Notifications
Clear all
Topic starter
19/08/2026 3:42 pm
TL;DR: Banking journeys across Europe and the USA were sending hashed or raw customer data to advertising and personalization platforms, often before consent or after rejection, with 14 financial-services cases showing repeated consent failures and data flows to about a dozen third parties, according to Jscrambler. The lesson is not just privacy risk: runtime script governance now sits inside broader identity, access, and data-control programmes.
NHIMG editorial — based on content published by Jscrambler: banking websites are leaking customer data to third-party platforms
Questions worth separating out
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.
Q: Why do hashed email and phone values still create identity risk?
A: Because deterministic hashes can still function as stable matching tokens.
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.
Practitioner guidance
- 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.
- Enforce consent propagation across frames and subdomains Verify that a reject-all choice actually stops data transmission inside embedded iframes and across subdomains.
- 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.
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.
👉 Read Jscrambler's analysis of banking websites leaking customer data to third parties →
Banking websites and consent failures: what IAM teams should notice?
Explore further
19/08/2026 4:20 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Banking websites are leaking sensitive data to third parties
