# Consent, purpose limitation and the wall between products
Your mortgage servicer knows your income, your payment history, and how close you've come to missing a payment. Your same bank's auto lending unit would love that data to price your next car loan. Legally, in most cases, it can't touch it. Not because the data isn't "theirs," but because they collected it for one purpose and one purpose only: to originate and service your mortgage.
This is purpose limitation, one of the quieter but most operationally demanding principles in data privacy law. It doesn't ask "do you have the data?" It asks "did the customer agree to this specific use?" For a bank running dozens of products across retail, wealth, cards, and lending, enforcing that question at scale requires real engineering, not just a compliance memo.
Purpose limitation means personal data collected for a specified, explicit purpose cannot be reused for a materially different purpose without a new legal basis (typically fresh consent, or another lawful ground).
In the EU/UK, this is codified directly in the GDPR (General Data Protection Regulation), Article 5(1)(b). It's one of the core data protection principles, alongside data minimization and storage limitation. The UK's post-Brexit version, UK GDPR, mirrors this.
In the US, there's no single federal privacy law as sweeping as GDPR, but the wall still exists:
The regulators enforcing this on the banking side include the Consumer Financial Protection Bureau (CFPB) in the US and, in the EU, national Data Protection Authorities (DPAs) coordinated through the European Data Protection Board (EDPB).
A common misconception, even among experienced bankers, is that once data sits inside "the bank," it's fair game internally. Regulators reject this. The mortgage unit and the auto lending unit may be the same legal entity, but the *purpose* under which the data was captured still binds it.
Concretely: if a customer's mortgage application discloses a debt-to-income ratio, that figure was collected to underwrite a mortgage. Feeding it, unconsented, into an auto-loan pricing model could violate:
1. The original privacy notice the customer received (a GLBA and CCPA issue in the US).
2. GDPR's purpose limitation principle, if any EU customer or EU-domiciled data is involved.
3. Fair lending expectations, since regulators like the CFPB scrutinize whether unconsented cross-use disproportionately affects protected groups.
This is also why "consent" is not a single checkbox. Under GDPR it must be specific, informed, and freely given, and consent for a mortgage doesn't automatically cover cross-selling an auto loan. A separate, clear opt-in is generally required for that new purpose.
Legal principles only work if they survive contact with production systems. Banks operationalize purpose limitation through purpose tagging, metadatametadataDonnées sur les données, informations décrivant le contexte, la structure, la provenance et les caractéristiques d'un asset de données (auteur, date, format, source, définition). attached to data at the point of collection that travels with it through every downstream system.
A simplified version looks like this:
customer_data_record:
customer_id: 88213
field: "monthly_income"
value: 7200
source_purpose: "mortgage_underwriting"
consent_id: "CNS-2024-0091"
allowed_uses: ["mortgage_servicing", "mortgage_risk_reporting"]
cross_product_use: false
retention_expiry: "2031-06-01"Any system, model, or analyst querying this field has to check cross_product_use and allowed_uses before ingesting it. If the auto loan pricing model's data pull doesn't filter on purpose tags, it risks silently ingesting out-of-scope data, which is exactly the failure mode auditors look for.
This is enforced through:
For a data governancedata governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.Voir la définition complète → team, purpose limitation isn't a one-time policy, it's a recurring audit cycle. Typical checks:
That last one is where many banks get caught out. A consent withdrawal recorded in a CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.Voir la définition complète → doesn't help if the machine learning feature storefeature storeA centralised repository managing ML features, ensuring consistency between training and serving environments.Voir la définition complète → refreshes weekly from a stale snapshot.
Vérification des acquis
1. A bank's mortgage servicing unit wants to share a customer's payment history with the bank's auto lending unit to price a car loan. Why does purpose limitation block this by default?
2. What is the key question purpose limitation asks, as distinguished from a simple data-access question?
3. Why does enforcing purpose limitation at a large bank require 'real engineering, not just a compliance memo'?
4. Select ALL correct answers about how purpose limitation is enforced in the US financial sector, given the absence of a single sweeping federal privacy law like GDPR.
Sélectionnez toutes les réponses correctes.
5. Select ALL correct answers about the GDPR's treatment of purpose limitation.
Sélectionnez toutes les réponses correctes.
Two live pressure points in 2026 make this more than theoretical:
Cross-selling analytics. Banks want unified customer views to recommend products. That's legitimate, but it usually requires a distinct "marketing and cross-sell" consent, separate from the "service this account" consent. Building a single customer data platformcustomer data platformA Customer Data Platform unifies customer data from all sources into persistent, actionable profiles that other systems can use.Voir la définition complète → (CDPCDPA Customer Data Platform unifies customer data from all sources into persistent, actionable profiles that other systems can use.Voir la définition complète →) without segmentingsegmentingDividing a market into distinct groups of customers who share similar needs, characteristics or behaviours, so each group can be served with a tailored approach.Voir la définition complète → by purpose is a common audit failure point.
Open banking and data sharing. Under the EU's PSD2 (Payment Services Directive 2) and its evolving successor framework, and the UK's Open BankingOpen BankingCadre réglementaire (PSD2 en Europe) obligeant les banques à partager les données clients via des API standardisées, avec consentement, transformant les données bancaires en actif compétitif. regime, customers can authorize third parties to access account data via APIs. This adds another layer: consent is now also directional (which third party) and time-bound (consents typically expire and require renewal, often every 90 days under UK Open BankingOpen BankingCadre réglementaire (PSD2 en Europe) obligeant les banques à partager les données clients via des API standardisées, avec consentement, transformant les données bancaires en actif compétitif. rules). The US is catching up through the CFPB's Section 1033 open bankingopen bankingCadre réglementaire (PSD2 en Europe) obligeant les banques à partager les données clients via des API standardisées, avec consentement, transformant les données bancaires en actif compétitif. rule, finalized in 2024, which similarly requires purpose-specific, revocable authorization for data sharing.
🎬 [VIDEO: "GDPR Explained: Purpose Limitation and Data Minimization" - youtube.com/results?search_query=gdpr+purpose+limitation+explained - search for a short explainer that walks through Article 5 principles with concrete examples, useful as a primer before applying them to banking data flows]