Leaders Insights
Leaders Insights

Stay at the top of your field, a little every day.

DomainsMarketingDataFinanceAI
ResourcesLearnTestToolsBlogGlossary
© 2026 Leaders Insights — All rights reserved.
Tracks/Data in fintech/Governance, privacy and checks/the regulatory map every fintech data leader must carry
1/4+150 XP

Governance, privacy and checks

10the regulatory map every fintech data leader must carry+15011privacy by design in payment and lending products+15012running a data governance audit that regulators respect+15013handling breaches, subject requests and regulator inquiries+150

the regulatory map every fintech data leader must carry

# The Regulatory MapMapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → Every Fintech Data Leader Must Carry

A single customer record, say, Maria in Berlin who uses a US-headquartered neobank with a UK payments partner, can simultaneously trigger obligations under four or five overlapping data laws the moment she taps "confirm" on a transaction. Her name, IBAN, spending history, and device fingerprint each fall under different jurisdictions, different consent rules, and different deletion timelines. This is not an edge case. It is the default architecture of modern fintech.

This lesson gives you the mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition →: the core regulations, where they conflict, and the practical checks you run to survive an audit without freezing your product roadmap.

The Five Regimes You Must Know Cold

GDPR (General Data Protection Regulation), EU law effective 2018, governs any personal data of EU residents, regardless of where your company is based. Core mechanics: lawful basis for processing, the right to erasure ("right to be forgotten"), data portability, and mandatory breach notification to regulators within 72 hours. Enforced by national Data Protection Authorities (DPAs), coordinated loosely under the European Data Protection Board.

PSD2 (Revised Payment Services Directive), EU directive from 2018, mandates open banking: banks must expose customer account data to licensed third parties via APIs, if the customer consents. It created the legal basis for account aggregators like Tink (acquired by Visa) and Plaid's European operations. PSD2 also mandates Strong Customer Authentication (SCA), two-factor verification on most online payments.

GLBA (Gramm-Leach-Bliley Act), US federal law from 1999, requires financial institutions to explain information-sharing practices and safeguard nonpublic personal information (NPI). Enforced by the FTC and prudential banking regulators (OCC, Federal Reserve, FDIC). GLBA is notice-based, not consent-based: institutions can share data with affiliates by default unless the customer opts out.

CCPA / CPRA (California Consumer Privacy Act, amended by the California Privacy Rights Act), effective 2020 and 2023 respectively, gives California residents rights to know, delete, and opt out of the "sale or sharing" of personal data. Enforced by the California Privacy Protection Agency (CPPA). Notably, GLBA-regulated data is largely exempt from CCPA, a carve-out that trips up compliance teams who assume US privacy law is uniform.

Open banking rules outside the EU: the UK runs its own regime post-Brexit via the Open Banking Implementation Entity, and the US has moved from voluntary frameworks toward a binding one under Section 1033 of the Dodd-Frank Act, with the Consumer Financial Protection Bureau (CFPB) finalizing rules on consumer data access starting 2024. Coverage and enforcement timelines still differ meaningfully from the EU's PSD2/PSD3 trajectory.

Where They Collide on One Record

Go back to Maria. Here is the collision mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → for her single transaction record:

  • Consent model mismatch: GDPR requires affirmative opt-in consent for most processing. GLBA defaults to opt-out. If your platform serves both US and EU customers from one data pipelinedata pipelineETL (Extract, Transform, Load) is a data integration process that pulls data from sources, reshapes it into a consistent format, and writes it into a target system.View full definition →, you cannot use a single consent flag. You need jurisdiction-aware consent state per record.
  • Deletion conflicts: GDPR's right to erasure says delete on request. But financial recordkeeping rules (in the EU, anti-money laundering directives; in the US, Bank Secrecy Act requirements enforced by FinCEN) mandate retaining transaction records for five to seven years. Your data architecture must support "soft delete with legal hold," not true deletion, and you must be able to explain that distinction to a regulator or an angry customer.
  • Third-party access under open banking: PSD2 forces you to expose Maria's account data to any licensed third-party provider (TPP) she authorizes. GDPR still makes you the data controller responsible for what happens to that data afterward. If the TPP mishandles it, regulators may still look at you for the initial exposure and consent design.
  • Cross-border transfer: If Maria's data touches a US-based cloud region (common with AWS, GCP, Azure global architectures), GDPR's rules on international transfers apply. Post the *Schrems II* ruling (2020, Court of Justice of the EU), Standard Contractual Clauses and, since 2023, the EU-US Data Privacy Framework are the main legal mechanisms. Get this wrong and your entire US-hosted analytics stack is a liability. Reference: the European Commission's overview of the Data Privacy Framework.

The Architecture Tradeoffs This Forces

Because these rules do not harmonize, data leaders make deliberate architecture calls:

1. Data residency partitioning: many fintechs run EU customer data in EU-region cloud infrastructure (data localization) even when technically not always mandatory, simply to reduce transfer-mechanism risk and audit complexity.

2. Consent as a first-class data object: consent state (who, what purpose, what jurisdiction, timestamp, version of policy accepted) gets modeled as its own auditable table, not a boolean flag buried in a user profile.

3. Field-level, not table-level, governance: NPI under GLBA, special category data under GDPR (which includes things like biometric identifiers), and CCPA's "sensitive personal information" category do not mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → to identical field lists. Tagging must happen at the column or field level with jurisdiction metadata attached.

A simplified schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → for how this looks in practice:

sql
-- consent_ledger: one row per consent event, not per user
CREATE TABLE consent_ledger (
    consent_id UUID PRIMARY KEY,
    customer_id UUID NOT NULL,
    jurisdiction VARCHAR(10) NOT NULL,   -- 'EU', 'US-CA', 'US-FED', 'UK'
    legal_basis VARCHAR(50) NOT NULL,    -- 'GDPR_ART6_1A', 'GLBA_OPT_OUT', 'CCPA_OPT_OUT'
    purpose VARCHAR(100) NOT NULL,       -- 'MARKETING', 'OPEN_BANKING_SHARE'
    granted_at TIMESTAMP,
    revoked_at TIMESTAMP,
    policy_version VARCHAR(20)
);

This is not decoration. Auditors and regulators will ask "show me consent for this specific processing purpose, at this date, for this customer." If that query takes a data engineer three days of log archaeology, you have a governance failure.

Knowledge check

1. Why does a single customer transaction like Maria's typically trigger multiple, overlapping data regulations simultaneously?

2. What is the key structural difference between how GDPR and GLBA treat data sharing?

3. A US-based fintech with no EU offices processes payment data for a customer who is an EU resident. Under GDPR's scope rules, what determines whether GDPR applies?

MULTIPLE CHOICE

4. Select ALL correct answers about PSD2's core requirements.

Select all the correct answers.

MULTIPLE CHOICE

5. Select ALL correct answers about why a fintech data leader needs a 'regulatory map' rather than treating each law separately.

Select all the correct answers.

The Practical Checks You Run

Sector fluency means knowing what a real audit or internal control cycle looks like, not just naming the laws.

Quarterly data mapping audit: maintain a live Record of Processing Activities (ROPA), a GDPR-mandated inventory of what personal data you hold, why, where it's stored, and who can access it. Most mature fintechs automate this with data catalogdata catalogA centralized inventory of an organization's data assets, enriched with metadata, that helps people find, understand, and trust the data they need.View full definition → tools (e.g., Collibra, Alation) rather than spreadsheets.

Access control review: verify least-privilege access to NPI and special category data. A common finding in audits: customer support staff with broad SQLSQLSales Qualified Lead: a prospect the sales team has validated as ready for direct outreach and a proposal, having passed clear qualification criteria.View full definition → access to production tables they do not need for their role.

Breach simulation / incident response drill: GDPR's 72-hour notification clock starts at awareness, not confirmation. Run tabletop exercises to check whether your team can actually detect, scope, and draft a notification within that window.

Third-party API risk review: under PSD2 and CFPB open banking rules, audit which TPPs have live access tokenstokensA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.View full definition →, when consent expires, and whether revocation actually propagates through your systems, not just your database.

Cross-border transfer inventory: list every system where EU personal data leaves EU infrastructure, and confirm the legal transfer mechanism is current (the EU-US framework has already survived legal challenges but remains contestable).

For a regulator-facing overview of enforcement patterns, the ICO's (UK Information Commissioner's Office) enforcement action library is a genuinely useful, free source of real cases, useful for pattern-spotting on what actually gets fined.

Open Banking Explained

Watch on YouTube

Key Takeaways

  • No single global privacy framework governs fintech data. GDPR, PSD2, GLBA, and CCPA/CPRA operate on different logics (consent vs. notice, deletion vs. retention) and a single customer record can be subject to all four at once.
  • Deletion requests under GDPR must be reconciled with financial recordkeeping mandates (AML, Bank Secrecy Act); the practical answer is soft delete with legal hold, not true erasure.
  • Consent should be modeled as an auditable, jurisdiction-tagged data object, not a single flag, because regulators will ask for purpose-specific, time-stamped proof.
  • Cross-border data transfers (especially EU to US cloud infrastructure) require an active legal mechanism (SCCs or the EU-US Data Privacy Framework) that must be tracked and periodically reverified.
  • Run recurring, concrete checks: ROPA data mapping, access control reviews, breach drills, and TPP access audits, since these are what actual examiners and DPAs test first.

Next

privacy by design in payment and lending products