Notes from Seven Regulatory Regimes: A Comparative View

A multi-line financial services firm we worked with last year — lending, payments, a small wealth-management arm, a card program run through a partner bank — operated under roughly seven distinct regulatory regimes depending on how you counted state-level variants. By the time we got involved, they had eleven separately built and separately maintained versions of what was, on inspection, the same underlying control: verify the customer's identity before allowing a transaction of consequence. Eleven implementations, eleven sets of test cases, eleven places a fix had to be applied when one of them found a bug. Nobody had set out to build it that way. Each version had been built by a team responding to one regime's specific requirement, in isolation, under deadline, without a mechanism to check whether the control already existed somewhere else in the company.

This piece is a comparative note on what we consistently see across regimes like these — not a citation of any specific rule text, which changes too often to be worth reproducing here, but the shape of the overlaps and conflicts, because the shape is what should drive how you architect the control layer.

The overlaps are larger than they look

Regulatory regimes are drafted by different bodies, at different times, for different primary risks — safety and soundness, consumer protection, market conduct, anti-money-laundering, data privacy, sector-specific licensing, state-level consumer-lending rules. Read independently, they look like seven different rulebooks. Implemented independently, they produce exactly the duplication we found: eleven identity-verification controls, nine transaction-monitoring pipelines, six versions of "is this customer disclosure adequate."

The reason the overlap is bigger than the rule text suggests is that most regimes are regulating the same underlying set of failure modes — a customer who isn't who they claim to be, a transaction that moves money somewhere it shouldn't, a disclosure the customer didn't actually understand — described in different language, with different evidentiary requirements, but pointed at the same operational reality. When you map requirements down to the control they're actually asking for, rather than the language asking for it, the seven regimes collapse to something closer to a dozen distinct underlying controls, each with several regimes' worth of requirements layered on top.

Where they genuinely conflict, not just overlap

The harder case, and the one that actually justifies keeping some controls regime-specific rather than unified, is where two regimes impose requirements that are in real tension — not just different phrasing of the same thing. The clearest recurring pattern: retention and deletion. A consumer-privacy-oriented regime wants data minimized and deleted on request within a bounded window. A safety-and-soundness or AML-oriented regime wants records retained for a period that often runs years longer, specifically so they're available for exactly the kind of retrospective examination that data minimization is designed to prevent. You cannot satisfy "delete on request" and "retain for seven years" with one policy; you need a control that knows which category of data a given record falls into and applies the correct regime's rule to that category, which is a harder engineering problem than either requirement alone.

A second recurring conflict sits in disclosure timing — one regime wants a disclosure delivered before a transaction executes, another treats the same disclosure as acceptable if delivered within a window after. Building to the stricter of the two generally satisfies both, but only if someone has actually identified that the two requirements are addressing the same disclosure rather than building separate disclosure flows because separate teams owned separate regime relationships.

Designing for the union, not the count

The practical implication is that a control layer for a multi-regime firm should be organized around the union of requirements per underlying control, not one implementation per regime. Concretely:

Start from the control, not the regulation. Build a control inventory keyed on the operational function — identity verification, transaction monitoring, disclosure delivery, retention — and map every regime's requirement onto that inventory as an attribute, rather than starting from the regulation's text and building outward. This is the single change that would have caught the eleven-identity-controls problem before it happened; the duplication was invisible from the regulation-first view and obvious from the control-first view.

Implement to the strictest applicable requirement per attribute, per jurisdiction. Not strictest overall — a national strictest-wins policy over-applies stringent state requirements to customers the state rule was never meant to cover, which creates its own compliance and customer-experience cost. The control needs to know which regime's requirement applies to which customer, and apply the strictest requirement within that applicable set.

Treat genuine conflicts as first-class branches, not edge cases. The retention conflict above isn't a bug to be smoothed over with a single policy; it's a permanent bifurcation the system needs to carry, with data classified at creation time so the correct rule applies automatically rather than being resolved case by case under pressure.

What this saved, concretely

Collapsing eleven identity-verification implementations to one parameterized control, with regime-specific requirements expressed as configuration rather than separate codebases, cut the team's regression-testing surface by roughly two-thirds and — more importantly — meant a rule change in one regime no longer risked silently leaving ten other implementations out of date. That second effect matters most under examination: a control-per-regime architecture guarantees drift between implementations that were never supposed to diverge, and drift is exactly what an examiner comparing your stated policy against your seven different actual behaviors is trained to find.