Case Study 5.2: GDPR Meets AML — The Data Architecture Conflict
The Situation
Organization: Cornerstone Financial Group (fictional) Context: Cornerstone's European subsidiary (Cornerstone Capital Markets, UK-regulated) faces a legal conflict between GDPR data minimization requirements and AML data retention obligations Stakeholders: Legal, Compliance, Data Privacy, IT Priya's role: External advisor brought in to help resolve the conflict
The Conflict
Cornerstone Capital Markets had, in 2022, implemented a comprehensive GDPR compliance program. One of its core commitments was data minimization: collecting only the personal data necessary for specified purposes, and retaining it only for as long as necessary.
In 2024, Cornerstone's Data Privacy Officer received a request from a customer — a high-net-worth individual from Belgium — to exercise his right to erasure under GDPR Article 17. The customer, who had closed all his accounts with Cornerstone two years earlier, requested that all personal data about him be deleted from Cornerstone's systems.
The DPO's initial instinct was to comply. The customer had a legitimate basis for the request (no active accounts, no ongoing contractual relationship), and GDPR Article 17 creates a right to erasure in exactly this situation.
The compliance team's immediate response: "We can't delete this."
The reason: Cornerstone's AML program retained comprehensive transaction records, KYC documentation, and suspicious activity monitoring data on all customers for a minimum of five years from the end of the business relationship — required by the UK's Money Laundering, Terrorist Financing and Transfer of Funds (Information on the Payer) Regulations 2017 (the MLRs).
This was not a close call on the AML side. The five-year retention requirement exists specifically so that transaction records are available for law enforcement investigation if criminal activity is subsequently identified. Deleting them in response to a data subject access request would create criminal liability.
But GDPR's right to erasure was equally real. The DPO needed a principled approach — not just for this case, but for all future erasure requests.
Priya's Analysis
Priya was called in three weeks after the request was received, by which point it had become a live legal dispute between the DPO and the compliance function. The customer had escalated to the ICO (Information Commissioner's Office) when Cornerstone failed to respond within GDPR's one-month deadline.
Priya's analysis proceeded in three stages:
Stage 1: Legal precedence mapping
Priya's first task was to establish the legal precedence clearly. GDPR Article 17(3) explicitly provides that the right to erasure does not apply where processing is "necessary for compliance with a legal obligation." The MLRs five-year retention requirement was precisely such a legal obligation.
This resolved the immediate case: Cornerstone was legally required to retain the data and was entitled to refuse the erasure request on the basis of the MLR obligation.
But the customer was also entitled to a clear explanation — and to know what data was being retained, why, and for how long.
Stage 2: Proportionality analysis
Just because Cornerstone was legally entitled to retain the data did not mean it was required to retain everything. GDPR's principle of data minimization applied even to data retained for legitimate AML purposes: Cornerstone should retain what the MLRs required, and no more.
The practical question: what did the MLRs actually require? The regulations required retention of: - Customer due diligence records (KYC documents, verification records) - Transaction records relevant to business relationships - SAR-related records (if a SAR had been filed)
They did not require retention of: - Marketing preferences - Non-financial communications not relevant to the business relationship - Behavioral analytics data generated internally (e.g., browsing patterns on the online platform)
Priya recommended a data category review: for each data category retained on closed accounts, determine whether it was within scope of the MLR retention obligation. Data outside scope should be deleted promptly when an account closed.
Stage 3: Architecture solution
The underlying problem was that Cornerstone's systems did not distinguish between data retained for AML/MLR purposes and data retained for other purposes. Deleting "all personal data" for a customer would necessarily delete AML-required data along with everything else.
Priya recommended a "data partitioning" approach: - Implement a retention classification for all personal data: AML-retained (required for 5 years from relationship end), operationally-retained (required for specific business purposes), and preference/behavioral-retained (can be deleted on request or at shorter intervals) - Build automated deletion for non-AML data at account closure - Store AML-retained data in a restricted archive with access controls that limit it to compliance and legal functions - Provide customers with a clear privacy notice explaining which data is retained for AML purposes and the legal basis
The Data Architecture Implications
The conflict revealed a fundamental data architecture requirement that Cornerstone had not designed for: the ability to segregate personal data by retention basis.
This required: - A data classification system (tagging every data record with its retention basis) - Retention schedules automated to delete data at the appropriate time (or to flag it for review) - An archive system for AML-retained data that was separated from operational systems - A subject access request workflow that could provide customers with a full view of what was retained and why, without revealing AML monitoring details that might constitute tipping-off
The implementation of this architecture took nine months and required coordination across legal, compliance, data privacy, IT, and the core banking vendor.
The ICO Response
Cornerstone ultimately responded to the customer's ICO complaint by: 1. Providing a detailed explanation of which data was retained and the legal basis 2. Confirming that non-AML data had been deleted 3. Providing access to the data retained for AML purposes (a GDPR subject access request right that exists independently of the right to erasure)
The ICO closed the complaint without finding against Cornerstone, noting that the retention was legally required and that Cornerstone had demonstrated appropriate proportionality in what was retained.
Discussion Questions
1. The GDPR/AML conflict described here is a structural feature of European financial regulation — it will recur every time a customer exercises GDPR rights over compliance-related data. What should financial institutions do proactively to avoid this conflict becoming a compliance crisis?
2. Priya recommended a "data partitioning" approach — segregating data by retention basis. What are the technical challenges of implementing this in an institution that has accumulated years of non-partitioned historical data?
3. The case reveals a difference between "what the MLRs require" and "what Cornerstone was actually retaining." This oversharing of personal data with the compliance function is common. What governance process would prevent it from occurring?
4. Some jurisdictions (particularly in APAC) have data localization requirements that require personal data to remain within national borders. How does this interact with the AML data sharing that financial intelligence units (FIUs) like FinCEN, the NCA, and AUSTRAC require?
5. Cornerstone ultimately needed to invest nine months and significant resources to build the data architecture to properly manage this conflict. What would have prevented this situation from arising had the architecture been designed correctly from the start?
Key Concepts Illustrated
- GDPR/AML conflict: The structural tension between privacy law and financial crime compliance requirements
- Data minimization as architecture requirement: The principle that only required data should be retained requires deliberate architectural design
- Retention schedules as compliance controls: Automated deletion is as important as automated collection
- Data partitioning: The technical approach of segregating data by retention basis
- Proportionality in retention: Legal compliance with AML retention requirements does not require retaining everything — only what the law specifically requires