Banking websites are leaking sensitive data to third parties

At a glance

What this is: Jscrambler found that sensitive banking journey data is routinely shared with third-party tracking and personalization platforms, including cases where collection happened before consent or after rejection.

Why it matters: This matters because identity, consent, and runtime control are collapsing into the same problem space, and IAM-adjacent teams need visibility into browser-side data flows as well as access governance.

👉 Read Jscrambler's analysis of banking websites leaking customer data to third parties

Context

Banking websites are expected to handle personal and financial data under tighter scrutiny than ordinary consumer sites, yet modern page stacks still depend on scripts that can move information outside the bank’s direct control. The governance gap is not simply whether cookies are shown, but whether runtime collection is limited to what the user actually consented to and what the institution intended to share.

In this research, that gap appears across account-opening, mortgage, credit, and wealth-management flows, where tracking and personalization tags carried hashed or raw identifiers, financial intent, and journey metadata to third parties. For identity and security teams, this is a useful reminder that consent enforcement, script governance, and data minimisation now overlap with the same control plane.

The pattern is not typical of a single broken page or isolated implementation mistake. The consistency across multiple institutions suggests a broader control failure in how browser-side collection is approved, monitored, and constrained.

Key questions

Q: How should security teams handle consent failures in browser-based customer journeys?

A: Treat consent failure as a runtime control issue, not a banner-design issue. Teams should test whether scripts wait for a user choice, stop after rejection, and keep that decision intact across iframes and subdomains. If the browser still sends identifiers or journey data, the control has failed regardless of what the policy says.

Q: Why do hashed email and phone values still create identity risk?

A: Because deterministic hashes can still function as stable matching tokens. If a platform receives the same hashed value repeatedly, it can link sessions, profile customers, or enrich records across systems. In regulated journeys, hashing reduces readability but does not automatically remove identifiability or the governance burden.

Q: What do banks get wrong about analytics on application and loan flows?

A: They often treat analytics as harmless measurement when it is actually exporting customer intent. On mortgage, credit, or onboarding pages, those tags can reveal product interest, financial capacity, and progression through a regulated journey. Security teams should assess the data leaving the browser, not just the vendor category.

Q: Who is accountable when third-party scripts ignore consent choices?

A: Accountability usually sits with the organisation that deployed the script, even when the script vendor’s defaults encourage over-collection. Regulators expect the controller to know what data is being transmitted, disclose it accurately, and enforce the user’s choice in practice. If the browser sends data after rejection, ownership has not been transferred.

Technical breakdown

How third-party pixels turn banking journeys into data export channels

Tracking and personalization scripts operate inside the browser, where they can read form fields, page context, event metadata, and identifiers before transmitting them to external endpoints. In financial services, that means a mortgage or loan flow can expose much more than click analytics. Hashed contact data, persistent IDs, page URLs, and even simulated credit values can be sent to advertising or measurement platforms with very little user visibility. The governance problem is that the site owner may think it is collecting analytics, while the runtime code is exporting customer intent and identity signals to third parties.

Practical implication: Inventory every script that can read or transmit sensitive page data, especially on application and onboarding flows.

Why consent state breaks down across banners, iframes, and subdomains

Consent controls only work if the decision is enforced everywhere the page loads code. Jscrambler’s cases show three common failures: scripts firing before the banner is answered, scripts continuing after rejection, and consent choices not propagating into embedded iframes or separate subdomains. In practice, the browser can record a denial while still allowing identifiers or journey data to leave the site. That creates a gap between policy and execution, which is why banner presence alone is not evidence of compliance.

Practical implication: Test consent logic in the real browser path, including embedded frames and cross-subdomain flows, not just on the homepage.

Why hashed identifiers are still identity data

Hashing is often mistaken for anonymisation, but deterministic hashes of email addresses or phone numbers remain linkable when the original value is known. If a platform receives a hashed identifier from a banking flow, it can use that value as a persistent signal for profiling, matching, or enrichment. The identity risk is therefore not eliminated by replacing plain text with a hash. In regulated journeys, a hash can still function as a stable personal-data surrogate when it is tied to a known customer attribute.

Practical implication: Treat hashed contact details as sensitive identity data unless you can prove they are irreversibly de-identified.

Threat narrative

Attacker objective: The practical objective is not break-in theft but uncontrolled disclosure and enrichment of customer identity and financial intent through third-party data flows.

1. Entry occurs through embedded tracking, analytics, or personalization scripts running inside banking web journeys.
2. Credential or identity data is harvested when those scripts collect hashed email, phone number, or raw customer details from forms and URLs.
3. Impact follows when sensitive personal and financial intent is exported to third-party platforms outside the bank’s direct control.

NHI Mgmt Group analysis

Consent enforcement has become a runtime security problem, not just a privacy checkbox. The article shows that a banner can exist while data still leaves the browser before choice or after rejection. That means the control failure sits in execution, not policy text, and it affects privacy, security, and identity governance at the same time. For practitioners, this is a reminder that browser-side data movement needs the same control discipline as privileged access.

Hashed customer identifiers are still governed identity data. When a bank sends hashed email or phone values into ad-tech ecosystems, it is creating a stable matching token, not anonymous telemetry. That blurs the line between marketing analytics and identity disclosure, especially where the same signals can be recombined across platforms. IAM and privacy teams should treat these flows as controlled identity exposure, not harmless measurement.

Browser-script sprawl is the web equivalent of unmanaged NHI sprawl. Each pixel, tag, and embedded workflow behaves like a non-human actor with its own access, data collection scope, and downstream dependencies. The named concept here is runtime consent drift: the gap between what the user chose, what the policy says, and what the browser actually sends. That is the governance failure this research exposes, and it belongs in the same conversation as access review and data minimisation.

Financial-services journeys expose intent, not only identity. The article shows that loan amount, repayment term, and application progress are commercially and operationally sensitive signals. Once those signals flow to third parties, the bank loses visibility into who can infer customer demand and product economics from them. Practitioners should treat intent leakage as a data-governance issue with direct security and trust implications.

Vendors that ship default collection behaviours shift risk into the customer environment. The bank still owns deployment decisions, but default-enabled pixels and auto-capture features make the real governance question whether the institution can prove it restrained the script at runtime. That is why control verification matters more than policy claims, and why security teams should insist on evidence from live flows rather than documentation alone.

What this signals

Runtime consent drift is the operational signal teams should watch for when browser-side data collection and privacy policy diverge. The practical lesson is that consent enforcement needs the same testing discipline as access control, especially where customer journeys include embedded scripts, subdomains, and externally hosted frames.

For identity and data governance teams, the priority is to map which customer-facing pages can leak personal or financial intent to third parties, then prove that collection is blocked when it should be. That requires evidence from live flows, not just static policy review, and it belongs alongside broader controls such as least privilege and data minimisation.

The browser has become a policy enforcement boundary, and in banking it is now a sensitive one. Programmes that still treat client-side tags as marketing-only infrastructure will miss the point: they can also behave like unmanaged non-human actors with data access that outlives the user’s choice.

For practitioners

• Audit runtime script behaviour on sensitive journeys Inspect mortgage, account-opening, loan, and wealth-management flows in a real browser to see exactly which scripts read fields, capture identifiers, and call external endpoints. Focus on pageviews, iframes, and embedded tags rather than the homepage.
• Enforce consent propagation across frames and subdomains Verify that a reject-all choice actually stops data transmission inside embedded iframes and across subdomains. A consent banner is not enough if the child frame ignores the parent decision or if scripts fire before the choice is made.
• Disable automatic matching and over-collection features Turn off automatic capture of contact data, hashed identifiers, and event enrichment unless the collection is explicitly documented, disclosed, and legally justified. Hidden default behaviour is the most common route from analytics to data leakage.
• Classify hashed identifiers as sensitive signals Update data handling rules so hashed email and phone values from banking journeys are treated as linkable identity data, not anonymous telemetry. That changes review, retention, sharing, and vendor approval requirements.
• Instrument third-party endpoints for blocked exfiltration Use runtime controls to detect and block requests that carry personal details in URLs, request payloads, or tracking parameters. Prioritise endpoints associated with advertising, personalization, and measurement platforms.

Key takeaways

• Banking websites are exposing customer identity and financial intent to third parties through runtime scripts that often ignore or outrun consent controls.
• The research shows repeated failures across 14 financial-services cases, with data reaching about a dozen outside platforms and leaking even after rejection in some flows.
• Practitioners should treat browser-side tracking as a governed data-access problem, with live-flow testing and script restriction as core controls.

Key terms

• Runtime Consent Drift: The gap between what a user selected in a consent interface and what the browser actually allowed scripts to send. It matters because a policy decision can be recorded correctly while data still leaves the site through embedded frames, subdomains, or preloaded tracking code.
• Deterministic Hashing: A one-way transformation that produces the same output for the same input every time. In identity and privacy contexts, it often reduces readability but does not remove linkability, because a known email or phone number can still be matched to the same hash value later.
• Client-side Data Leakage: Client-side data leakage occurs when sensitive information is exposed, copied, or exfiltrated within the browser before it reaches backend systems or traditional monitoring tools. It is often invisible to server-side logs because the data loss happens in the rendered session, not the application core.
• Financial Intent Leakage: The exposure of a customer’s likely decision, product interest, or borrowing behaviour through web interactions. On banking sites, this can reveal loan amounts, repayment terms, application progress, or product choices that should not be broadly shared outside the institution.

What's in the full report

Jscrambler's full report covers the operational detail this post intentionally leaves for the source:

• Per-bank case breakdowns showing which pages sent hashed or raw data and exactly which third parties received it.
• Request-level examples for consent failures, including pre-consent firing, post-rejection leakage, and iframe boundary breaks.
• Evidence trails for the mortgage, credit, account-opening, and wealth-management flows analysed in Europe and the USA.
• The site-level script and endpoint patterns behind advanced matching, personalization, and fingerprinting behaviour.

👉 The full Jscrambler report covers per-bank examples, request details, and consent-failure patterns across sensitive banking journeys.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and machine identity security. It helps security and identity teams build the control literacy needed to govern non-human access and runtime exposure across modern environments.