Banks present themselves as the most careful custodians of personal and financial data. Customers expect that trust to extend to every digital interaction including public websites and online application flows. Yet Jscrambler’s Security Research Team found that many banking experiences transmit sensitive information to third-party advertising, analytics, and personalization platforms. In many cases, the data leaves the browser before the user has made a consent choice. In others, it continues to flow even after users have rejected tracking technologies.
Following on from our previous pixel research, Jscrambler conducted a runtime analysis of the tracking and personalization scripts running on financial services websites across Europe and the USA. Our previous pixel research analysed retail, hospitality, and healthcare websites. This new research focuses on retail and investment banks, payment infrastructure providers, and online customer journey flows including opening accounts, applying for credit, and simulating loan approval processes. These are among the most regulated and sensitive pages on the web, and the behaviors we observed go well beyond what ordinary user journey tracking requires.
The findings were consistent enough to be described as patterns rather than one-off errors. Across the fourteen financial-services cases we documented in this research, tracking fired without a valid consent choice at nine separate companies, whether before the banner was actioned, after the user rejected all cookies, or despite an essential-cookies-only selection. The data then reached approximately a dozen distinct third parties.
Tracking pixels and personalization tags were once simple tools for confirming an ad impression or counting a visit. On a banking website, the same tags now sit alongside mortgage calculators, account-opening forms, and loan applications, and they behave the same way as they do on a retailer’s checkout page. They collect contact details, hash them, attach them to persistent identifiers, and transmit product and financial intent to platforms the bank does not control. Most institutions are unlikely to realize how much of this is happening by default.
From Anonymous Visit to Named Banking Customer
The most direct concern is a pattern that Jscrambler Security Research repeatedly observed across banks in different countries: re-identifiable contact data leaving banking pages and entering advertising platforms.
As we documented in our previous research, TikTok and Meta normalize an email address or phone number, convert it into a SHA-256-hashed identifier, and send it out. The hashing is deterministic, so the same input always produces the same output. A hash built from a known email or phone number can therefore be traced back to that person by anyone who holds the original value. It does not anonymise the user, it merely relabels them.
A representative case was the online mortgage flow of a Spanish bank. The user was shown a cookie banner offering the usual choices to accept, configure, or reject, with text explaining that the site used both first- and third-party cookies for analytics and advertising based on a profile built from the user’s browsing habits. After the user accepted, TikTok received the user’s hashed email and hashed phone number through a request to its pixel endpoint (analytics.tiktok.com/api/v2/pixel/inter). The request originated from an embedded iframe serving the mortgage page, and the payload carried the hashed identifiers alongside the:
- Full page URL
- Referrer
- Anonymous ID
- Session ID
- Pageview ID
The bank publishes a cookie policy that enumerates the cookies and vendors it sets, but TikTok does not appear in it, and TikTok is absent from the bank’s privacy policy as well. A customer reading either document would have no way to know that accepting cookies would send their hashed contact details to TikTok.
The recipient of sensitive data was not always a social media platform. During the online account and card application flow of a second Spanish bank, requests to Google Ads, Google Consent Mode, and Google Analytics carried the user’s hashed phone number directly in the request URL, in parameters named telefono_hasheado and ep.telefono_hasheado. The data travelled to Google’s advertising and measurement infrastructure from inside a live banking application, on a page where the customer was entering personal details.
In the most serious version of this pattern, the data was not hashed at all. During the online account-opening flow of a Portuguese bank, a request was sent to Evergage, now part of Salesforce Interaction Studio, including the user’s email address in the request URL. The value was Base64-encoded, which is simple encoding, not encryption, so it was trivially decodable back to the raw address.
Later steps of the same flow sent additional personal data to the same platform, including the customer’s name, age, Portuguese tax number (NIF), and a Salesforce Marketing Cloud contact key. Several of these events carried an empty consents array. Sending raw, recoverable personal data and a government identifier from an account-opening flow to a marketing personalization platform poses a materially different risk from a hashed advertising signal, and it sits at the top of any reasonable severity scale.
Two further cases sent a hashed email to Google after the user had actively rejected cookies. Because the consent story is the sharper issue there, we return to them below.
The Financial Intelligence Problem
Identity is only one part of the exposure. The other is financial intent: the signals that reveal what customers are looking for, the decisions they are considering, and where they are in a financial journey. This creates a dual risk: customers may unknowingly expose sensitive financial information, while banks may unintentionally reveal valuable intelligence about customer demand, product interest, and conversion activity to third parties. On a retail site, this type of exposure might reveal:
- Product names
- Prices
- Cart values
On a banking site, the implications are far more significant. The data can reveal borrowing behaviour, financial needs, product preferences, and progress through high-value application journeys.
In the personal credit flow of a Portuguese consumer-credit provider, Google Analytics received the full loan application URL, which encoded the customer’s specific choices: a requested amount of €2,500, a 12-month term, an indication that insurance was selected, and a flag for finance charges. Google Analytics also received event names from the application, including steps labeled as the personal data and banking details stages of the credit flow. This exposed not only that a person was applying for a loan, but the amount requested, repayment period, additional product selections, and progression through the application funnel.
On the personal credit simulator of a second Portuguese bank, a Google Analytics event transmitted the full set of simulation values after a user completed a credit simulation:
- Desired loan amount
- Repayment period
- Monthly payment
- Annual Percentage Rate (TAEG)
- Nominal interest rate (TAN)
- Total amount payable (MTIC)
- Product family and subfamily
No email, phone number, or hashed identifier appeared in that particular request, but the financial profile it described was remarkably detailed. Aggregated across many sessions, this is a continuous feed of demand, pricing sensitivity, borrowing preferences, and conversion behaviour for a bank’s lending products, flowing into a third-party platform that uses signals collected across its advertising ecosystem to refine audience models and optimize advertising performance, including for other financial services organizations.
This is the financial services equivalent of the commerce data problem we described in our previous research. Organizations may believe they are simply measuring user behavior through standard analytics. In practice, they are exporting a detailed, ongoing view of customer financial intent and product economics to third parties, often with little visibility into the scope or sensitivity of data being shared.
Collected Before, and Despite, the Consent Choice
The timing of these requests matters as much as their content. Consent only protects the user if the tracking waits for it, and during this analysis, we found three distinct ways that it did not:
- Tags that fired before the banner was actioned.
- Tags that kept firing after the user rejected everything.
- Consent choices that were never carried into the part of the site doing the tracking.
The first pattern was tracking that ran before any choice was made. On the wealth-management site of a major US bank, a “Yext” tracking pixel sent a pageview to yext-pixel.com while the cookie banner was still on screen. The page source showed analytics enabled by default (window.yextAnalyticsEnabled = true), and the function that was supposed to gate analytics on consent simply set the same value to “true” again, so the pixel was effectively always on. The same pre-consent firing appeared elsewhere. On the site of a major US investment bank, a Parse.ly content analytics pageview (p1.parsely.com/px/) and an Adobe Experience Platform request went out before consent.
This before-consent firing was something we saw in both the US and Europe alike, from the US wealth-management and investment-banking cases, to a European bank whose fingerprinting script, covered below, also loaded before the banner was answered.
On a UK payments provider’s site, the conversational marketing platform “Drift” received visitor and page data, including an anonymous ID, country, hostname, locale, and session metadata, ahead of the banner, alongside an early Google Analytics request. On a US payments-infrastructure provider’s site, a Google DoubleClick advertising request (adservice.google.com/ddm/fls/z/) loaded while the cookie banner was still displayed.
The second pattern is harder to defend because the user explicitly said no. On the digital account-opening flow of a third Spanish bank, Google Ads and DoubleClick received the user’s hashed email in the request URL, via the match_id and u5 parameters, even though cookies had been rejected. The request itself carried pscdl=denied, confirming the rejected state. This is one of the two cases flagged earlier: a hashed contact identifier sent to an advertising and conversion endpoint from an account-opening page after the user declined.
A Portuguese bank’s account-opening flow went further still. With cookies rejected, Google Analytics received a SHA-256 hash of the email the user had entered during registration, again alongside the consent-denied signals (gcs=G100, npa=1, pscdl=denied). On the same flow, LinkedIn captured the journey step by step:
- Page visits
- Form-submission clicks
- Clicks on the account-opening call to action
- Birth-year selection from the date picker
LinkedIn even recorded the user clicking “RECUSAR TODOS”, the reject-all button itself. The consent rejection was logged as a tracking event at the same moment it was being ignored.
The Portuguese consumer credit flow described earlier follows the same pattern. There, the user rejected all cookies, the Google Analytics request correctly carried gcs=G100, npa=1, and pscdl=denied, and Google Analytics still received the loan application URL and event names. Recording the consent state and then ignoring it in practice is arguably worse than not asking, because it produces a documented record of a choice the implementation did not honor.
The third pattern is subtler. On another Portuguese bank’s personal credit simulator, the user accepted only essential cookies. Clicking through to the next step opened an iframe hosted on a separate subdomain, and that iframe did not inherit the consent choice made on the main site. Once it loaded, Pinterest, LinkedIn, TikTok, Meta, and Google/DoubleClick all fired from inside it, receiving the credit simulation context:
- Loan purpose
- Loan amount of €27,000
- Repayment term of 48 months
- Total cost of €32,141.92
- Monthly payment of €655.99
LinkedIn also captured the click on the data-processing consent label inside the form. A consent choice that is not carried across a site boundary is not really a consent choice at all.
Fingerprinting Beyond Marketing
Not every concerning behavior comes from an advertising or analytics tag. Our research also identified browser fingerprinting and device intelligence collection occurring through first-party scripts, including activity observed on the online banking site of a Dutch bank.
A first-party script collected detailed browser and device characteristics and transmitted the information back to the bank through tracking image requests (/qsl/trans.gif), while storing a browserInfo cookie. The collected data included:
- User agent
- Platform
- Screen and window dimensions
- Language settings
- Installed plugins
- Font and browser fingerprint attributes
- Input field metadata
The script also probed localhost, issuing image requests to 127.0.0.1 on specific ports and measuring timing differences to infer whether particular local services were running. The observed ports included 7070 and 5938, associated with AnyDesk and TeamViewer, respectively. This behavior is consistent with fraud or remote-access detection rather than advertising, and there can be a legitimate security rationale for it. It is still highly invasive browser fingerprinting and local-port probing performed on the user’s machine, and it deserves the same scrutiny, disclosure, and consent treatment as any other runtime data collection. We are confirming the precise scope of this behavior under controlled testing.
The other direction was third-party adtech. On the site of a Portuguese bank, a fingerprinting script loaded before any cookie consent and sent a full device fingerprint to an advertising endpoint (tracking.adsafety.net), covering canvas, WebGL, fonts, audio, plugins, screen properties, timezone, hardware details, and more. Here there was no fraud-prevention rationale. A marketing fingerprint was being assembled before the user had agreed to anything.
Data Privacy and Regulatory Implications
The behaviours documented here create significant privacy and compliance risks under GDPR and equivalent US privacy regimes. The consent failures specifically implicate the ePrivacy Directive, which requires prior consent before storing or reading information on a user’s device. The recurring triggers are consent failures, where tags fire before a choice or after a rejection, and the transmission of personal data, including a government identifier in the Portuguese account-opening case, to third parties that the reviewed policies did not clearly name as recipients. Where data, such as an email address appears in a request URL, it can persist well beyond the request itself, in browser histories, server logs, and intermediary systems, widening the exposure.
The financial sector also carries obligations that a general retailer does not. In the European Union, operational resilience and third-party risk rules under DORA arguably treat unmanaged third-party scripts in customer-facing flows as part of the institution’s risk surface.
The payments framework is tightening as well: PSD2 already governs how payment data is handled, and its successors, the Third Payment Services Directive and the Payment Services Regulation, reached final compromise texts in April 2026 and are moving toward adoption. In the United States, the Gramm-Leach-Bliley Act and its Safeguards Rule require financial institutions to protect customer information, and state laws such as California’s CCPA and CPRA give consumers rights over how their data is shared. Loan amounts, repayment terms, and account-opening details are exactly the kind of customer information these regimes expect banks to control end to end.
This problem rarely stays on one website. Many of the groups in scope do not operate a single brand. The large traditional banks increasingly run separate digital or neobank brands alongside their flagship sites, often sharing tag management, analytics, and personalization infrastructure across the group. A single permissive default, an unconsented pixel, a hashed identifier in a URL, or a personalization platform receiving raw email addresses does not stay contained to one domain. It tends to replicate across every consumer-facing property the group operates. A configuration problem on one site is rarely just one site’s problem.
There is a competitive cost too, and it’s worse in finance than in retail. These tags are no longer just passive measurement tools. They are active collection systems that feed customer identity, financial intent, and product economics into the same global platforms that every other institution, including direct rivals, uses. Across this analysis, that data reached at least a dozen distinct third parties, including Google, Meta, and TikTok, as well as LinkedIn, Pinterest, Adobe, and Salesforce. Better aggregate data improves targeting, and better targeting tends to favor the players with the largest budgets.
Whose Responsibility Is It?
When the initial pixel research was published, Dark Reading wrote an article about it and asked Meta and TikTok to respond. Their answers are worth revisiting now, because our banking findings test the assumptions behind them. Meta characterized the report as self-promotional and said it misrepresented how the Meta Pixel works while ignoring the company’s privacy controls and its policy of prohibiting the sharing of sensitive data. TikTok took a narrower line, stating that advertisers decide what events and parameters they send, and that any data it receives is limited to what partners intentionally configure and send.
Both responses place the responsibility squarely on the website operator. That framing only holds if the collection is something the operator deliberately switched on, and much of what we observed is not. Features such as automatic advanced matching are enabled by default and are designed to capture and hash contact details with no explicit action from the site owner. A bank that drops in a standard pixel does not intentionally configure it to send a customer’s hashed email and phone number from a mortgage page, as we saw in the Spanish case above. In these situations, default platform behavior becomes a significant factor in what data is collected and transmitted.
Meta’s response also highlights a broader tension. A policy that prohibits the sharing of sensitive data is difficult to reconcile with a pixel that, left at its defaults, captures and transmits exactly that kind of data from account-opening and lending flows. If the policy genuinely prohibited it, the default would not collect it.
So the position remains the same as in our previous pixel research: responsibility is shared. Financial institutions do have a responsibility to review the third-party technologies they deploy on sensitive customer journeys, understand what data is collected, and govern those integrations appropriately.
However, responsibility cannot rest solely with the website operator when the tools are designed to collect as much data as possible by default, relying on terms of service, implementation guidance, and limited guardrails to keep that collection defensible. Telling an institution that it should have configured a pixel differently, while shipping a pixel that defaults to excessive data collection, does not fully address the underlying issue. It shifts the burden of controlling complex browser-based data flows to the organizations and customers with the least visibility into how those flows operate.
Recommendations to mitigate runtime data risks
Managing this requires more than reading a vendor’s documentation. It means auditing what the scripts actually do at runtime, in real application flows, and watching for scope creep, where a tag begins collecting more than was intended.
Monitor runtime behavior: gain visibility into what each script accesses, what it collects, and how it transmits that data, with particular attention to account-opening, mortgage, loan, and simulation flows rather than just the homepage.
Enforce runtime controls: proactively restrict third-party access to sensitive fields and block unauthorized exfiltration, including data placed in request URLs.
Honor the consent choice in practice: ensure tags do not load before a choice is made, verify that a rejection actually stops data leaving the browser rather than merely recording a denied signal, and confirm that the choice is carried into iframes and subdomains rather than lost at the boundary.
Disable advanced matching and automatic collection where it is not justified: turn off automatic event capture and advanced matching features that send hashed or raw contact data unless that sharing is documented, disclosed, and lawful.
Treat first-party scripts with the same rigor: fingerprinting and port-probing logic, even when built for fraud prevention, should be inventoried, disclosed, and consent-aware.
It is the responsibility of every institution to ensure that the scripts running on its sites are configured to do only what they are permitted to do, and nothing more. On a banking site, the gap between those two things is not a measurement nuance. It is sensitive customer data leaving the organization through a channel most users never see.
The next post in this series turns from what banks are exposing to what that data is worth on the other side: how advertising platforms, data brokers, and competitors can use these signals to improve targeting, audience intelligence, and commercial decision-making. And what it means for the institutions providing them.