Financial services firms operate under the most complex intersection of regulatory obligations of any commercial sector. GDPR applies alongside a dense framework of sector-specific regulation: MiFID II requires retention of transaction records; PSD2 mandates data sharing with authorised payment service providers; AML regulations require collection and retention of identity and transaction data for extended periods; EBA and EIOPA guidelines impose their own security and data governance standards. Understanding how these frameworks interact — where they align, where they conflict, and where GDPR provides exemptions for regulatory obligations — is essential for privacy professionals working in or with financial services firms.
The Regulatory Stack: How Financial Services Rules Interact with GDPR
FINANCIAL SERVICES REGULATION — GDPR INTERACTION MAP
| Regulation | Key Data Processing Requirement | GDPR Interaction | Tension or Alignment |
|---|---|---|---|
| MiFID II (Markets in Financial Instruments) | Record all client communications (phone, email, electronic messaging) for 5–7 years; record all orders and transactions | Art. 6(1)(c) — legal obligation; MiFID II is the legal obligation that justifies processing and retention | Alignment: MiFID II provides the lawful basis and retention period; GDPR storage limitation principle is overridden by the regulatory retention requirement |
| PSD2 (Payment Services Directive 2) | Open banking: share customer payment data with authorised third-party providers (TPPs) when customer consents; strong customer authentication | Art. 6(1)(a) consent for data sharing with TPPs; SCA is a security measure aligned with Art. 32 | Partial tension: PSD2’s access-to-account requirements involve sharing financial personal data with third parties; GDPR requires this sharing to be properly characterised (controller/processor) and secured |
| AMLD (Anti-Money Laundering Directive) | Collect and verify customer identity (KYC); retain AML records for minimum 5 years; report suspicious transactions | Art. 6(1)(c) legal obligation; Art. 9(2)(g) substantial public interest for biometric or special category KYC data | Alignment: AML/KYC obligations provide lawful basis and minimum retention; tension exists around secondary use of AML data for commercial purposes (not permitted without separate basis) |
| DORA (Digital Operational Resilience Act) | Operational resilience for financial entities; ICT risk management; incident reporting; third-party ICT provider oversight | Substantial overlap with Art. 32 security requirements; DORA’s incident reporting obligations overlap with Art. 33 breach notification | Alignment: DORA and GDPR security requirements are complementary; DORA adds prescriptive ICT risk management obligations on top of GDPR’s risk-based standard |
| EBA Guidelines (various) | EBA guidelines on outsourcing, ICT and security risk management, and remote customer onboarding set specific operational standards | EBA security standards are consistent with Art. 32 ‘state of the art’; remote onboarding guidelines address identity verification data processing | Alignment: EBA guidelines provide sector-specific interpretation of Art. 32; compliance with EBA guidelines is strong evidence of Art. 32 compliance |
| GDPR (as a financial sector obligation) | All processing of customer, employee, and third-party personal data must comply with GDPR principles | GDPR applies as a general law; financial sector regulations provide specific lawful bases (Art. 6(1)(c)) but do not exempt firms from all GDPR obligations | Compliance with sector regulation does not exempt from GDPR transparency, rights, and accountability obligations |
The Data Minimisation vs. Regulatory Retention Tension
One of the most practical tensions in financial services GDPR compliance is between GDPR’s storage limitation principle — retain data only as long as necessary for the purpose — and sector-specific regulations that mandate minimum retention periods. These two requirements are reconcilable, but only with a carefully designed retention schedule that distinguishes between regulatory retention obligations and commercial convenience.
RETENTION APPROACH FOR COMMON FINANCIAL DATA TYPES
| Data Type | Regulatory Retention Requirement | GDPR Approach | Key Risk |
|---|---|---|---|
| Client identity and KYC records | 5 years from end of business relationship (AMLD); can extend to 10 years | Art. 6(1)(c) provides lawful basis for retention; retain for regulatory period, then delete | Retaining KYC data beyond regulatory period for commercial purposes without separate basis |
| Transaction records | MiFID II: 5 years; some products up to 7 years; PSD2 payment records: 5 years | Art. 6(1)(c) provides retention basis; data may not be used for secondary purposes beyond the regulatory obligation | Using retained transaction data for marketing analytics without separate consent or LIA after the commercial relationship ends |
| Investment suitability assessments | MiFID II: 5 years; records of basis for advice | Art. 6(1)(c); retain for regulatory period; delete after regulatory period unless ongoing client relationship | Retaining assessment data longer than required and repurposing for upselling without new basis |
| Client communications (MiFID II) | MiFID II: 5–7 years depending on instrument type | Art. 6(1)(c); bulk communications retention system; access strictly limited to compliance and legal | Communications systems retaining data beyond MiFID II period; communications accessed for purposes other than compliance review |
| Complaint records | FCA (UK): 3 years; varies by EEA regulator | Art. 6(1)(c); retain for regulatory period; data subject rights apply to complaint data subject to legal proceedings exemption | Complaint data used to profile customers for commercial purposes without consent |
| Credit assessment data | Credit bureau data retention varies; internal credit models: as needed for relationship | Art. 6(1)(b) contract; or Art. 6(1)(c) where regulatory; LIA for internal credit modelling | Special category data (e.g. health data in credit assessment) without Art. 9 basis; automated decisions without Art. 22 safeguards |
KYC/AML Data: Special Considerations
Anti-money laundering legislation requires financial institutions to collect substantial personal data to verify customer identity and assess financial crime risk. This data — identity documents, politically exposed person status, sanctions screening results, beneficial ownership information — often includes special category data (such as nationality, which is linked to racial or ethnic origin) and involves systematic automated screening. The GDPR obligations for this processing require careful attention.
KYC/AML DATA — GDPR COMPLIANCE REQUIREMENTS
| KYC/AML Processing | Lawful Basis | Specific Obligation | Common Compliance Gap |
|---|---|---|---|
| Customer identity verification | Art. 6(1)(c) legal obligation (AML Directive implementation) | Privacy notice must explain AML processing purpose; data minimised to what AML law requires | Notice does not explain AML processing; data collected beyond what AML requires (e.g. collecting ethnic origin for credit scoring, not AML) |
| PEP and sanctions screening | Art. 6(1)(c); Art. 9(2)(g) for special category data involved (nationality, political opinions) | Transparency about automated screening; Art. 22 compliance if decisions based solely on automated screening have significant effects | Automated adverse decision (account refusal, transaction blocking) made solely on automated screening without human review |
| Transaction monitoring | Art. 6(1)(c) legal obligation; Art. 6(1)(f) LI for fraud prevention | LIA required where legitimate interests relied on for monitoring beyond regulatory minimum; data subjects informed of monitoring | Monitoring extends beyond regulatory minimum without LIA; employees’ transactions monitored without adequate notice |
| Suspicious activity reporting | Art. 6(1)(c); Art. 9(2)(g) where special category data involved | Tipping-off rules under AML law restrict disclosure to data subject that report has been made; privacy notice should explain this without breaching tipping-off prohibition | Awkward interaction between GDPR transparency and AML tipping-off; notice should acknowledge possibility of regulatory reporting without specifics |
Privacy Governance for Financial Services
Financial services regulators — particularly in the UK and EU — increasingly assess data governance as part of their supervisory activities. The PRA and FCA in the UK, and EIOPA, EBA, and ESMA in the EU, expect financial firms to have documented data governance frameworks. These expectations align substantially with GDPR’s accountability principle, but the audience is different: financial regulators care about operational risk and customer outcomes, not primarily about data subjects’ rights.
FINANCIAL SERVICES PRIVACY GOVERNANCE STRUCTURE
| Governance Element | GDPR Requirement | Financial Regulator Expectation | Unified Approach |
|---|---|---|---|
| Data protection officer | DPO mandatory for large-scale processing or special category data; most financial firms will require a DPO | Senior privacy or data governance officer expected; often combined with CISO or CCO function | Designate DPO with appropriate independence; clearly separate DPO function from compliance functions that create conflicts |
| Data governance committee | No explicit GDPR requirement; implied by accountability principle for complex organisations | Data governance or data management committee expected; oversight of data quality, access, and risk | Combined data governance and privacy committee; DPO on committee; reports to board risk committee |
| Privacy risk in operational risk framework | GDPR risk assessment (Art. 32) and DPIA (Art. 35) required | Financial regulators include data and cyber risk in operational risk appetite frameworks | Map GDPR privacy risks into operational risk framework; DPIA findings fed into risk register; DPA enforcement risk in risk appetite statement |
| Staff training | Data protection training required for all staff processing personal data | Financial regulators require training on AML, market conduct, and data governance | Combined AML/conduct/privacy training module; role-specific deep-dive for compliance, customer-facing, and technology staff |
| BITLION INSIGHT | The most effective financial services privacy programmes are those that have genuinely integrated GDPR compliance into the existing regulatory compliance framework rather than treating it as an additional standalone obligation. GDPR’s accountability principle is a natural fit with the Senior Managers and Certification Regime’s culture of documented accountability. The DPO’s evidence portfolio maps naturally onto the compliance monitoring framework that financial regulators already expect. Firms that have built this integration — rather than running parallel frameworks — consistently maintain higher compliance standards at lower cost. |