finecobank.com

Context

it.finecobank.com is the website of the Italian online bank FinecoBank S.p.A. (part of the UniCredit group). A modern Next.js application. The privacy policy is one of the most detailed in the whole series: about seventy-seven thousand characters, covering credit scoring, biometrics (voice password, graphometric signature), international transfers and an Azure-cloud chatbot. The capture shows 99 requests to 22 domains. The capture, like the whole series, was taken on a clean Edge browser with no VPN and no blocker. This site is interesting in that it shows: doing consent right is possible. And against the backdrop of the commercial sites in the series it stands out favourably precisely in its mechanics.

Was there a consent banner

There is a banner — the OneTrust system, and it works as it should. Its stub loads at the very start, the full rendering of the banner completes at around the second-to-third second, and the user’s decision is recorded by a separate receipt at around +4.7 seconds. The main thing is what happens around this banner, and here everything is arranged correctly.

Consent is implemented correctly

This is the key observation and a big plus for the site. Google has a machine flag that tells the embedded tools whether saving data and identifiers is allowed. Before consent this flag is in the «declined» position — and in this state only the libraries themselves and anonymised utility pings go out, without saving anything identifying. No marketing trackers work at this time. And only after consent is recorded by a receipt does the flag switch to the «allowed» position — and then, and not a second earlier, the whole marketing stack switches on in a salvo. That is, the sequence is correct: first they ask, then they collect. This is the direct opposite of what we saw, for example, on the advertising blog, where the trackers worked against the refusal. Another mature detail is worth noting separately: Google’s analytics here goes not directly, but through the bank’s own server node. The data first arrives at Fineco’s own infrastructure, and only then is passed further — which gives the bank more control over exactly what goes outward.

What switches on after consent

To show the scale, here is who comes to life after consent is recorded: Google’s analytics and advertising tags, Amazon’s advertising system, Microsoft/Bing advertising and the Salesforce Evergage behavioural-personalisation system, as well as the YouTube player. The set is serious, especially Salesforce Evergage — a tool that adjusts content to the behaviour of a specific visitor. But the fundamental point is that this whole set switches on only with consent, not before it.

The recipients — where are they named?

Here is the only real catch, and it must be laid out honestly and without exaggeration. The extremely detailed main policy, which meticulously describes the banking processes, speaks of cookies in literally one phrase and refers to a separate cookie area at another address. In this document itself none of the web partners — Google, Amazon, Microsoft/Bing, Salesforce — is named. But this should not be blown up. Moving the detailed cookie list to a separate page is common and lawful practice, that is how many sites are arranged. And since the OneTrust system works here, which is precisely what compiles the list of all vendors automatically, the list of recipients is almost certainly on that separate page. I was unable to check it during the audit, so the correct formulation is this: the recipients are not named in the exported document, and the separate cookie page could not be confirmed. This is a question of the completeness of the available picture, not proven concealment.

How consent was obtained — an honest caveat

Another point that cannot be kept silent. In the capture the consent flag switches from «declined» to «allowed», and a receipt is recorded — but an explicit press of the «accept» button is not visible in the record. So from a single capture I cannot say for sure whether a live person pressed consent, whether the capture tool did so automatically, or whether the banner counted consent without a user action. If the last is true, it would undermine the otherwise correct mechanism. But this cannot be claimed from the capture, and the «ask first» architecture here is built correctly.

What cannot be claimed from the capture

In addition to the above: I did not check the separate cookie page with the vendor list; the origin of the consent in the capture is ambiguous; the capture covers the public home page, and the banking processes described in the policy (biometrics, scoring, transfers) are not engaged on it; the server IP addresses are not preserved in the lightweight export.

Conclusion

Against the backdrop of the commercial sites in the series, this is one of the best examples in terms of consent mechanics. Nothing identifying goes out before consent, the marketing stack switches on strictly after the decision is recorded, and the analytics goes through the bank’s own server node — all of this is done competently and responsibly, the direct opposite of the blog with an advertising auction. The only unclosed point is that the web partners are not named in the document itself and are moved to a separate page that could not be checked; with the consent system used, they are most likely listed there. The main takeaway for the reader: the bank shows that collecting data with consent and under control is possible, and here it is mostly done that way; the questions remain about the completeness of disclosure, not about the mechanics themselves.