New research from Jscrambler shows that financial institutions in Europe and the US have been transmitting sensitive customer data to third-party advertising, analytics, and personalization platforms through cookie trackers, pixels, and browser-side scripts. The issue affects customer journeys such as account opening, mortgage applications, credit simulations, and loan flows, where users may enter highly sensitive financial and personal information.
The problem is not only that tracking exists. The bigger issue is that tracking sometimes fired before users gave consent, continued after users rejected cookies, or failed to respect consent choices across subdomains and embedded iframes.
What Happened
Jscrambler analyzed 14 financial services websites, including retail banks, investment banks, payment providers, and consumer credit platforms. Across those cases, tracking technologies fired without valid consent at nine separate companies. Data was sent to third parties including Google, Meta, TikTok, LinkedIn, Pinterest, Adobe, Salesforce, and others.
The data reportedly included hashed and unhashed emails, phone numbers, government tax IDs, loan details, repayment terms, and financial intent signals. In some cases, the data was merely encoded or deterministically hashed rather than strongly protected, meaning it could potentially still be linked back to individuals under the right conditions.
Why This Matters
Financial institutions are among the most regulated and trusted custodians of personal data. Customers expect banks to protect information related to identity, borrowing, income, credit, payments, and account activity.
But modern banking websites increasingly rely on third-party JavaScript for marketing, analytics, personalization, fraud prevention, customer journeys, embedded forms, and conversion measurement.
That creates a client-side risk.
Even if the bank’s backend systems are secure, sensitive data can still leak from the browser if third-party scripts collect or transmit information from forms, URLs, buttons, embedded pages, or tracking events.
Sensitive Pages Were Affected
This was not limited to basic marketing pages.
According to the reporting, trackers appeared in sensitive flows such as mortgage applications, account-opening forms, and loan simulators. One example involved a Spanish bank where a mortgage process sent a hashed email and phone number to TikTok’s pixel endpoint after cookie acceptance, despite TikTok not appearing in the bank’s cookie or privacy policy.
Another case involved a Portuguese bank account-opening flow where customer data, including email address, name, age, national tax number, and a Salesforce Marketing Cloud contact key, was sent to a Salesforce marketing platform.
Researchers also described credit and loan simulation flows where financial details such as loan amount, term, interest rate, and total cost of credit were sent to Google Analytics.
Consent Controls Failed in Multiple Ways
The research identified three recurring consent failures.
First, tracking fired before the user made a cookie choice. Second, tracking continued even after the user selected “reject all.” Third, consent choices were recorded on one part of a site but were not carried into subdomains or iframes handling the next step of the same transaction.
That last point is important.
Many financial journeys do not happen on one simple page. A user may start on the main website, move into a mortgage calculator, continue through an embedded form, and finish inside a different subdomain or third-party-hosted component.
If consent enforcement crosses those boundaries, the customer may believe they have rejected tracking while data continues to flow.
Why Cookie Banners Are Not Enough
Cookie banners often create the impression that privacy is controlled at the user interface level.
But the real risk sits deeper.
A banner can show “reject all,” but if third-party scripts still fire, collect data, or send tracking events, the consent mechanism is not doing its job in practice.
Security teams need to verify actual runtime behavior, not only the declared policy.
The key question is not “Did the website show a banner?”
The key question is “Did the browser actually stop unauthorized data collection after the user rejected tracking?”
Third-Party Risk in the Browser
This issue sits at the intersection of privacy, security, and third-party risk.
Financial institutions may not write or fully control the code executed by advertising, analytics, personalization, and tracking vendors. But that code still runs on the bank’s website, inside the customer’s browser, during sensitive financial workflows.
Jscrambler’s Gareth Bowker described the issue as a third-party risk problem at its root, because code the organization does not fully control is executing on its most sensitive pages. It becomes a privacy issue when personal data is sent to platforms users did not agree to, and a security issue when sensitive values appear in request URLs or third-party systems.
Compliance Implications
The findings raise compliance concerns under several regulatory frameworks.
In Europe, the most obvious concerns relate to GDPR and the ePrivacy Directive, especially where tracking occurs without valid consent or where sensitive personal data is shared with third parties. Financial institutions are also subject to DORA, which focuses on digital operational resilience and third-party technology risk in the financial sector.
For banks and financial firms, this is not simply a marketing configuration issue.
It may become a data protection, supplier governance, security monitoring, and operational resilience issue.
What Financial Institutions Should Do
Financial organizations should move beyond static cookie audits and point-in-time vendor reviews.
Recommended actions include:
- continuously monitor browser-side script behavior
- verify that rejected consent actually stops tracking
- enforce consent across iframes, subdomains, and embedded journeys
- block unauthorized data exfiltration from forms and URLs
- disable automatic advanced matching where it is not justified
- review third-party scripts on account-opening, mortgage, credit, and loan pages
- inspect what data is being sent to analytics and advertising platforms
- treat marketing tags as third-party code with security impact
- align privacy, AppSec, legal, and marketing teams around runtime controls
Jscrambler specifically recommends runtime monitoring, enforcement controls, consent validation across subdomains and iframes, and blocking unauthorized data exfiltration, including data placed into request URLs.
What Customers Should Know
Customers cannot easily see what third-party scripts are doing in the background.
A user may reject cookies and still have no simple way to verify whether tracking stopped. They also may not know that sensitive actions such as mortgage simulations, account-opening steps, or loan calculations can generate data flows to analytics and advertising platforms.
For individuals, practical protection is limited. Browser privacy tools, tracker blockers, and strict cookie settings may help reduce exposure, but the responsibility sits mainly with the financial institution and its technology providers.
Customers should still be cautious when entering sensitive information online and should prefer institutions that clearly explain how data is collected, shared, and protected.
Final Thoughts
The Jscrambler findings show that financial data leakage is not always caused by a database breach or a hacked server.
Sometimes it happens directly in the browser.
Third-party trackers, pixels, and personalization scripts can quietly collect and transmit sensitive information during customer journeys that users assume are private and secure.
Customer data protection cannot stop at the backend perimeter. The browser is now part of the security boundary.
If banks allow third-party code to run on sensitive pages, they must continuously monitor what that code does, enforce consent decisions in practice, and block unauthorized data flows before customer information leaves the site.
