Bank Websites Are Sending Loan Data to TikTok and Google

Quick answer: New research on 14 European and US financial-services websites found tracking pixels on bank websites sending loan amounts, contact details, and even a government tax ID to advertising platforms such as TikTok, Google, and Meta. On 9 of the 14 sites, the tracking fired without valid consent. Nothing on the banks’ servers changed, which is why nothing caught it.

Often the data left before visitors made a consent choice. Sometimes it kept flowing after they explicitly rejected tracking. The researchers ran a runtime analysis covering retail and investment banks, payment providers, and consumer credit platforms, and the data reached roughly a dozen third parties, including Google, Meta, TikTok, LinkedIn, Pinterest, Adobe, and Salesforce.

What did the research find on bank websites?

• Three Spanish banks sent hashed emails and phone numbers to TikTok and Google from mortgage and account-opening flows. The hashing is deterministic, so anyone holding the original value can reidentify the customer. In one case, the data went out after the user rejected cookies, and the request itself carried the denied-consent flag.
• A Portuguese bank’s account-opening flow sent a customer’s Base64-encoded email (trivially decodable), plus their name, age, and government tax number, to a marketing personalization platform.
• A consumer-credit provider sent Google Analytics the full loan-application URL, including the requested amount, term, and insurance selection, after the user rejected all cookies.
• On another bank’s credit simulator, the user accepted essential cookies only. The next step opened an iframe on a separate subdomain that ignored that choice, and Pinterest, LinkedIn, TikTok, Meta, and Google all received the simulation details: a €27,000 loan, a 48-month term, and a €655.99 monthly payment.
• LinkedIn logged one user’s click on the reject-all button as a tracking event, at the same moment the rejection was being ignored.
• US institutions were not exempt. A major US bank’s wealth-management site fired an analytics pixel while the consent banner was still on screen, with the consent gate hardcoded to enabled. A US investment bank and two payments providers showed the same pre-consent pattern.

Why didn’t the banks notice?

Because nothing changed on their servers. A modern banking page is assembled at runtime, inside the visitor’s browser, from scripts supplied by dozens of external vendors: analytics, tag managers, marketing pixels, chat widgets, personalization platforms.

Your WAF inspects traffic to your servers. Your scanners test your own code. Your consent platform manages the banner. None of them verify what a third-party script actually does inside a customer’s browser after the page loads. WAFs protect the perimeter. Client-side security protects execution.

Many of these tags also overcollect by default. Features like automatic advanced matching capture and hash contact details with no deliberate action from the site owner. A bank that drops in a standard pixel never configured it to send hashed emails from a mortgage page. The default did.

This is what banks find when they look

The research is not an outlier. A Tier-1 European banking group ran an independent proof of concept across 27 of its public websites and found:

Its own Group Data Protection team concluded that client-side monitoring should be implemented group-wide. Both studies describe the same problem: code you did not write is handling data you are accountable for. And because banking groups often share tag infrastructure across brands, one permissive default replicates across every property the group operates.

What is the regulatory exposure?

Four fronts at once:

• GDPR and ePrivacy: Fines can reach 4% of global annual revenue. CNIL has already fined Google €150 million and Facebook €60 million over consent failures.
• US litigation: Pixel class actions against financial institutions are advancing past dismissal. In March 2026, a Wisconsin court let nine claims proceed against a credit union, rejecting the anonymized-and-disclosed defense at the pleading stage.
• DORA: Applicable since January 2025. Unmanaged third-party scripts in customer-facing flows are third-party ICT risk for financial institutions.
• PCI DSS 4.0.1: Requirements 6.4.3 and 11.6.1, mandatory since March 31, 2025, demand a live, authorized script inventory on payment pages and alerts on unauthorized changes.

How do you close the gap?

Continuous client-side monitoring. And there is an architectural lesson hiding in the findings: the €27,000 leak happened inside a cross-origin iframe, exactly where embedded, in-page monitoring scripts are blind by design. Fixing a third-party-script problem by adding another script to the page also adds one more vendor touching your customers’ sessions.

Reflectiz monitors remotely: the platform simulates real user journeys in a controlled browser environment outside your site and observes every script, pixel, iframe, cookie, and network call.

• Nothing deployed on your site: no tag, no latency, no new attack surface
• Full visibility into cross-origin iframes and subdomains, which is where several of the consent failures in this research occurred
• Zero access to customer data, so no new data-processing relationship
• Live dashboard within hours of sharing your URLs

Every pixel in the research above would have appeared in the inventory, flagged with what it collects and where it sends it, before a regulator, a plaintiff’s attorney, or a journalist found it first.

See what is actually running on your website. Book a demo.