Financial Services

Financial services sit at the intersection of two opposing regulatory forces: data protection law (GDPR, national data protection acts) pushes toward minimization and anonymization, while financial regulation (AML directives, KYC requirements, prudential supervision) mandates retention of identifiable data for compliance, fraud detection, and regulatory reporting. No other vertical has this tension as sharply.

The regulatory collision

The core tension:

Regulation	Requires	Retention	Anonymization stance
GDPR	Data minimization, purpose limitation, storage limitation	As short as possible	Encouraged — anonymized data exits scope
EU AMLD 5/6 (Anti-Money Laundering)	Customer due diligence, transaction monitoring, suspicious activity reporting	5 years after business relationship ends (AMLD5 Art. 40); member states may extend to 10 years	Prohibited for AML data — must retain identifiable records. The new EU Anti-Money Laundering Authority (AMLA), established in Frankfurt in 2025, will select directly supervised entities in 2027 and begin direct supervision of the highest-risk cross-border institutions in 2028.
PSD2/PSD3 (Payment Services)	Strong customer authentication, transaction records	5 years (accounting directive alignment)	Permitted for analytics; prohibited for mandated records. PSD3 (political agreement Nov 2025, expected ~2027–2028) reforms payment services and open banking. The separate proposed FIDA (Financial Data Access) regulation (COM(2023)0360), part of the same legislative package but not yet adopted, would extend data sharing to broader financial products (savings, investments, pensions, insurance).
PCI-DSS v4.0.1	PAN protection, key management, access controls	As defined by business need; PAN must be unreadable when stored	Tokenization as scope reduction
DORA (Digital Operational Resilience Act)	ICT risk management, incident reporting, digital resilience testing	Per incident severity and ICT third-party risk	Effective January 2025; applies to ~22,000 financial entities. Requires ICT risk management frameworks that cover data integrity and confidentiality — anonymization of test data is one compliance lever.
Swiss FINMA / Banking Act	Banking secrecy, data governance	Per FINMA Circular 2023/1	Anonymized data exits banking secrecy scope (Module 01)
MiFID II (Markets in Financial Instruments)	Transaction reporting, record-keeping	5 years for transaction records	Prohibited for reportable transactions

The practical consequence: a financial services data platform cannot anonymize its way to compliance. KYC records, transaction monitoring data, and regulatory reporting datasets must remain identifiable for statutory retention periods. Anonymization applies to analytical layers — risk modeling, fraud pattern analysis, product development, market research — that operate on derived data, not to the operational and regulatory layers.

This shapes the zone architecture: Zone 0 (raw) and Zone 1 (pseudonymized) carry the regulatory retention burden. Zone 2 (structurally anonymized) and Zone 3 (DP outputs) serve analytics. The zones don't just differ in access controls — they differ in legal status. Premature anonymization of data subject to retention mandates is itself a compliance violation.

Engineer takeaway

In financial services engagements, the first question isn't "how do we anonymize?" — it's "which data cannot be anonymized?" Map the regulatory retention requirements before designing the anonymization pipeline. The answer determines which data flows to the analytical zones and which stays in the operational zone under access controls and pseudonymization.

Transaction anonymization for fraud detection

Fraud detection is the use case where the privacy-utility tension in finance is most acute. Effective fraud detection requires pattern recognition across transaction sequences — amounts, timing, merchant types, geographic patterns, velocity — and these patterns are the same features that make transactions identifiable.

The challenge by detection approach:

Approach	Data requirement	Anonymization-compatible?	Pattern
Rule-based detection	Threshold checks on individual transactions	Yes — rules operate on transaction attributes, not identity	Pseudonymized data in Zone 1
Supervised ML (fraud scoring)	Labeled transaction sequences	Partially — training can use pseudonymized data; inference needs identity for blocking	Train on Zone 1 data; inference in operational zone
Graph analytics (network detection)	Transaction networks linking accounts	Difficult — graph structure is the analytical value, and it's also the re-identification vector	Pseudonymized nodes + structural controls on the graph
Cross-institutional detection	Shared fraud signals across banks	Privacy-preserving techniques required	Federated learning, secure multi-party computation, or DP-aggregated signals

Cross-institutional fraud detection is the frontier. The 2024 AML package — specifically AMLR Article 75 — establishes a framework for information-sharing partnerships between obliged entities for AML purposes, but GDPR constrains how that sharing works. Three emerging patterns:

1. Federated learning. Each institution trains a local model on its own transaction data; only model gradients (not raw data) are shared with a central aggregator. The aggregated model benefits from cross-institutional patterns without any institution seeing another's transactions. This is moving from theory to practice: SWIFT ran an experimental trial with 13 global banks and Google Cloud using federated learning for cross-border fraud detection over 10 million synthetic transactions. The collaborative model was 2x more effective at identifying known fraudulent patterns compared to single-institution models. SWIFT's separate AI-enhanced Payment Controls service entered production in January 2025, but the federated learning component itself remains pre-production as of mid-2026. Privacy mechanisms include secure aggregation, Renyi DP composition on gradients (Module 04 covers composition), and encrypted model updates. The main risk: gradient leakage attacks can reconstruct individual records from shared gradients — DP on the gradients (DP-SGD) mitigates this but reduces model accuracy.

2. Secure multi-party computation (SMPC). Multiple institutions jointly compute a function (e.g., "has this account appeared in suspicious activity reports at other banks?") without revealing their individual inputs. Computationally expensive but provides strong mathematical guarantees. Practical for narrow, high-value queries — not for bulk analytics.

3. Privacy-preserving record linkage. Institutions share HMAC-hashed identifiers (using a shared key managed by a trusted third party) to detect common actors across datasets without revealing raw identities. This enables alert correlation — "this account triggered alerts at 3 banks" — without any bank seeing the other banks' customer data.

KYC/AML: where anonymization stops

Know Your Customer (KYC) and Anti-Money Laundering (AML) regulations create a hard floor beneath which anonymization cannot go. The data that must remain identifiable:

• Customer identification data — typically legal name, date of birth, address, nationality, and government-issued ID number. AMLD5 Art. 13 sets a general duty to identify and verify customers from reliable, independent sources; exact required fields vary by national transposition and supervisory guidance.
• Beneficial ownership records — for corporate clients, the natural persons who ultimately own or control the entity (25%+ ownership or significant control). Must be identifiable and verified.
• Transaction records — sufficient to reconstruct the transaction and identify the parties involved. Currently, retention periods vary by member state under AMLD5 (5 years minimum, up to 10 in some jurisdictions). The EU Anti-Money Laundering Regulation (AMLR 2024/1624), adopted but applying from July 2027, will establish a uniform 5-year retention period (Art. 77(3)) across all member states. Until then, national AMLD transpositions govern. In the US, OFAC extended blocked property record retention from 5 to 10 years as of March 2025.
• Suspicious Activity Reports (SARs) — filed with Financial Intelligence Units. Must include full identifying information. "No tipping off" rules under AML legislation restrict standard GDPR data subject notification when an investigation is active (resolution: GDPR Art. 23 restrictions on data subject rights).
• Risk assessments — customer risk profiles for AML purposes, including the data supporting the assessment. PEP (Politically Exposed Person) classifications require retention of politically sensitive categorization data.

What can be anonymized: Aggregated transaction statistics for product development, anonymized customer segments for marketing, DP-guaranteed behavioral analytics, synthetic transaction data for model training and testing.

The GDPR-AML reconciliation pattern:

• Operational KYC/AML data stays identifiable in Zone 0/Zone 1 with strict access controls, audit logging, and retention automation (auto-archive or delete after the statutory period).
• Analytical derivatives flow to Zone 2/Zone 3 with structural anonymization or DP.
• A clear data classification scheme (Module 09) labels each dataset's regulatory retention status: "AML-mandated — no anonymization; retention: 5 years post-relationship + legal hold."

Open Banking and PSD2

The revised Payment Services Directive (PSD2) introduced third-party access to customer account data through Account Information Service Providers (AISPs) and Payment Initiation Service Providers (PISPs). This creates a data sharing pipeline with built-in anonymization decisions:

• Customer-consented sharing. PSD2 requires explicit customer consent before an AISP can access their account data. The consent is granular (which accounts, which data types, for how long) and revocable.
• Data minimization at the API level. The Berlin Group's NextGenPSD2 API standard and the UK Open Banking standard define specific data fields that can be shared. Account servicing payment service providers (ASPSPs — typically banks) should return only the fields the AISP is authorized to access, not the entire account record.
• Anonymization for aggregate analytics. AISPs that aggregate data across many customers (e.g., personal finance management apps, credit scoring services) must anonymize the aggregated data if it will be used beyond the original consent scope. This is where the standard anonymization toolkit applies — DP for aggregate statistics, k-anonymity for segmentation.

The practical challenge: PSD2 APIs transmit pseudonymized but identifiable data (the AISP receives account numbers and transaction details — that's the point). The anonymization question is what happens to that data inside the AISP's platform: how is it stored, for how long, and how is it anonymized when used for purposes beyond the individual customer's service (e.g., market research, benchmarking).

Credit scoring and automated decisions

GDPR Article 22 gives data subjects the right not to be subject to decisions based solely on automated processing that produce legal or similarly significant effects — and credit scoring is the canonical example. The CJEU's December 2023 SCHUFA ruling held that credit scoring can constitute automated decision-making under Article 22 when a lender gives the score a determining role in granting, performing, or terminating a contract. In that scenario, the credit reference agency producing the score is subject to Article 22's requirements — meaningful transparency about scoring logic, right to human intervention, and right to contest the decision.

This intersects with anonymization in two ways:

1. Explainability requires traceability. If a credit application is declined based on an automated score, the individual has the right to request meaningful information about the logic involved (Art. 13(2)(f), Art. 14(2)(g)), to obtain human intervention, and to contest the decision. This means the model's inputs — the features derived from the applicant's data — must be traceable back to the decision, even if the training data was pseudonymized. Anonymization of the training pipeline cannot prevent traceability of individual inference decisions. In the US, parallel requirements exist under ECOA (principal reasons for denial must be disclosed) and FCRA (key factors affecting credit score), creating a global pattern where credit scoring models must be transparent at the individual decision level.

2. Training data anonymization. Credit scoring models can be trained on pseudonymized or anonymized historical data — the model learns patterns, not identities. But the training data must be representative (to avoid bias), and anonymization techniques that distort the data (noise, generalization) can introduce or amplify bias in the model's outputs. This is a particular concern under the EU AI Act, which classifies credit scoring as a high-risk AI system — requiring dual compliance with both GDPR transparency and AI Act requirements for risk management, data governance, human oversight, and accuracy/robustness testing. Synthetic financial data (using tools like Gretel, now part of NVIDIA's ecosystem, or K2view for entity-driven generation that preserves cross-table relationships) is the emerging pattern for training data that reduces privacy risk — but does not eliminate it or automatically solve bias. Generators can memorize source records (requiring membership inference validation), preserve under-representation from the training data, or amplify correlations that produce discriminatory outcomes. Synthetic training data requires both privacy validation (membership inference testing) and fairness/representation validation before use.

---

Next: Energy and utilities — the youngest anonymization vertical, where smart meters turned billing records into household portraits.

---

Created by Claude Opus with ❤️ for the Aliz Data Engineering team.