Data privacy and open finance: GDPR, CCPA and data-sharing consent, MBA Training, MBA Training
4/5+150 XP
Data privacy and open finance: GDPR, CCPA and data-sharing consent
# Data privacy and open finance: GDPR, CCPA and data-sharing consent
A user connects their bank account to a budgeting app. Behind that one click, the app has just triggered obligations under at least two major privacy regimes, a bank-data access rule, and possibly a sector-specific consent standard, depending on where the user lives. If the user later says "delete my data," the aggregator has 45 days (or less) to prove it actually did. This is the operational reality of open finance in 2026: consent is not a checkbox, it is a compliance system.
Why aggregators sit at the center of this lesson
Account aggregators (Plaid, MX, Yodlee, Tink in Europe) pull transaction data from banks via APIs (application programming interfaces, the technical channels banks expose for data access) and pass it to fintech apps: budgeting tools, lenders, robo-advisors.
They are "data controllers" or "data processors" under GDPR depending on their role, meaning they either decide how data is used (controller) or act on someone else's instructions (processor). That distinction determines who is legally on the hook when something goes wrong.
GDPR: the European baseline
GDPR (General Data Protection Regulation), enforced since 2018 by national Data Protection Authorities (DPAs, such as Ireland's DPC or France's CNIL) under the coordination umbrella of the European Data Protection Board, sets the global reference standard for consent.
Core requirements relevant to fintech aggregators:
Lawful basis for processing. Consent is only one of six legal bases. For account aggregation, most EU fintechs rely on "explicit consent" or "contractual necessity," and regulators expect them to document which one applies to each .
data flowdata flowAn automated sequence of steps that moves data from source to destination: ingestion, transformation, validation, and loading, so it arrives clean and ready to use.Voir la définition complète →
Consent must be freely given, specific, informed, and unambiguous. A pre-ticked box does not qualify. Bundling "agree to share transaction data" with "agree to marketing emails" in one checkbox is a common violation.
Right to erasure ("right to be forgotten"). Users can demand deletion, though banks can retain some records for anti-money-laundering purposes under separate law, creating a real tension aggregators must engineer around.
Data minimization. Collect only what's needed. An aggregator pulling five years of transaction history to approve a loan when the lender's model only uses 12 months is a minimization failure.
Data portability (Article 20): users can request their data in a "structured, commonly used, machine-readable format" and move it to a competitor.
Fines can reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.Voir la définition complète → €20 million or 4% of global annual revenue, whichever is higher. Meta and Amazon have both received fines in the hundreds of millions for GDPR violations; a mid-size fintech would face proportionally smaller but still material penalties.
CCPA and CPRA: California's parallel track
The CCPA (California Consumer Privacy Act, 2018) and its 2023 amendment the CPRA (California Privacy Rights Act) give California residents rights enforced by the California Privacy Protection Agency (CPPA).
Key differences from GDPR that matter operationally:
CCPA is opt-out by default for data sale/sharing, not opt-in consent like GDPR. A US fintech doesn't need affirmative consent to process data, but must let users say "don't sell my data."
Right to delete exists but with more carve-outs for financial and legal-compliance records than in the EU.
CCPA applies based on revenue and data-volume thresholds (roughly, businesses with over $25 million in annual revenue, or handling data on 100,000+ consumers/households). A small fintech startup may be exempt; a scaled one is not.
There is no single US federal privacy law equivalent to GDPR. Other states (Virginia's VCDPA, Colorado's CPACPACost Per Acquisition: the total cost to generate one customer or conversion, computed by dividing total spend by the number of acquisitions.Voir la définition complète →) add overlapping but non-identical rules, so a US-only fintech still faces a patchwork.
Practical consequence: an aggregator serving both EU and California users typically builds to the stricter GDPR standard globally and layers CCPA-specific mechanics (a "Do Not Sell or Share My Personal Information" link) on top, rather than running two separate systems.
Open finance and data portability rules
Beyond general privacy law, dedicated open banking / open finance rules govern account-linking specifically.
Europe:PSD2 (the second Payment Services Directive) requires banks to provide regulated third-party providers secure APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Voir la définition complète → access to account data, when the customer consents. The EBA (European Banking Authority) sets the technical standards (strong customer authentication, secure communication). PSD3, under negotiation as of 2025-2026, aims to replace screen-scraping entirely with standardized APIs.
United States: the CFPB (Consumer Financial Protection Bureau) finalized its Section 1033 personal financial data rights rule (issued 2024) under the Dodd-Frank Act, requiring banks to give consumers, and their authorized third parties like aggregators, access to their own financial data in a standardized, machine-readable format, largely free of charge. As of 2026 this rule is being phased in and has faced legal and political challenges from bank trade groups, so timelines remain fluid; check the CFPB's official rule page for current status.
UK: the Open Banking Implementation Entity framework, now transitioning into the broader Smart Data scheme, plays a similar role post-Brexit.
The common thread: consent to share data must be specific (not blanket), revocable (users can disconnect access anytime), and time-limited (many regimes cap standing consent at 90 days before re-authorization is required).
How this shapes actual product engineering
A compliant account-linking consent flow typically needs:
1. A consent screen naming the exact data categories requested (balances, transaction history, account holder name), not a generic "allow access" button.
2. A consent ledger: an internal, auditable record of what was consented to, when, and its expiry, so the company can prove compliance if a regulator asks.
3. A deletion pipeline that propagates erasure requests across every downstream system, including analytics warehouses and ML training sets, not just the primary database.
4. Re-authentication triggers that expire stale consent automatically.
This is not throwaway 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).: it's the artifact a DPA or the CFPB will ask to see during an examination.
Vérification des acquis
1. Under GDPR, what legally determines whether an account aggregator is classified as a 'data controller' versus a 'data processor'?
2. A fintech app presents users with a single checkbox that says 'I agree to share my transaction data and receive marketing emails.' Why does this likely violate GDPR consent standards?
3. Why might an EU fintech aggregator choose to rely on 'contractual necessity' rather than 'explicit consent' as its lawful basis for processing certain transaction data?
CHOIX MULTIPLES
4. Select ALL correct answers about the role of Data Protection Authorities (DPAs) and the European Data Protection Board under GDPR.
Sélectionnez toutes les réponses correctes.
CHOIX MULTIPLES
5. Select ALL correct answers about why GDPR's consent requirements create operational challenges for account aggregators like Plaid or Tink.
Sélectionnez toutes les réponses correctes.
Where this gets hard: cross-border and third-party risk
Aggregators rarely operate in one jurisdiction. A neobank headquartered in the US, using a European core banking partner, serving customers who move between the UK and EU, must reconcile GDPR, UK GDPR (a near-identical but separately enforced regime post-Brexit), CCPA-style state laws, and PSD2/PSD3 simultaneously.
Third-party risk compounds this: if a fintech's outsourced KYC (Know Your Customer) vendor mishandles data, the fintech itself, as the controller, generally remains liable under GDPR. This is why regulators increasingly expect documented vendor due diligence and data processing agreements (DPAs, not to be confused with Data Protection Authorities) with every subcontractor touching personal data.
🎬 [VIDEO: "GDPR Explained in Simple Terms" - https://www.youtube.com/results?search_query=gdpr+explained+simple+terms - a plain-language walkthrough of consent, lawful basis, and enforcement mechanics useful for non-technical learners]
GDPR requires opt-in, specific, revocable consent and gives users erasure and portability rights; CCPA/CPRA default to opt-out and focus on sale/sharing disclosures, so global fintechs typically build to the stricter GDPR standard and layer state-specific mechanics on top.
Open finance access rules (PSD2/PSD3 in Europe, Section 1033 in the US via the CFPB, Smart Data in the UK) are distinct from general privacy law: they specifically mandate that banks expose account data to authorized third parties through secure, standardized APIs.
Compliant account-linking requires engineering, not just legal policy: consent ledgers, expiring authorizations, and deletion pipelines that reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.Voir la définition complète → every downstream data store, including analytics and ML training data.
Liability follows the data, not the org chart: aggregators and controllers generally remain accountable for third-party vendors' privacy failures.
US federal privacy and open-banking rules are still consolidating as of 2026; check the CFPB and EBA directly for current implementation status before assuming a rule is fully in force.