GDPR for Fintech: Data Protection Requirements, Fines, and Compliance Checklist

Fintech companies occupy an uncomfortable position under GDPR. They process personal data at the scale of a technology platform — millions of user records, real-time transaction data, behavioural analytics — but the underlying activities are financial services, which carry their own data retention mandates under AML/CFT law, banking regulation, and tax rules. Those two frameworks frequently conflict.

Add automated credit scoring, algorithmic fraud detection, and open banking data sharing to the mix, and you have some of the most complex GDPR compliance challenges in any industry. This guide covers the specific rules that matter most for fintech — not the generic GDPR overview, but the provisions that actually drive fines and enforcement actions in this sector.

Why Fintech Faces Unique GDPR Challenges

Several characteristics of fintech business models create disproportionate GDPR exposure:

• Scale of processing: A neobank with 3 million users processes hundreds of millions of transactions annually. Every transaction involves personal data. The risk profile of a data breach or unlawful processing scales with that volume.
• Sensitive data categories: Financial data — transaction history, credit behaviour, account balances — is not technically a "special category" under GDPR Article 9, but it is highly sensitive in practice and subject to elevated expectations from supervisory authorities. Financial data that reveals health conditions (pharmacy transactions, addiction services) may trigger Article 9 obligations.
• Automated decision-making: Credit scoring, fraud detection, and loan approval are commonly automated. GDPR Article 22 imposes specific obligations on decisions made by automated means that produce legal or similarly significant effects, including the right to human review.
• Open banking data flows: Under PSD2, third-party providers (TPPs) access account data via APIs. Each data sharing event creates GDPR obligations — the account servicing payment service provider (ASPSP) and the TPP are separate data controllers with independent obligations.
• Retention conflicts: AML regulations (AMLD6) require transaction data retention for 5-10 years. GDPR's storage limitation principle requires data to be kept no longer than necessary. Resolving this tension requires explicit legal basis analysis for retention beyond the transactional period.

Lawful Bases for Financial Data Processing

Choosing the correct lawful basis under GDPR Article 6 is the foundational compliance decision for fintech. The wrong basis — or relying on consent where another basis applies — creates downstream problems for withdrawal of consent, erasure requests, and portability rights. In fintech, the most relevant bases are:

Contractual Necessity (Article 6(1)(b))

Processing is lawful where necessary to perform a contract with the data subject or to take steps at their request prior to entering a contract. For fintech, this is the primary basis for: account opening and KYC, transaction processing, payment execution, account maintenance, and credit assessment where the product is a loan or credit facility.

The key constraint: processing must be necessary for the contract, not merely useful or convenient. The European Data Protection Board (EDPB) Opinion 6/2020 clarified that "necessary" means the processing is objectively required for the contract to function — not that the controller would like to use the data for that purpose. Behavioural analytics for marketing purposes do not satisfy contractual necessity, even if the user has a product contract.

Legal Obligation (Article 6(1)(c))

Processing required to comply with EU or member state law is lawful. For fintech, this covers: AML transaction monitoring, suspicious activity reporting, sanctions screening, PSD2-required information disclosure, CRS/FATCA tax reporting, and record retention under financial regulation. This basis is important because it provides a robust legal foundation for retaining data beyond the contractual period — you cannot erase data that you are legally required to retain.

Legitimate Interests (Article 6(1)(f))

Processing is lawful where necessary for the legitimate interests of the controller or a third party, except where overridden by the data subject's interests or rights. Fintech commonly uses legitimate interests for: fraud prevention beyond AML obligations, internal analytics and product improvement, security monitoring, and credit risk management for existing customers.

Legitimate interests requires a three-part balancing test: (1) identify the legitimate interest; (2) assess whether processing is necessary to pursue it; (3) balance the interest against the data subject's interests, rights, and freedoms. The balancing test must be documented. Regulators increasingly require controllers to demonstrate the test was genuinely conducted, not just asserted.

When NOT to Use Consent

Fintech companies frequently make the mistake of using consent as a catch-all basis, particularly for marketing. GDPR consent in a fintech context is problematic because: the power imbalance between customer and financial services provider makes consent freely given harder to demonstrate; withdrawal of consent cannot be restricted without a legal obligation or contractual necessity basis; and grandfathered pre-GDPR consent is likely invalid.

Data Subject Rights in Financial Services Practice

GDPR Articles 15-22 create a suite of rights that fintech companies must operationalise. Financial services creates specific tensions for three of them:

Right of Access (Article 15)

Customers can request a copy of all personal data held about them. In fintech, this typically means: all transaction records, communications, credit assessment data, fraud flags, profiling outputs, and internal notes. The obligation is to provide a complete copy — partial responses are a common enforcement focus. The one-month response deadline applies regardless of data volume, and a further two-month extension is only available for complex or numerous requests.

Right to Erasure (Article 17) vs. Retention Requirements

This is the most operationally complex area for fintech. A customer requests deletion of their data after closing their account. GDPR Article 17 gives them a right to erasure. AML Directive Article 40 requires five-year retention of transaction records. These obligations conflict directly.

The resolution: Article 17(3)(b) creates an exception to the right of erasure where retention is necessary for compliance with a legal obligation. Fintech companies must document, for each category of retained data: the specific legal obligation requiring retention, the retention period, and confirmation that data is not processed for any other purpose during retention. Blanket "we retain for legal compliance" policies are insufficient — regulators expect category-level documentation.

Right to Data Portability (Article 20)

Portability under GDPR Article 20 overlaps with PSD2's account data access rights under AISP (Account Information Service Provider) frameworks. The data subject can request their data in a structured, machine-readable format — transaction history, account information, profiling data provided by the customer — for transfer to another controller. For fintech, DORA's operational resilience requirements (see our DORA compliance guide) interact with portability: data formats must be maintained consistently enough to support portability requests over time.

When Fintech Must Appoint a DPO

GDPR Article 37 mandates a Data Protection Officer for: public authorities; controllers/processors whose core activities require large-scale, regular and systematic monitoring of data subjects; and controllers/processors whose core activities involve large-scale processing of special category data.

For fintech, the "large-scale regular and systematic monitoring" trigger is particularly relevant. Credit scoring, transaction monitoring for fraud, behavioural analytics for product personalisation, and AML monitoring all constitute systematic monitoring. The EDPB's guidelines on DPOs (WP243) indicate that a bank or payment processor of significant scale will almost always meet this threshold.

Practical DPO requirements: the DPO must have expert knowledge of data protection law; must be provided with adequate resources; must have access to the highest management level; must not receive instructions regarding the exercise of their tasks; and must not be dismissed or penalised for performing their tasks. Appointing a junior lawyer as DPO with no independence is a common compliance gap that regulators have specifically cited in enforcement decisions.

Cross-Border Data Transfers

Fintech commonly transfers data internationally — to cloud providers, payment network processors, fraud screening services, and parent companies. Post-Schrems II (Case C-311/18, 2020), international transfers require either an adequacy decision for the destination country or appropriate safeguards under GDPR Article 46.

The current transfer mechanism landscape:

For US cloud providers (AWS, GCP, Azure), the EU-US DPF provides a streamlined mechanism for DPF-certified providers. However, NOYB has indicated an intent to challenge the DPF as it challenged Privacy Shield. Fintech companies should maintain SCCs as a backup even for DPF-covered transfers.

GDPR Enforcement Trends in Fintech

GDPR enforcement against financial services firms has accelerated since 2022. Key cases relevant to fintech:

• N26 (Germany, BaFin/BerlinDPA): The neobank faced both AML enforcement (€4.25M in 2021) and separate data protection investigations related to identity verification processing. The combination of regulatory scrutiny illustrates the intersection of AML and GDPR in fintech specifically.
• Revolut (Lithuania VDAI, 2023): Investigated for its use of customer data for credit risk modelling, specifically whether legitimate interests adequately justified profiling for credit purposes. The case highlighted the importance of documented balancing tests.
• Clearview AI (multiple DPAs, 2022-2023): Fined across multiple EU jurisdictions for biometric data processing. While not a traditional fintech, the case established that facial recognition data used in financial KYC processes is special category data requiring explicit consent or substantial public interest justification.
• Meta (Ireland DPC, 2023): The €1.2 billion fine for unlawful US data transfers under the previous Privacy Shield mechanism created the strongest possible signal to any company relying on a challenged transfer mechanism — do not wait for a legal challenge to resolve before implementing backup safeguards.

GDPR and PSD2/Open Banking Intersection

The intersection of GDPR and PSD2 creates compliance complexity that neither regulation addresses fully. The key tensions:

Consent under PSD2 vs. GDPR consent: PSD2 requires explicit customer consent for TPP access to account data. That consent is both a PSD2 authorisation and a GDPR processing basis. However, withdrawal of PSD2 consent by revoking API access doesn't automatically trigger GDPR erasure — the TPP may have a separate legitimate interests or contractual necessity basis for retaining data already processed. The EDPB Opinion 9/2023 on PSD2 and GDPR addressed this but left several open questions.

Data minimisation vs. open banking utility: Account data accessed via AISP is intended to be used for a specific purpose (account aggregation, financial management). Using that data for credit scoring, marketing profiling, or other secondary purposes requires a separate lawful basis under GDPR's purpose limitation principle — the original PSD2 consent does not carry over. Our coverage of fintech regulatory compliance provides broader context on how PSD2 and GDPR interact operationally.

GDPR Compliance Checklist for Fintech

The following 10 items represent the minimum baseline for fintech GDPR compliance in 2026. Each should be documented and auditable:

1. Records of processing activities (RoPA): Article 30 requires a complete register of all processing activities. For fintech, this means every category of customer data, the lawful basis for each, retention periods, and international transfers.
2. Lawful basis documentation per processing activity: Every processing activity in the RoPA must have a documented lawful basis — not a generic assertion but a specific analysis for each purpose.
3. Data subject request process: A documented, tested process for handling SARs, erasure requests, portability requests, and objections — with SLAs that meet GDPR deadlines.
4. DPO appointment decision: Either a DPO has been appointed (with documented independence and resources) or there is a documented legal analysis concluding DPO appointment is not required.
5. Privacy notices: Layered, plain-language privacy notices at each data collection point. Financial services-specific notices must address automated decision-making and profiling explicitly.
6. DPIA programme: Data Protection Impact Assessments for high-risk processing — credit scoring, fraud detection, identity verification, large-scale behavioural analytics.
7. Processor agreements (DPAs): Article 28 agreements with every data processor — cloud providers, payment processors, fraud screening vendors, KYC/AML service providers.
8. International transfer safeguards: For each non-EEA country receiving personal data, a documented transfer mechanism (adequacy decision, SCCs, BCRs) plus Transfer Impact Assessment where required.
9. Breach response plan: A documented incident response plan including the 72-hour notification obligation to the lead supervisory authority for personal data breaches under Article 33.
10. Annual review cadence: Scheduled review of RoPA, privacy notices, DPIAs, and transfer mechanisms — not set-and-forget. EDPB guidance and national DPA decisions regularly update interpretation.