Chapter 32: Case Study 2 — Rafael's Advice: When One Framework Creates Compliance Problems in Another

Background

Orion Asset Management is a London-headquartered investment management firm with operations in the United Kingdom, the European Union (Luxembourg), and the United States (New York and Boston). Orion manages approximately $14 billion in assets across European and US institutional clients. Its technology systems hold personal data for approximately 22,000 clients and 8,000 counterparties across all three jurisdictions.

In 2023, Orion's General Counsel, Priya Mehta, identified a compliance risk from managing three different data privacy frameworks — UK GDPR, EU GDPR, and a growing patchwork of US state privacy laws. Her assessment: "We cannot manage three different consent frameworks, three different deletion workflows, and three different breach notification timelines with manual processes. We need to simplify."

The simplification approach adopted by Orion's technology team, with Priya's approval, was to implement GDPR globally: apply the strictest framework — EU GDPR — to all customer data regardless of jurisdiction. The rationale was conservative: if GDPR is satisfied, any less stringent framework is also satisfied. The implementation team built a single global DSAR (Data Subject Access Request) workflow, a global consent management platform with GDPR-grade consent requirements, and a single global data deletion workflow that could execute right-to-erasure requests across all systems.

Rafael Torres was engaged eighteen months later to advise on Orion's US regulatory compliance posture ahead of an SEC examination. During his review, he identified a problem.

The Conflict

Rafael's review of Orion's data privacy implementation identified an unintended consequence of the global GDPR policy: it was creating conflicts with US regulatory obligations.

The Conflict: GDPR Right to Erasure vs. BSA Retention Requirements

Under GDPR Article 17, Orion's platform was configured to honor erasure requests from all customers — including US customers — within thirty days, subject to the exemptions listed in Article 17(3). The exemptions include compliance with a legal obligation, the exercise of legal claims, and public interest. GDPR's Article 17(3)(b) exempts erasure where processing is necessary "for compliance with a legal obligation which requires processing by Union or Member State law."

But Orion's US customer data is not subject to Union or Member State law. The legal obligation that prevents erasure is the US Bank Secrecy Act, which requires financial institutions to retain records of customer identification, beneficial ownership verification, and transaction history for five years. FinCEN's regulations (31 CFR § 1020.430 for banks; with equivalent provisions for investment advisers under 31 CFR § 1032) require retention of specific records regardless of the customer's wishes.

The practical consequence: if a US customer submitted a GDPR-style erasure request to Orion, and Orion honored it under its global deletion policy, Orion would delete records that US law requires it to retain for five years. This would create a BSA/AML record-keeping violation — a federal offense with significant civil and potentially criminal penalties.

Rafael found two cases where this had already occurred: two US counterparties had submitted erasure requests (prompted by a link in Orion's standard email footer that referenced GDPR rights globally), and the automated deletion workflow had purged their records from Orion's CRM and transaction history systems. The records were gone. The BSA retention obligation had been violated.

The Secondary Conflict: CCPA vs. GDPR Consent Architecture

Orion's global consent platform required affirmative opt-in consent for all data processing categories — the GDPR standard. For California clients, this created a different problem: the CCPA does not require opt-in consent for most data processing; it provides an opt-out right for the sale or sharing of personal data. By applying GDPR's opt-in standard globally, Orion had created an unnecessarily restrictive consent architecture for US clients that made certain legitimate business activities — such as sharing data with affiliated US entities for investment advisory purposes — technically non-compliant with Orion's own privacy policy if prior consent had not been captured.

During one quarter, Orion had shared US client data with a US-affiliated broker-dealer for order routing purposes — a standard, lawful activity under US law — without having first obtained the specific GDPR-style consent that Orion's own privacy policy now required (because the policy applied globally). This created an internal inconsistency: the activity was lawful under CCPA and GLBA but arguably violated Orion's own global privacy policy, which in turn was a policy document referenced in client service agreements.

The Remediation

Rafael presented his findings to Priya Mehta and the Orion Board. His assessment: "You were trying to simplify. But applying your strictest framework globally doesn't simplify — it exports one framework's constraints into jurisdictions where those constraints create new conflicts. GDPR's right to erasure is not the right to erasure under US law. You can't make it so by applying it globally."

The remediation approach Rafael recommended, and which Orion implemented over the following nine months:

Step 1: Jurisdiction-flagging in the CRM. Every client and counterparty record was tagged with a primary regulatory jurisdiction (EU/UK/US) based on the client's residence and the entity through which they were onboarded. The deletion and consent workflows were reconfigured to apply jurisdiction-specific logic.

Step 2: Separate retention schedules by jurisdiction. US records are governed by a retention schedule derived from BSA, SEC, and FINRA record-keeping requirements. EU records are governed by GDPR's storage limitation principle and AML Regulation retention requirements. UK records are governed by UK GDPR and MLR 2017 retention requirements. The global deletion workflow was retired; jurisdiction-specific workflows replaced it.

Step 3: GDPR exemptions properly configured for EU/UK records only. For EU and UK records, the erasure workflow was reconfigured to apply GDPR Article 17(3) exemptions correctly — including the exemption for compliance with legal obligations under EU and UK law (specifically, AML retention requirements). The previous implementation had not consistently applied these exemptions.

Step 4: Reconstruct the two deleted US records from backup. Legal counsel confirmed that Orion had a regulatory obligation to reconstruct the deleted records from system backups, which were retained for 180 days. The records were reconstructed and the BSA retention clock reset from the original transaction dates.

Step 5: Voluntary self-disclosure to FinCEN. After internal deliberation and external legal advice, Orion made a voluntary self-disclosure to FinCEN regarding the two record-keeping failures. Voluntary self-disclosure is a mitigating factor in FinCEN enforcement decisions. FinCEN accepted the disclosure; no enforcement action was taken. FinCEN noted the prompt remediation.

The Broader Lesson

Rafael's summary note to Priya Mehta, which she circulated to the Board, captured the core principle:

"Regulatory frameworks are designed for specific jurisdictions. When they conflict — as GDPR's erasure right conflicts with BSA's retention requirement — the conflict cannot be resolved by applying one framework to both jurisdictions. The conflict must be managed by jurisdiction-specific configuration that respects both legal obligations. GDPR's exemptions exist precisely for this reason: Union law acknowledges that legal obligations may prevent erasure, and the exemption applies where the processing is necessary for compliance with a legal obligation under Union or Member State law. The key word is 'Union or Member State.' For a US client whose data is held under US law, that exemption does not automatically apply — because the legal obligation is a US legal obligation, not a Union one. The solution is not to pick a winner between GDPR and BSA. It is to apply each framework to the data it governs."

Discussion Questions

1. Orion's General Counsel made a good-faith effort to simplify compliance by applying the strictest framework globally. What is the fundamental flaw in the "apply the strictest framework globally" approach when frameworks conflict rather than merely differ in strictness? Under what circumstances — if any — does applying the strictest framework globally work without creating new problems?

2. The two BSA record-keeping violations arose from an automated deletion workflow that executed without jurisdiction-specific safeguards. How should automated regulatory workflows be designed to prevent unintended violations in one jurisdiction caused by compliance measures designed for another? What testing should have been performed before the global deletion workflow was deployed?

3. Rafael identified the CCPA consent conflict: Orion's global GDPR opt-in requirement made certain lawful US data sharing activities inconsistent with Orion's own privacy policy. What is the compliance risk created when a firm's own privacy policy is more restrictive than applicable law, and the firm then fails to comply with its own policy? How should privacy policies be drafted to accommodate multi-jurisdictional operations without creating internally inconsistent obligations?

4. Orion's voluntary self-disclosure to FinCEN regarding the BSA record-keeping failures was a critical risk management decision. What factors should a firm weigh when deciding whether to voluntarily self-disclose a regulatory violation? What are the risks of self-disclosure, and under what circumstances does self-disclosure typically result in a better outcome than non-disclosure followed by regulatory discovery?

5. The conflict between GDPR's right to erasure and blockchain-based records (which are immutable by design) raises a similar structural problem to the one Orion faced with BSA retention. Design a data architecture for a blockchain-based trade reconciliation system that complies with GDPR's right to erasure without violating the immutability of the blockchain record. What technical approaches exist for separating personal data from the immutable record?