Review Finds Bank Websites Leaked Financial Data Through Tracking Scripts
A TechRadar review of 14 financial-services websites in Europe and the US found tracking scripts in account-opening, mortgage, and loan flows sent contact details, financial intent, and device fingerprints to third parties, with nine sites doing so without valid consent.
The failures fell into three patterns, and the review said the distinction matters legally. On wealth-management, investment-banking, and payment-provider sites, tags fired before the cookie banner had been answered at all. Under the EU's ePrivacy Directive, that behavior never had a lawful basis because consent is required before anything is stored on or read from a device.
At another site, tracking continued after a user actively rejected cookies. Google Ads and DoubleClick still received the user's hashed email in the request URL alongside the consent-denied signal, meaning the rejection was recorded and then ignored, the review said.
Financial specifics also leaked regardless of consent status. During one personal credit application, a loan amount of €2,500, a 12-month term, and an insurance selection reached Google Analytics. At a Portuguese bank, a customer's name, age, and tax number were sent to Evergage as Base64-encoded text in a request URL during account opening.
At a Dutch banking site, a first-party script combined browser fingerprinting with image requests to 127.0.0.1 on ports 7070 and 5938, the ports associated with AnyDesk and TeamViewer. The review described this as effectively checking whether remote-access software was running on the visitor's own device.
Meta and TikTok have each pointed to the website operator as the party in control of what gets collected, in response to earlier research on the topic. Meta cited its privacy controls and its policy against sharing sensitive data. TikTok said advertisers decide what events and parameters they send, and that it only receives what partners intentionally configure.
According to the review, that framing puts responsibility entirely on the website operator and only holds up if the collection was something the operator deliberately turned on. Often it was not. Meta's Automatic Advanced Matching feature is turned on by default on the Meta Pixel, and in that default state it captures and hashes contact-form data without any separate configuration step from the site owner. A bank engineer adding a standard tracking snippet is not choosing to send a mortgage applicant's hashed email and phone number to Meta; the pixel does that by default. A policy against collecting sensitive data is difficult to reconcile with a feature that collects it by default.
That does not remove the bank's own responsibility, the review said. Banks choose which vendors to deploy, place the consent banners in front of customers, and publish cookie policies that are supposed to name every entity receiving that data. Both sides carry some of the blame: platforms ship defaults that maximize data capture, and banks deploy those defaults into some of their most sensitive flows without validating what they actually do at runtime.
The review described the issue as a compliance question as much as an ethical one. In the EU, unmanaged third-party scripts in customer-facing flows sit across GDPR and ePrivacy consent requirements and, for regulated financial entities, DORA's third-party risk and operational resilience rules. PSD2 adds its own security obligations for payment flows. In the US, institutions carry duties under the Gramm-Leach-Bliley Act's Safeguards Rule and increasingly under state laws such as the CCPA/CPRA.
Fixing the problem starts with verifying runtime behavior rather than assuming it matches what was configured, according to the review. That means validating what scripts actually do on live account-opening, mortgage, loan, and simulation pages, since these carry the highest-value data, rather than stopping checks at the homepage. It also means watching for a tag that starts collecting more than it was originally set up to collect, sometimes called scope creep.
Visibility needs to lead to control. Security teams need the ability to stop third-party scripts from reading sensitive form fields and to block unauthorized data transfers, including the technique of hiding identifiers and financial details inside a request URL rather than a request body. Consent needs to mean something in practice, not just on paper: a rejection should stop data from leaving the browser instead of merely getting logged as a denied signal while the tracking call fires anyway.
Editor's Summary
A TechRadar review of 14 financial-services websites found tracking scripts leaked contact and financial data to third parties, often without valid consent. The findings raise compliance questions under EU and US privacy, financial-security, and operational-resilience rules. The review says banks and platforms should verify runtime behavior and give security teams control to enforce consent and block unauthorized transfers.