Rafael Torres set his laptop bag on the conference room table and did not open it. He had learned, after two decades in compliance, that the first meeting with a new client was not a presentation. It was a listening exercise.
In This Chapter
- The Map Comes First
- Section 1: Why Jurisdictional Comparison Matters
- Section 2: Comparative Analysis by Domain
- Section 3: Convergence and Divergence — What It Means for Technology
- Section 4: Technology Choices in a Multi-Jurisdictional Context
- Section 5: Python — Jurisdictional Compliance Matrix
- Section 6: The Map Becomes the Recommendation
- Summary
Chapter 32: Global RegTech — US, EU, UK, APAC Comparative Landscape
The Map Comes First
Rafael Torres set his laptop bag on the conference room table and did not open it. He had learned, after two decades in compliance, that the first meeting with a new client was not a presentation. It was a listening exercise.
The Head of Compliance at Meridian Global Bank — Sarah Whitfield, fifty-one, with the measured speech of someone who had survived three regulatory examinations and one enforcement action — had asked him a single question before he had taken his seat: "Which RegTech platform should we buy?"
Rafael pulled out a legal pad. He uncapped a pen. "Before we can answer that," he said, "we need to map your obligations by jurisdiction. What you need in Singapore is not what you need in the EU. What's permitted in the US may be restricted in the EU. The platform comes last. The map comes first."
Whitfield leaned back. She had heard consultants say things like this before. Usually it meant they were buying time. "We've already received demos from four vendors."
"I know." Rafael wrote the bank's name at the top of the page. Below it, he drew a simple grid — five rows, five columns. "You operate in the US, UK, EU — Frankfurt and Amsterdam — Singapore, and Hong Kong. That's five jurisdictions. Across those five jurisdictions, you have compliance obligations in at least five domains: AML and KYC, market surveillance, operational resilience, AI and algorithmic governance, and data privacy." He tapped the grid. "That's twenty-five cells. Each one has a different answer. Before I can tell you which platform to buy, I need to know what's in each cell."
Whitfield looked at the grid. She was quiet for a moment. Then she said: "Walk me through it."
This chapter does precisely that.
Section 1: Why Jurisdictional Comparison Matters
The temptation in global compliance is to treat regulatory requirements as essentially the same across jurisdictions — different labels, different agency names, but fundamentally the same obligations. This temptation is understandable. FATF's Forty Recommendations provide a global AML baseline. The FSB's Key Attributes of Effective Resolution Regimes create a shared framework for systemic risk. IOSCO's Objectives and Principles of Securities Regulation underpin market integrity rules worldwide.
But the temptation is wrong, and it is expensively wrong.
Regulatory frameworks reflect political choices, legal traditions, and financial system histories. The EU's GDPR is not merely a stricter version of the US's sectoral privacy patchwork — it reflects a fundamentally different view of privacy as a fundamental right rather than a consumer protection matter. The UK's principles-based approach to operational resilience is not merely a softer version of DORA — it reflects the FCA's longstanding preference for outcomes-based regulation over prescriptive rules. Singapore's MAS inspection-first approach to AML is not merely an Asian variant of FinCEN's guidance — it reflects a city-state's particular vulnerability to cross-border money laundering from its regional neighbors.
These are not semantic differences. They create genuinely different technology requirements, different data architectures, different testing obligations, and different notification timelines.
The framework for comparison that this chapter uses is deliberately structured: five compliance domains, five jurisdictions. The domains are AML/KYC; market surveillance; operational resilience; AI and algorithmic governance; and data privacy. The jurisdictions are the United States, the European Union, the United Kingdom, Singapore, and Hong Kong. Together, these represent the five most significant regulatory environments for internationally active financial institutions.
The analysis proceeds in two directions. Horizontally, across jurisdictions for each domain, the reader can see how a single compliance function — say, AML monitoring — looks different depending on where the firm is operating. Vertically, within a single jurisdiction, the reader can see the full compliance stack and assess where platforms can serve multiple domains and where they cannot.
Before examining each domain, one structural observation is worth making. There is a genuine convergence trend in global regulation, driven by FATF, the FSB, BIS, and IOSCO. On the fundamentals — AML risk-based approach, market integrity, systemic risk measurement — frameworks have converged substantially over the past two decades. What has not converged is implementation. The risk-based approach to AML is endorsed by every major jurisdiction. The specific triggers for enhanced due diligence, the format of suspicious activity reports, the list of designated categories of offenses that constitute predicate offenses for money laundering — these diverge significantly. Convergence at the principle level does not eliminate divergence at the implementation level, and it is implementation-level divergence that technology must address.
Section 2: Comparative Analysis by Domain
Domain 1: AML / KYC
Anti-money laundering is the compliance domain with the most extensive international coordination and, simultaneously, some of the most significant implementation-level divergence.
United States
The US AML framework is anchored in the Bank Secrecy Act of 1970, administered by FinCEN within the Treasury Department. The BSA requires financial institutions to maintain AML programs with four pillars: internal controls, independent testing, a designated BSA officer, and training. The Customer Identification Program (CIP) Rule requires institutions to verify customer identity at account opening. FinCEN's 2016 Customer Due Diligence Rule — extended and amended in 2024 — requires identification of beneficial owners of legal entity customers, typically to the 25% ownership threshold.
The SAR filing regime is distinctive: US institutions file Suspicious Activity Reports electronically to FinCEN via the BSA E-Filing System in a specific structured format. Currency Transaction Reports (CTRs) are required for cash transactions over $10,000. State-level Money Services Business licensing requirements create an additional compliance layer for fintech firms.
European Union
The EU's sixth Anti-Money Laundering Directive (AMLD6) has now been superseded by the 2024 AML Regulation, which, crucially, is a Regulation rather than a Directive. This distinction matters: Directives require transposition into national law, creating implementation-level divergence across member states. A Regulation applies directly and uniformly across the EU. The 2024 AML Regulation is accompanied by the creation of the Anti-Money Laundering Authority (AMLA), which will assume supervisory responsibility for the highest-risk financial entities from 2026 and will provide binding technical standards and guidelines that will substantially reduce the variation in AML implementation that previously existed across member states.
Ultimate Beneficial Owner (UBO) registers are required across the EU, though the 2022 ECJ ruling in WM and Sovim (C-601/20) restricted public access to UBO data, requiring member states to demonstrate legitimate interest. Enhanced due diligence requirements apply to correspondent banking relationships and to customers from high-risk third countries designated by the European Commission.
United Kingdom
The UK's AML framework is set out in the Money Laundering, Terrorist Financing and Transfer of Funds Regulations 2017, amended most recently in 2022. Post-Brexit, the UK maintains a framework that largely mirrors AMLD5 but has developed in parallel. The UK's Financial Intelligence Unit sits within the National Crime Agency; SAR filings go to the NCA rather than a Treasury agency. The Joint Money Laundering Steering Group (JMLSG) produces guidance that, while not legally binding, is widely treated as the benchmark for what constitutes good AML practice. Crypto asset businesses must register with the FCA under the Money Laundering Regulations before commencing business.
Singapore
MAS administers AML/CFT requirements through a suite of Notices and Guidelines. Singapore is a FATF member and has undergone successful mutual evaluations demonstrating technical compliance and effectiveness. The MAS inspection-first approach — where supervisors review actual files, not just policies — sets a high practical standard. Private banking is subject to enhanced scrutiny given Singapore's role as a regional wealth management hub. Digital Payment Token (DPT) service providers must register with MAS and meet AML/CFT requirements equivalent to those for traditional financial institutions.
Hong Kong
The Anti-Money Laundering and Counter-Terrorist Financing Ordinance (AMLO), enacted in 2012 and subsequently amended, provides the statutory framework. The HKMA supervises banks; the SFC supervises licensed corporations. Hong Kong's unique position as a Special Administrative Region with deep financial connections to Mainland China creates a distinctive risk profile: financial flows between Hong Kong and the Mainland require careful monitoring, and correspondent banking with Mainland Chinese banks requires robust due diligence given the differences between the two legal systems.
Domain 2: Market Surveillance
United States
Market surveillance in the US is divided between the SEC (equities and options), FINRA (broker-dealer self-regulation), and the CFTC (futures, swaps, and derivatives). The Consolidated Audit Trail (CAT) is the SEC's foundational market surveillance infrastructure: it requires broker-dealers and exchanges to submit comprehensive records of order events, creating a unified audit trail that allows regulators to reconstruct market activity. The CAT replaced the earlier Order Audit Trail System (OATS).
SEC Regulation SHO governs short selling; the CAT captures locate data and delivery failures. FINRA's surveillance of broker-dealer conduct includes cross-market surveillance coordinated with the SEC. The CFTC's approach to algorithmic trading — the proposed Regulation Automated Trading (RegAT) — has been under discussion for years without finalization, leaving algo governance to existing risk controls guidance.
European Union
The Market Abuse Regulation (MAR, EU 596/2014) is directly applicable across all member states. Article 31 of MiFIR requires trading venues and systematic internalisers to establish effective arrangements and procedures to detect and report suspicious transactions and orders (STORs). ESMA coordinates market surveillance across the EU through colleges of supervisors and joint supervisory action, and its Guidelines on the market abuse regulation provide specific surveillance scenarios that firms must consider.
United Kingdom
UK MAR, maintained in UK law following Brexit via the European Union (Withdrawal) Act 2018, largely mirrors EU MAR in substance. The FCA's STOR regime operates in parallel to the EU system. Post-Brexit, coordination between UK and EU market surveillance authorities continues through memoranda of understanding, but the UK has developed some UK-specific interpretations — particularly around crypto asset surveillance, where the FCA has moved more quickly than some EU counterparts on market abuse in crypto markets.
Singapore
The Securities and Futures Act (SFA) provides the statutory framework for market conduct. The MAS maintains market surveillance capabilities and has bilateral cooperation arrangements with other jurisdictions — particularly for cross-border market manipulation involving both Singapore-listed and regionally-listed instruments. The cross-border dimension of Singapore's market integrity regulation reflects its role as a regional hub where market participants may operate across multiple exchanges simultaneously.
Hong Kong
The Securities and Futures Ordinance (SFO) governs market conduct. The SFC maintains sophisticated market surveillance systems and has enforcement powers including asset freezing orders and criminal prosecution referrals. The Stock Connect programs linking Hong Kong with the Shanghai and Shenzhen exchanges create a genuinely novel surveillance challenge: manipulation may occur on one side of the Connect, with economic benefit realized on the other.
Domain 3: Operational Resilience
This domain has seen the most significant regulatory development in the past five years, driven by the operational disruptions revealed by COVID-19 and the growing recognition of the systemic risk posed by technology concentration in financial services.
United States
The US approach to operational resilience remains sector-specific and guidance-based rather than statutory. The FFIEC Cybersecurity Assessment Tool provides a framework for examining cyber resilience. OCC guidance on risk management provides expectations for technology risk. The NIST Cybersecurity Framework (CSF 2.0, 2024) is referenced by multiple regulators. There is no US equivalent to DORA: no single statutory framework imposing specific ICT risk management requirements, third-party concentration risk rules, or mandatory testing obligations on financial institutions comprehensively.
European Union
DORA — the Digital Operational Resilience Act, effective January 17, 2025 — is the most comprehensive operational resilience regulation in the world. It applies to financial entities (banks, investment firms, insurance companies, payment institutions, crypto-asset service providers) and to ICT third-party service providers that are designated as critical. DORA requires: an ICT risk management framework with senior management accountability; ICT incident classification and reporting within defined timelines; digital operational resilience testing including threat-led penetration testing (TLPT) for significant firms; and third-party ICT risk management including contractual requirements and oversight of Critical Third-Party Providers (CTPPs). Chapter 33 covers DORA in detail.
United Kingdom
The FCA and PRA's Policy Statement PS21/3 established the UK operational resilience framework, effective from March 2022 (with full compliance required by March 2025). The framework requires firms to identify their Important Business Services; set impact tolerances for each service (the maximum tolerable disruption); map the resources — people, technology, facilities, third parties — needed to deliver each service; and test whether they can remain within their impact tolerances during severe but plausible disruption scenarios. The CBEST framework (for major banks and FMIs) is the UK's equivalent of DORA's TLPT requirement.
Singapore
MAS's Technology Risk Management (TRM) Guidelines are highly prescriptive — more so than the UK framework and comparable to DORA in terms of specificity. The TRM Guidelines cover system development, IT project management, IT service management, access controls, incident management, and IT outsourcing risk. MAS's notification requirements for technology-related incidents are specific: certain incidents must be reported to MAS within one hour of the bank declaring a major incident; full reports must follow within specified timescales.
Hong Kong
The HKMA's Supervisory Policy Manual module TM-E-1 (Technology Risk Management) provides the operational resilience framework for authorized institutions. It covers technology governance, risk management, security controls, and business continuity. HKMA supervisory expectations on technology risk are enforced through the examination process.
Domain 4: AI and Algorithmic Governance
United States
The US has no comprehensive AI regulation at the federal level (as of 2026). The Biden-era Executive Order on AI (October 2023) established principles and required risk assessments, but it was an executive order, not legislation. NIST's AI Risk Management Framework (AI RMF 1.0, published 2023) is voluntary guidance. The Federal Reserve's SR 11-7 guidance on model risk management — originally issued for financial models broadly — is applied by supervisors to AI models in credit, market risk, and operational contexts. Colorado's SB21-169, which governs algorithmic decision-making in insurance, represents one of the most significant state-level AI regulations. The patchwork nature of US AI governance creates significant uncertainty for financial institutions operating AI-powered compliance tools.
European Union
The EU AI Act (Regulation (EU) 2024/1689, entering force August 2024, with phased application) is the world's first comprehensive AI regulation. It applies a risk-tiered approach: prohibited AI practices (manipulative AI, social scoring by public authorities); high-risk AI systems (including those used in credit decisioning, biometric identification, and critical infrastructure); and general-purpose AI models. High-risk AI systems — which include AI used in creditworthiness assessment and therefore relevant to many financial services applications — must undergo conformity assessment before deployment; must be registered in an EU database; must be accompanied by technical documentation; and must meet requirements on transparency, human oversight, data governance, and robustness. The AI Act has extraterritorial effect: it applies to AI systems placed on the EU market regardless of where the provider is established.
United Kingdom
The UK has adopted a sector-specific, principles-based approach rather than a single AI Act. The FCA and PRA issued cross-sector AI principles in 2023-24 covering fairness, transparency, human oversight, accountability, and contestability. The FCA has been active in using its regulatory sandbox to explore AI governance in financial services. The UK's approach gives firms more flexibility but less legal certainty than the EU AI Act, and creates divergence risk for firms that operate in both jurisdictions.
Singapore
MAS's FEAT Principles (Fairness, Ethics, Accountability, and Transparency) were issued in 2018 and represent one of the earliest efforts by a financial services regulator to address AI governance. They are voluntary but carry significant supervisory weight. The MAS Veritas consortium — a collaboration between MAS and industry — develops open-source tools for testing AI models against the FEAT principles, particularly for credit decisioning. Singapore's approach combines voluntary principles with practical implementation support, reflecting MAS's characteristic preference for close public-private collaboration.
Hong Kong
HKMA guidance on the use of AI in banking covers disclosure obligations (customers must be informed when AI is used in significant decisions), human oversight requirements, and model risk management expectations. The HKMA approach is principles-based and disclosure-focused, closer to Singapore's FEAT framework than to the EU AI Act in terms of prescriptiveness.
Domain 5: Data Privacy
United States
The US has no comprehensive federal data privacy law as of 2026. Privacy regulation is sectoral and state-level. At the federal level, the Gramm-Leach-Bliley Act (GLBA) requires financial institutions to protect nonpublic personal information; the GLBA Safeguards Rule (amended 2023) prescribes specific information security requirements. HIPAA governs health information. For financial institutions operating in California, the California Consumer Privacy Act (CCPA) and its amendment, the California Privacy Rights Act (CPRA), provide significant rights to California residents — access, deletion, opt-out of sale or sharing. Multiple other states have enacted similar legislation, creating a growing patchwork of state privacy requirements that financial institutions must navigate.
European Union
The GDPR (General Data Protection Regulation, Regulation (EU) 2016/679) is the most consequential data privacy law in the world, both for the rigor of its requirements and for its extraterritorial scope. It applies to any organization that processes personal data of EU residents, regardless of where the organization is established. GDPR requires a lawful basis for processing; limits purpose and retention; requires data minimization; grants data subjects rights to access, rectification, erasure, portability, and objection; requires Data Protection Officers for certain organizations; mandates data protection impact assessments for high-risk processing; and restricts transfers of personal data to countries outside the EU unless adequate protections exist. Maximum penalties are up to €20 million or 4% of global annual turnover, whichever is higher.
United Kingdom
The UK GDPR, established under the Data Protection Act 2018, is substantially equivalent to EU GDPR — the UK Government retained GDPR in UK law following Brexit and has maintained an adequacy decision with the EU (finalized in 2021). Some UK-specific provisions exist, particularly around national security, law enforcement, and some derogations. The UK Government has consulted on amendments to the data protection framework under the Data Protection and Digital Information Act, which is progressing through Parliament.
Singapore
The Personal Data Protection Act (PDPA), enacted in 2012 and substantially amended in 2021, is Singapore's comprehensive privacy framework. The 2021 amendments introduced mandatory breach notification (to the PDPC and affected individuals in certain circumstances); enhanced financial penalties (up to S$1 million or 10% of annual Singapore turnover for organizations with annual local turnover exceeding S$10 million); data portability rights; and extended the Act's application to data intermediaries. The PDPA is consent-based at its core — organizations generally must obtain consent before collecting, using, or disclosing personal data.
Hong Kong
The Personal Data (Privacy) Ordinance (PDPO), Cap. 486, is Hong Kong's primary data privacy legislation, originally enacted in 1996. It is one of the older frameworks in the region and has been subject to calls for comprehensive reform. The PDPO's six Data Protection Principles cover collection, accuracy and retention, use, security, transparency, and data access rights. The Office of the Privacy Commissioner for Personal Data (PCPD) oversees enforcement. Data transfer restrictions apply: personal data may not be transferred outside Hong Kong unless specified conditions are met. Significant amendments to strengthen the PDPO, particularly regarding doxxing, were enacted in 2021, but broader reform remains under consideration.
Section 3: Convergence and Divergence — What It Means for Technology
Having mapped twenty-five regulatory frameworks across five jurisdictions and five domains, the question Rafael Torres posed to Whitfield becomes more tractable: where can shared RegTech platforms work, and where does platform customization become unavoidable?
Where Shared Platforms Work
Sanctions screening is the clearest case for a shared platform with jurisdiction-specific tuning. The UN Consolidated Sanctions List is globally applicable. OFAC's SDN list, HMT's UK sanctions list, and MAS's sanctions list all largely mirror the UN list with some additions. A single screening engine can consume all four lists and operate uniformly. The tuning required — threshold settings, name matching algorithms, nationality weighting — can be configured at the jurisdiction level without requiring separate systems.
FATF-based AML typology detection is similarly amenable to shared platforms. The FATF's identified money laundering typologies — structuring, layering through shell companies, real estate abuse, trade-based money laundering — are recognized across all five jurisdictions. A transaction monitoring system built on FATF typologies can, with configuration, apply jurisdiction-specific rules for predicate offenses and reporting thresholds while using a common detection engine.
Market abuse typology detection — spoofing, layering, wash trading, front-running — is conceptually consistent across MAR, UK MAR, the SFA, and the SFO. The underlying mathematical indicators (price impact, order-to-trade ratios, cross-asset correlations) apply regardless of jurisdiction. Venue coverage and regulatory destination for alerts differ, but the detection logic can be shared.
Where Customization Becomes Unavoidable
The EU GDPR's right to erasure creates a direct conflict with blockchain-based immutability. A distributed ledger transaction is permanent by design. GDPR Article 17 requires erasure of personal data on request. These cannot both be fully satisfied simultaneously. In jurisdictions where GDPR applies, any RegTech system involving a blockchain must have an architecture that separates personal data from the immutable record — for example, storing personal data in a mutable database with the blockchain containing only hashes or identifiers.
Consent frameworks differ fundamentally. GDPR's consent must be freely given, specific, informed, and unambiguous — and withdrawal of consent must be as easy as giving it. The CCPA's opt-out framework is narrower. Singapore's PDPA consent framework has specific deemed consent provisions that GDPR does not recognize. A consent management platform designed for GDPR cannot simply be deployed globally without jurisdiction-specific configuration that reflects these structural differences.
DORA's ICT third-party requirements have no direct US equivalent. A firm subject to DORA must ensure that contracts with ICT third-party providers contain specific provisions (Article 30) and must participate in DORA's oversight framework for Critical Third-Party Providers. This requires vendor management processes and contractual templates that are jurisdiction-specific to the EU. US vendor management processes, which lack these statutory requirements, cannot be applied uniformly.
SAR filing formats are jurisdiction-specific by definition. FinCEN's SAR format (FinCEN SAR — Form 111) is specific to the BSA reporting regime. The UK's SARs go to the NCA in a different format. EU-level SAR reporting is being harmonized by AMLA, but the pre-AMLA national regime maintained distinct national formats. Any RegTech platform that generates SAR filings must have separate jurisdiction-specific filing modules — there is no single format that satisfies all five jurisdictions.
AI governance requirements create a further divergence. A firm deploying an AI-powered credit decisioning system must, in the EU, treat it as a high-risk AI system under the AI Act and comply with conformity assessment requirements. In the US, the same system is governed by fair lending law (ECOA, Fair Housing Act) and model risk guidance (SR 11-7) — a different legal framework with different documentation and testing requirements. In Singapore, the FEAT Principles require fairness assessment using tools like those developed in the Veritas consortium. Three jurisdictions, three different compliance frameworks for the same AI system.
The Regulatory Tetris Problem
Rafael Torres uses the phrase "regulatory Tetris" to describe what happens when a technology team tries to configure a single platform to satisfy five different frameworks simultaneously. Like Tetris, each piece has a specific shape — the data structure required by DORA's incident reporting is not the same shape as FinCEN's SAR format, which is not the same shape as MAS's TRM incident notification. Fitting these shapes together requires careful architecture: common data models that can be mapped to jurisdiction-specific outputs; configurable workflow engines that can route the same underlying event through different regulatory processes depending on jurisdiction; and reporting modules that can generate the correct output format for each recipient.
This is achievable. Several leading RegTech platforms do it. But it requires that the platform be evaluated against the jurisdiction-specific requirements before purchase, not after. The map comes first.
Section 4: Technology Choices in a Multi-Jurisdictional Context
The jurisdiction-specific analysis has direct implications for three foundational technology choices: cloud architecture and data localization, transaction monitoring architecture, and reporting infrastructure.
Data Localization and Cloud Architecture
EU GDPR restricts transfers of personal data to countries outside the EU unless an adequacy decision exists or appropriate safeguards (Standard Contractual Clauses, Binding Corporate Rules) are in place. Singapore's PDPA similarly restricts transfers overseas. China's Personal Information Protection Law (PIPL) — relevant for firms with China operations — requires personal information processed in China relating to critical information infrastructure to be stored in China. These requirements mean that a single global cloud deployment may be impermissible: data about EU residents may need to stay in EU-located data centers; data about Singapore residents may require Singapore or adequacy-approved storage.
The practical consequence for RegTech: cloud-based platforms must support data residency configurations. This is standard for major cloud providers (AWS, Azure, GCP all offer EU, Singapore, and US regions), but RegTech vendors built on single-region architectures may not support data localization requirements. This is a procurement due diligence question that must be asked before selection.
Transaction Monitoring Architecture: Global vs. Local
Two approaches exist to AML transaction monitoring for a multi-jurisdictional firm. The first is a single global system with jurisdiction-specific tuning: one platform, one transaction data feed, with different rule sets, thresholds, and alert queues for each jurisdiction. This approach benefits from global typology coverage — structuring that straddles two jurisdictions is visible from a single vantage point — and from operational efficiency. The risk is that the global system must be configured correctly for each jurisdiction, and misconfiguration in one jurisdiction does not affect the others, which requires robust governance.
The second approach is separate systems per jurisdiction, with cross-border coordination handled at the investigations level. This approach creates cleaner jurisdictional separation and may simplify regulatory examinations, but at the cost of losing visibility into cross-border activity and multiplying operational complexity.
For most internationally active firms, the first approach — a single global system with jurisdiction-specific configuration — is both more cost-effective and more analytically powerful. But it requires a platform that genuinely supports jurisdiction-specific configuration rather than one that claims global capability but delivers it through crude geographic filtering.
Cornerstone Financial Group: A Multi-Jurisdictional Technology Stack
Cornerstone Financial Group operates in the US, UK, and EU. Its global compliance technology architecture illustrates the principles above. For AML transaction monitoring, Cornerstone uses a single platform (NICE Actimize in this illustration) with separate rule sets for US BSA, UK MLR, and EU AMLD/AML Regulation requirements. The platform feeds alert queues to jurisdiction-specific investigation teams who apply local standards. SAR/SARs filed to FinCEN (US), NCA (UK), and national FIUs (EU member states) are generated by jurisdiction-specific filing modules within the same platform.
For data privacy, Cornerstone maintains separate consent management configurations for EU customers (GDPR), UK customers (UK GDPR), and US customers (GLBA/CCPA). The underlying CRM holds a single customer record, but consent flags are jurisdiction-specific and the processing logic differs by customer jurisdiction.
For operational resilience, Cornerstone maps its Important Business Services under the UK PS21/3 framework, which it has also extended (voluntarily) to its EU operations ahead of full DORA compliance. The US operations maintain FFIEC-compliant business continuity plans that, while not using the "important business services" terminology, achieve conceptually equivalent outcomes.
Section 5: Python — Jurisdictional Compliance Matrix
The following implementation provides a structured approach to building and interrogating a multi-jurisdictional compliance matrix.
from __future__ import annotations
from dataclasses import dataclass, field
from enum import Enum
from typing import Optional
class Jurisdiction(Enum):
US = "United States"
EU = "European Union"
UK = "United Kingdom"
SINGAPORE = "Singapore"
HONG_KONG = "Hong Kong"
class ComplianceDomain(Enum):
AML_KYC = "AML / KYC"
MARKET_SURVEILLANCE = "Market Surveillance"
OPERATIONAL_RESILIENCE = "Operational Resilience"
AI_GOVERNANCE = "AI / Algorithmic Governance"
DATA_PRIVACY = "Data Privacy"
class RegulatoryApproach(Enum):
RULES_BASED = "Rules-Based (prescriptive)"
PRINCIPLES_BASED = "Principles-Based (outcomes focused)"
HYBRID = "Hybrid"
VOLUNTARY = "Voluntary / Guidance Only"
@dataclass
class RegulatoryFramework:
"""A regulatory framework for a specific domain and jurisdiction."""
jurisdiction: Jurisdiction
domain: ComplianceDomain
primary_legislation: str
regulator: str
approach: RegulatoryApproach
key_requirements: list[str]
penalty_max: str
technology_implications: list[str]
diverges_from_others_on: list[str] = field(default_factory=list)
class MultiJurisdictionalComplianceMatrix:
"""Maps regulatory frameworks across jurisdictions and domains."""
def __init__(self, firm_name: str, active_jurisdictions: list[Jurisdiction]):
self.firm_name = firm_name
self.active_jurisdictions = active_jurisdictions
self._frameworks: dict[tuple, RegulatoryFramework] = {}
def add_framework(self, framework: RegulatoryFramework) -> None:
key = (framework.jurisdiction, framework.domain)
self._frameworks[key] = framework
def get_frameworks_by_domain(
self, domain: ComplianceDomain
) -> list[RegulatoryFramework]:
return [
f
for (j, d), f in self._frameworks.items()
if d == domain and j in self.active_jurisdictions
]
def divergence_analysis(self, domain: ComplianceDomain) -> list[str]:
"""Identify divergences across jurisdictions for a domain."""
frameworks = self.get_frameworks_by_domain(domain)
all_divergences = []
for f in frameworks:
for div in f.diverges_from_others_on:
all_divergences.append(f"[{f.jurisdiction.value}] {div}")
return all_divergences
def technology_requirements_summary(
self,
) -> dict[ComplianceDomain, list[str]]:
"""Aggregate technology implications across all active jurisdictions per domain."""
result: dict[ComplianceDomain, list[str]] = {}
for domain in ComplianceDomain:
tech_reqs: list[str] = []
for f in self.get_frameworks_by_domain(domain):
for req in f.technology_implications:
entry = f"[{f.jurisdiction.value}] {req}"
if entry not in tech_reqs:
tech_reqs.append(entry)
result[domain] = tech_reqs
return result
def coverage_gaps(self) -> list[tuple[Jurisdiction, ComplianceDomain]]:
"""Identify jurisdiction-domain combinations not yet mapped."""
gaps = []
for j in self.active_jurisdictions:
for d in ComplianceDomain:
if (j, d) not in self._frameworks:
gaps.append((j, d))
return gaps
def risk_score(
self,
gap_weight: int = 10,
divergence_weight: int = 3,
) -> dict[tuple[Jurisdiction, ComplianceDomain], int]:
"""
Rate each jurisdiction-domain combination by compliance gap severity.
Scoring:
- Base score: 0 (covered)
- +gap_weight if the cell is not mapped (coverage gap)
- +divergence_weight per divergence point identified for a mapped cell
Higher scores indicate higher attention priority.
"""
scores: dict[tuple[Jurisdiction, ComplianceDomain], int] = {}
for j in self.active_jurisdictions:
for d in ComplianceDomain:
key = (j, d)
if key not in self._frameworks:
scores[key] = gap_weight
else:
f = self._frameworks[key]
scores[key] = len(f.diverges_from_others_on) * divergence_weight
return scores
def print_matrix_summary(self) -> None:
print(f"\n{'='*70}")
print(f" Multi-Jurisdictional Compliance Matrix: {self.firm_name}")
print(f"{'='*70}")
tech_summary = self.technology_requirements_summary()
for domain, reqs in tech_summary.items():
print(f"\n Domain: {domain.value}")
if reqs:
for r in reqs:
print(f" • {r}")
else:
print(" (No frameworks mapped)")
# ── Demonstration: Cornerstone Financial Group ─────────────────────────────
cornerstone = MultiJurisdictionalComplianceMatrix(
firm_name="Cornerstone Financial Group",
active_jurisdictions=[Jurisdiction.US, Jurisdiction.EU, Jurisdiction.UK],
)
# AML / KYC frameworks
cornerstone.add_framework(RegulatoryFramework(
jurisdiction=Jurisdiction.US,
domain=ComplianceDomain.AML_KYC,
primary_legislation="Bank Secrecy Act / 31 CFR Chapter X",
regulator="FinCEN",
approach=RegulatoryApproach.RULES_BASED,
key_requirements=[
"Customer Identification Program (CIP)",
"Beneficial Ownership CDD Rule (25% threshold)",
"SAR filing to FinCEN via BSA E-Filing",
"CTR for cash >$10,000",
],
penalty_max="Criminal penalties + unlimited civil money penalties",
technology_implications=[
"SAR filing module in FinCEN SAR Form 111 format",
"CTR generation for qualifying cash transactions",
"BSA E-Filing API integration",
"Beneficial owner registry with 25% threshold",
],
diverges_from_others_on=[
"SAR format (FinCEN-specific) — not interchangeable with NCA or national FIU formats",
"CTR requirement has no direct EU/UK equivalent",
"MSB state licensing layer has no EU/UK analogue",
],
))
cornerstone.add_framework(RegulatoryFramework(
jurisdiction=Jurisdiction.EU,
domain=ComplianceDomain.AML_KYC,
primary_legislation="EU AML Regulation 2024 / AMLD6",
regulator="AMLA (from 2026) / National Competent Authorities",
approach=RegulatoryApproach.HYBRID,
key_requirements=[
"UBO verification and UBO register cross-check",
"Enhanced due diligence for high-risk third countries",
"Correspondent banking EDD",
"AMLA-compatible beneficial ownership data model",
],
penalty_max="Up to €5 million or 10% of annual turnover",
technology_implications=[
"UBO data model compatible with forthcoming AMLA technical standards",
"EDD workflow with mandatory enhanced data collection for designated countries",
"National FIU goAML API integration (per member state)",
],
diverges_from_others_on=[
"AMLA convergence will standardize EU national FIU formats — distinct from US and UK",
"UBO register query API requirement — no US/UK equivalent statutory register",
"ECJ restrictions on public UBO register access require legitimate interest verification",
],
))
cornerstone.add_framework(RegulatoryFramework(
jurisdiction=Jurisdiction.UK,
domain=ComplianceDomain.AML_KYC,
primary_legislation="Money Laundering Regulations 2017 (as amended 2022)",
regulator="FCA / HMRC / NCA",
approach=RegulatoryApproach.HYBRID,
key_requirements=[
"Risk-based AML programme per JMLSG guidance",
"SAR filing to NCA (SARs Online)",
"Crypto asset business FCA registration",
"PEP/sanctions screening",
],
penalty_max="Unlimited fine + criminal prosecution",
technology_implications=[
"SAR filing via NCA SARs Online portal (distinct format from FinCEN)",
"JMLSG EDD trigger configuration (UK-specific trigger list)",
"FCA crypto AML registration workflow",
],
diverges_from_others_on=[
"JMLSG EDD triggers differ from EU AMLD high-risk country list in some respects",
"NCA SAR format different from both FinCEN and EU national FIU formats",
"Crypto registration with FCA (not passportable from EU)",
],
))
# Operational Resilience frameworks
cornerstone.add_framework(RegulatoryFramework(
jurisdiction=Jurisdiction.US,
domain=ComplianceDomain.OPERATIONAL_RESILIENCE,
primary_legislation="FFIEC Cybersecurity Assessment Tool / NIST CSF",
regulator="OCC / Federal Reserve / FDIC",
approach=RegulatoryApproach.VOLUNTARY,
key_requirements=[
"Business continuity planning",
"Technology risk management",
"Cyber risk assessment",
"Third-party risk management",
],
penalty_max="Varies by agency; MRAs and civil money penalties",
technology_implications=[
"NIST CSF profile documentation",
"BCP testing documentation for examiners",
"Third-party risk assessment workflow",
],
diverges_from_others_on=[
"No statutory equivalent to DORA or UK PS21/3 — guidance-based only",
"No mandatory ICT incident reporting timeline analogous to DORA 4h/72h/30d",
"No mandatory TLPT equivalent for US financial institutions",
],
))
cornerstone.add_framework(RegulatoryFramework(
jurisdiction=Jurisdiction.EU,
domain=ComplianceDomain.OPERATIONAL_RESILIENCE,
primary_legislation="DORA — Regulation (EU) 2022/2554",
regulator="National Competent Authorities / EIOPA / ESMA / EBA",
approach=RegulatoryApproach.RULES_BASED,
key_requirements=[
"ICT risk management framework",
"Major incident classification and reporting (4h/72h/30d)",
"Threat-led penetration testing (TLPT) every 3 years",
"ICT third-party contractual requirements (Article 30)",
"CTPP oversight participation",
],
penalty_max="Up to 1% of average daily worldwide turnover per day for ongoing violations",
technology_implications=[
"ICT incident classification engine (DORA RTS thresholds)",
"NCA notification workflow with 4h/72h/30d outputs",
"TLPT scheduling and results documentation",
"Vendor contract management with DORA Article 30 provisions",
],
diverges_from_others_on=[
"DORA CTPP oversight framework has no UK or US equivalent",
"TLPT mandatory every 3 years — UK CBEST similar but scope/frequency differs",
"ICT incident reporting timeline (4h initial) more prescriptive than UK PRIN 11",
],
))
cornerstone.add_framework(RegulatoryFramework(
jurisdiction=Jurisdiction.UK,
domain=ComplianceDomain.OPERATIONAL_RESILIENCE,
primary_legislation="FCA/PRA PS21/3",
regulator="FCA / PRA",
approach=RegulatoryApproach.PRINCIPLES_BASED,
key_requirements=[
"Important Business Services identification",
"Impact tolerance setting per IBS",
"Self-assessment annual requirement",
"Scenario testing within tolerances",
],
penalty_max="Unlimited financial penalty",
technology_implications=[
"IBS mapping tool (people, process, technology, third-party dependencies)",
"Impact tolerance monitoring dashboard",
"Scenario test documentation workflow",
],
diverges_from_others_on=[
"IBS / impact tolerance model differs from DORA ICT risk management framework",
"CBEST TLPT regime differs from DORA TLPT in scope and frequency",
"No CTPP designation framework — UK CTP regime under Financial Services and Markets Act",
],
))
# Data Privacy frameworks
cornerstone.add_framework(RegulatoryFramework(
jurisdiction=Jurisdiction.US,
domain=ComplianceDomain.DATA_PRIVACY,
primary_legislation="GLBA / CCPA/CPRA (California) / State patchwork",
regulator="FTC / State AGs / CFPB",
approach=RegulatoryApproach.HYBRID,
key_requirements=[
"GLBA Safeguards Rule (information security program)",
"CCPA consumer rights (access, deletion, opt-out) for CA residents",
"GLBA privacy notices",
"State privacy law compliance as applicable",
],
penalty_max="CCPA: $7,500 per intentional violation; GLBA: $100,000 per violation",
technology_implications=[
"CCPA consumer rights portal (access, deletion, opt-out requests)",
"GLBA Safeguards compliance documentation",
"State-by-state privacy flag in CRM",
],
diverges_from_others_on=[
"No right to erasure under GLBA — BSA retention requirements override deletion",
"Opt-out model (CCPA) differs from opt-in consent model (GDPR)",
"No DPO requirement — unlike GDPR",
],
))
cornerstone.add_framework(RegulatoryFramework(
jurisdiction=Jurisdiction.EU,
domain=ComplianceDomain.DATA_PRIVACY,
primary_legislation="GDPR — Regulation (EU) 2016/679",
regulator="National Data Protection Authorities / EDPB",
approach=RegulatoryApproach.RULES_BASED,
key_requirements=[
"Lawful basis for all processing",
"Right to erasure (Article 17)",
"Data portability",
"DPO appointment (for large-scale processing)",
"Data transfers: adequacy or SCCs required",
"72-hour breach notification to DPA",
],
penalty_max="€20 million or 4% of global annual turnover (whichever higher)",
technology_implications=[
"Consent management platform with GDPR-compliant consent records",
"DSAR (Data Subject Access Request) workflow",
"Erasure workflow — with BSA/AML retention override logic",
"Data transfer impact assessment for non-EU transfers",
"DPA breach notification workflow (72h)",
],
diverges_from_others_on=[
"Right to erasure conflicts with BSA 5-year retention in global deployments",
"DPO requirement — no equivalent in US or Singapore",
"Data transfer restrictions most onerous globally (SCCs / adequacy)",
],
))
cornerstone.add_framework(RegulatoryFramework(
jurisdiction=Jurisdiction.UK,
domain=ComplianceDomain.DATA_PRIVACY,
primary_legislation="UK GDPR / Data Protection Act 2018",
regulator="ICO",
approach=RegulatoryApproach.RULES_BASED,
key_requirements=[
"Mirrors EU GDPR substantively",
"ICO registration",
"72-hour breach notification to ICO",
"UK adequacy maintained with EU",
],
penalty_max="£17.5 million or 4% of global turnover",
technology_implications=[
"ICO breach notification workflow (distinct from EU DPA workflows)",
"UK-specific DSAR handling (ICO guidance)",
"UK-EU data transfer adequacy monitoring",
],
diverges_from_others_on=[
"Separate ICO as regulator — notifications distinct from EU DPA notifications",
"UK may diverge from EU GDPR over time under Data Protection and Digital Information Act",
"UK adequacy with EU must be maintained — risk of divergence if UK law changes materially",
],
))
# ── Running the Analysis ───────────────────────────────────────────────────
print("CORNERSTONE FINANCIAL GROUP — MULTI-JURISDICTIONAL COMPLIANCE ANALYSIS")
print("="*70)
print("\n1. DIVERGENCE ANALYSIS: AML / KYC Domain")
print("-"*50)
aml_divergences = cornerstone.divergence_analysis(ComplianceDomain.AML_KYC)
for d in aml_divergences:
print(f" {d}")
print("\n2. DIVERGENCE ANALYSIS: OPERATIONAL RESILIENCE Domain")
print("-"*50)
or_divergences = cornerstone.divergence_analysis(ComplianceDomain.OPERATIONAL_RESILIENCE)
for d in or_divergences:
print(f" {d}")
print("\n3. TECHNOLOGY REQUIREMENTS SUMMARY")
cornerstone.print_matrix_summary()
print("\n4. COVERAGE GAPS (unmapped jurisdiction-domain combinations)")
print("-"*50)
gaps = cornerstone.coverage_gaps()
if gaps:
for j, d in gaps:
print(f" GAP: {j.value} × {d.value}")
else:
print(" No gaps — all combinations mapped.")
print("\n5. RISK SCORES (higher = higher priority attention)")
print("-"*50)
scores = cornerstone.risk_score()
sorted_scores = sorted(scores.items(), key=lambda x: x[1], reverse=True)
for (j, d), score in sorted_scores[:10]:
status = "UNMAPPED" if (j, d) not in cornerstone._frameworks else "mapped"
print(f" Score {score:3d} | {j.value:20s} | {d.value:35s} [{status}]")
The output reveals Cornerstone's priority areas: the unmapped market surveillance and AI governance cells score highest, signaling where the compliance team's next jurisdictional mapping exercise should focus. The data privacy divergences — particularly the GDPR right-to-erasure conflict with BSA retention — surface as the highest-priority mapped cells, confirming what Rafael would tell any global bank: the data privacy architecture requires bespoke cross-jurisdictional design, not a single global policy.
Section 6: The Map Becomes the Recommendation
Rafael Torres spent six weeks completing Meridian Global Bank's jurisdictional comparison matrix. The deliverable was twelve pages: five jurisdictions, five domains, twenty-five cells, each populated with the primary legislation, regulator, key requirements, and technology implications. Eight of the twenty-five cells contained specific technology requirements that differed materially from at least one other jurisdiction's requirements for the same domain. Seven of those eight differences had direct platform selection implications.
Sarah Whitfield reviewed the matrix in a second meeting. She turned to the data privacy section and stopped. "This is the first time I've seen our regulatory obligations laid out side by side," she said. "I didn't realize how different the data privacy requirements are between the EU and Singapore for the same data. We've been applying GDPR globally — for simplicity — but the consent frameworks are genuinely different."
Rafael nodded. "Most firms don't realize it. They apply their strictest framework globally, which sounds conservative, but GDPR's right to erasure conflicts with your US BSA retention obligations. Applying GDPR globally doesn't solve your problem — it creates a different one."
Whitfield looked up. "So what do we do?"
"You design jurisdiction-specific consent and retention configurations within a single system. Same platform, different configurations per customer jurisdiction. It's achievable — but you need to buy the right platform."
The bank shortlisted two platforms. Rafael mapped them both against the full matrix. The first covered eight of the ten most material requirements — including AMLA-compatible UBO tracking, DORA incident reporting, and ICO breach notification workflows. The second covered seven but was stronger on the Singapore PDPA data portability module, which was not a gap in the most critical domains.
The recommendation was the first platform. "The map tells you what the destination is," Rafael said. "Then you find the best route." He paused. "And sometimes the best route isn't the one with the lowest price tag."
Whitfield approved the recommendation the following week. The procurement process had taken three months from first conversation to decision — longer than she had expected. But the alternative, Rafael knew, was what he had seen at other firms: a platform selected on price, deployed globally, and discovered to have gaps when the regulators asked questions. That discovery, in his experience, was always more expensive than the map.
Summary
Global RegTech operates across a matrix of jurisdictions and compliance domains that do not resolve to a single unified framework. FATF, FSB, BIS, and IOSCO have driven substantial convergence at the principles level — but implementation diverges meaningfully across the US, EU, UK, Singapore, and Hong Kong in every major compliance domain. AML frameworks share a risk-based approach but diverge on SAR formats, beneficial ownership thresholds, and reporting infrastructure. Operational resilience ranges from DORA's prescriptive statutory framework in the EU to guidance-based practice in the US. AI governance spans the EU AI Act's comprehensive risk-tiered regulation to Singapore's voluntary FEAT principles. Data privacy is anchored by GDPR in the EU but varies from a sectoral patchwork in the US to a consent-based framework in Singapore.
Technology selection for a multi-jurisdictional firm must begin with jurisdictional mapping. Where frameworks converge — sanctions screening, FATF typology detection, market abuse indicators — shared platforms with jurisdiction-specific configuration work. Where frameworks diverge — SAR filing formats, data consent architectures, ICT incident reporting timelines — customization is unavoidable and must be specified before procurement. The jurisdictional compliance matrix is not a compliance deliverable in its own right. It is the foundation on which platform selection, vendor due diligence, and architecture decisions must rest.
The map comes first.