Appendix C: Key Regulations Primer

Essential Regulatory Context for RegTech Practitioners

This primer provides plain-language summaries of the key regulations referenced throughout the textbook. Each entry covers: what the regulation requires, who it applies to, key obligations, and its RegTech relevance. This primer is orientation-level — for compliance decisions, consult the primary legislation and qualified legal counsel.

Regulations are current as of early 2025. All regulations are subject to amendment; verify current requirements through primary sources.

EU Regulations

EU AI Act (Regulation (EU) 2024/1689)

Short name: EU AI Act Adopted: August 2024 Phased implementation: Prohibited practices (August 2024); GPAI provisions (August 2025); High-risk AI provisions (August 2026) Regulator: National market surveillance authorities; European AI Office (for GPAI models) Scope: Any person placing AI systems on the EU market or using AI systems in the EU — including firms outside the EU whose AI systems affect EU persons

What It Requires

The EU AI Act establishes a risk-based framework with four tiers:

Tier 1 — Prohibited AI: AI systems that pose unacceptable risks are banned outright. Prohibited practices include: social scoring by public authorities; manipulation of vulnerable persons; real-time remote biometric identification in public spaces (with exceptions); emotion recognition in workplaces and schools.

Tier 2 — High-Risk AI: AI systems listed in Annex III, including credit scoring, hiring tools, and KYC biometric systems, must meet requirements covering: risk management systems (Article 9); data governance for training data (Article 10); technical documentation (Article 11); automatic logging (Article 12); transparency obligations (Article 13); human oversight (Article 14); and accuracy and robustness (Article 15). Conformity assessment is required before market placement.

Tier 3 — Limited Risk AI: Chatbots and certain AI content generation systems must disclose that they are AI.

Tier 4 — Minimal Risk AI: No specific obligations.

RegTech Relevance

Financial services AI systems that fall within Annex III — including credit scoring models, AML transaction monitoring systems classified as high-risk, KYC facial recognition systems — must meet the high-risk AI requirements. The human oversight requirements (Article 14) and the explanation obligation interact with existing GDPR Article 22 obligations. The conformity assessment obligation requires institutions to document their compliance before deployment.

Key Articles: Arts. 5 (prohibitions), 9 (risk management), 10 (data), 13 (transparency), 14 (human oversight), 28-29 (obligations of deployers)

DORA — Digital Operational Resilience Act (Regulation (EU) 2022/2554)

Short name: DORA Effective date: 17 January 2025 Regulator: National competent authorities (FCA, PRA, BaFin, AMF, etc.); EBA/ESMA/EIOPA Scope: All EU-regulated financial entities — credit institutions, investment firms, payment institutions, e-money institutions, insurance undertakings, crypto-asset service providers; also ICT third-party service providers designated as Critical Third-Party Providers (CTPPs)

What It Requires

ICT Risk Management (Arts. 5–16): Financial entities must maintain an ICT risk management framework with: asset classification and protection; detection capability; response and recovery plans; post-incident analysis and improvement; and management body accountability and training.

ICT Incident Management and Reporting (Arts. 17–23): Financial entities must classify ICT incidents using criteria in the DORA Level 2 delegated regulations (affected users, duration, geographic spread, economic impact). Major incidents must be reported to the competent authority: initial notification within 4 hours of classification; intermediate report within 72 hours; final report within 30 days.

Digital Operational Resilience Testing (Arts. 24–27): Financial entities must test their ICT systems. Basic testing (vulnerability assessments, scenario-based tests) applies to all. Threat-Led Penetration Testing (TLPT) — based on the TIBER-EU framework — applies to significant entities every 3 years.

ICT Third-Party Risk (Arts. 28–44): Financial entities must manage third-party ICT risk. Contracts with ICT providers must include provisions from Article 30 (including audit rights, exit assistance, data portability, SLA terms). Critical Third-Party Providers (designated by the European Supervisory Authorities) are subject to direct oversight.

RegTech Relevance

DORA fundamentally changes the compliance profile of technology vendor relationships. Every material contract with a RegTech vendor must include Article 30 provisions. The incident reporting obligations create new compliance workflows — the CCO, not just the CISO, must manage the regulatory notification dimension of cyber incidents.

Key Articles: Arts. 5 (management body), 17 (incident classification), 19-23 (incident reporting), 24-27 (TLPT), 28-30 (third-party risk)

GDPR — General Data Protection Regulation (Regulation (EU) 2016/679)

Short name: GDPR Effective date: 25 May 2018 Regulator: National data protection authorities (DPAs); EDPB for cross-border matters Scope: Any processing of personal data in the EU, or processing of EU residents' data regardless of location

What It Requires

Principles (Art. 5): Personal data must be: processed lawfully, fairly, and transparently; collected for specified, explicit, and legitimate purposes (purpose limitation); adequate, relevant, and limited to what is necessary (data minimisation); accurate; not kept longer than necessary (storage limitation); processed securely.

Lawful basis (Art. 6): Processing must have a lawful basis — consent, contract, legal obligation, vital interests, public task, or legitimate interests. For AML monitoring: the legal obligation basis (compliance with MLR/AMLD obligations) applies. For fraud prevention: legitimate interests typically applies.

Rights (Arts. 15–22): Data subjects have rights of access (Art. 15), rectification (Art. 16), erasure (Art. 17), restriction (Art. 18), portability (Art. 20), and objection (Art. 21). Automated individual decision-making with significant effects requires either consent, contract necessity, or explicit legal authorization, plus the right to human review (Art. 22).

Security (Art. 32): Appropriate technical and organizational measures to ensure a level of security appropriate to the risk.

Data breach (Arts. 33–34): Notify the supervisory authority within 72 hours of becoming aware of a personal data breach. Notify affected individuals where the breach is likely to result in high risk.

Controllers and processors (Arts. 28–30): Processing by processors must be governed by a Data Processing Agreement. Controllers must maintain records of processing activities.

RegTech Relevance

Every RegTech system that processes personal data — which includes virtually all of them — must comply with GDPR. The tension between the right to erasure (Art. 17) and AML record retention obligations is a specific practical challenge. The Art. 22 right to human review of automated decisions interacts with AML and credit decisioning systems. The 72-hour breach notification interacts with cybersecurity incident response planning.

Key Articles: Arts. 5 (principles), 6 (lawful basis), 17 (erasure), 22 (automated decisions), 28 (processors), 32 (security), 33-34 (breach notification)

MiFID II (Directive 2014/65/EU) and MiFIR (Regulation 2014/600/EU)

Short names: MiFID II / MiFIR Effective date: 3 January 2018 Regulator: ESMA; national competent authorities (FCA, BaFin, AMF, etc.) Scope: Investment firms, trading venues, data reporting services providers in the EU

What They Require

Transaction reporting (MiFIR Art. 26): Investment firms must report transactions in financial instruments admitted to trading on EU trading venues. Reports must be made to the competent authority (directly or through an Approved Reporting Mechanism, ARM) by the end of the following working day. Reports must include instrument identification (ISIN), counterparty information (LEI), price, quantity, and execution venue.

Best execution (MiFID II Art. 27): Investment firms must take all sufficient steps to obtain the best possible result for clients when executing orders, considering price, costs, speed, likelihood of execution, and other factors. This must be monitored and reported.

Market abuse prevention (MAR, related Regulation 596/2014): Firms must have market surveillance systems that detect and report suspicious transactions (STORs) to the competent authority.

Algorithmic trading controls (MiFID II Arts. 17, 48): Firms using algorithmic trading must have systems and risk controls including kill switches, order-to-trade ratio limits, and pre-trade controls.

RegTech Relevance

MiFID II/MiFIR are the primary drivers of investment firm regulatory reporting and market surveillance RegTech investment. Transaction reporting to ESMA/FCA requires automated, high-volume data processing. Best execution monitoring requires analytics across order execution data. Market surveillance (Chapter 19-22) is a direct response to MiFID II/MAR obligations.

EU AML Regulation / AMLA Establishment

Short name: AMLAR / AMLA EU AML Regulation (proposed, 2021): Harmonizes AML obligations across EU; replaces the patchwork of national implementations of the AMLD directives AMLA Establishment Regulation (2024/1620): Creates the new EU Anti-Money Laundering Authority based in Frankfurt; will directly supervise certain obliged entities Effective date: AMLA operational from 2025; direct supervision from 2028

What It Requires

The EU AML Regulation creates directly applicable rules (not requiring national transposition) covering: CDD requirements; beneficial ownership; EDD; PEP requirements; correspondent banking; cash restrictions. The AMLA will directly supervise the highest-risk financial entities across borders.

RegTech Relevance

The EU AML Regulation will be the single applicable AML standard across all EU member states — replacing the current divergence across national implementations of the AMLD directives. This significantly affects multi-jurisdictional compliance programs that currently maintain country-specific AML procedures. The AMLA's direct supervision of high-risk entities creates a new regulatory relationship that compliance teams at designated firms must prepare for.

UK Frameworks

FCA Consumer Duty (PS22/9)

Short name: Consumer Duty Effective date: 31 July 2023 (existing products); 31 July 2024 (closed products) Regulator: FCA Scope: All FCA-regulated firms

What It Requires

The Consumer Duty establishes a higher standard of consumer protection. At its core: firms must act to deliver good outcomes for retail customers. The Duty comprises:

The Principle: Firms must act to deliver good outcomes for retail customers.

Three Cross-Cutting Rules: Act in good faith; avoid causing foreseeable harm; enable customers to pursue their financial objectives.

Four Outcome Areas: Products and services; price and value; consumer understanding; consumer support.

Firms must monitor the outcomes they are delivering, assess whether they are meeting the standard, and identify and remedy where they are not.

RegTech Relevance

Consumer Duty has significant implications for automated decision-making in financial services. Automated systems that systematically produce poor outcomes for customers — through discriminatory pricing, inadequate explanations, inaccessible products for vulnerable customers — may violate the Duty even if they are technically compliant with specific rules. The monitoring obligation (evidencing outcomes) drives demand for customer analytics and outcome measurement RegTech.

FCA/PRA Operational Resilience (PS21/3 / SS1/21)

Short name: Operational Resilience Framework Effective date: 31 March 2022 (initial); 31 March 2025 (full compliance including impact tolerance testing) Regulator: FCA and PRA Scope: Banks, building societies, PRA-designated investment firms, insurers; FCA framework for FCA-regulated firms

What It Requires

Firms must: identify their important business services (IBS); set impact tolerances for each IBS (the maximum time a disruption can be tolerated); map the people, processes, technology, facilities, and data that underpin each IBS; test ability to remain within impact tolerances; and make investments to remain within tolerances.

RegTech Relevance

Operational resilience is a significant driver of technology investment in risk management, business continuity, and incident response. The mapping requirement drives demand for dependency mapping tools. The testing requirement drives demand for scenario simulation platforms. The reporting requirement (when impact tolerances are breached) creates new compliance notification obligations.

Money Laundering Regulations 2017 (MLR 2017)

Short name: MLR 2017 Effective date: 26 June 2017 (multiple amendments since) Regulator: FCA, HMRC, other supervisory authorities by sector Scope: Financial institutions; credit institutions; lawyers; accountants; estate agents; other "obliged entities"

What It Requires

MLR 2017 implements the EU Fourth Money Laundering Directive (now superseded by EU AML Regulation for EU purposes). Key requirements: customer due diligence (CDD) for all customers; enhanced due diligence (EDD) for higher-risk situations; ongoing monitoring; SAR filing (under POCA 2002 and Terrorism Act 2000); record retention (5 years minimum); training.

JMLSG Guidance (Joint Money Laundering Steering Group) provides sector-specific guidance on how to meet MLR obligations. The JMLSG Guidance is not law but is the primary source of practical implementation guidance for UK financial institutions.

RegTech Relevance

MLR 2017 is the primary AML compliance driver for UK financial institutions. Every UK AML RegTech system — transaction monitoring, KYC platforms, SAR case management — is ultimately designed to meet MLR 2017 obligations. The JMLSG Guidance provides the transaction monitoring threshold and typology guidance that calibrates monitoring systems.

US Frameworks

Bank Secrecy Act (BSA) and FinCEN AML Rules

Short name: BSA / AML Original: 1970; multiple amendments including USA PATRIOT Act 2001, Anti-Money Laundering Act 2020 Regulator: FinCEN (Financial Crimes Enforcement Network); bank regulators for implementation; DOJ for enforcement Scope: Banks, broker-dealers, money services businesses, and other "financial institutions"

What It Requires

Customer identification and CDD: Know your customer; verify identity; understand the nature and purpose of the business relationship; identify beneficial owners of legal entity customers (CDD Rule, 2018).

Transaction monitoring and SAR: Maintain an AML program; monitor for suspicious activity; file SARs with FinCEN within 30 days of detecting suspicious activity.

Currency transaction reports (CTR): File CTR for cash transactions >$10,000.

Recordkeeping: Maintain records for minimum 5 years.

AML Program: Written policies and procedures; designated BSA Officer; independent testing; training.

RegTech Relevance

The BSA is the foundation of US AML compliance. Every US-regulated financial institution's AML monitoring system, KYC platform, and SAR case management system is ultimately calibrated to BSA requirements. FinCEN's SAR filing system (BSA E-Filing) accepts electronic SARs in a specific XML format that AML RegTech systems must produce.

SR 11-7: Guidance on Model Risk Management

Short name: SR 11-7 Issued: April 2011 Regulator: Federal Reserve Board; OCC (OCC Bulletin 2011-12) Scope: US banking organizations; applied by extension to model-using functions across financial services

What It Requires

SR 11-7 establishes the three-pillar framework for model risk management: (1) model development and implementation (sound methodology; appropriate data; testing); (2) independent model validation (performed by function separate from development; covers conceptual soundness, data analysis, outcomes); (3) governance and controls (model inventory; risk tiering; policy; escalation).

Key principle: all models must be validated — including vendor-supplied models. A financial institution cannot outsource its model risk management by purchasing a pre-built system.

RegTech Relevance

SR 11-7 is the most directly applicable governance standard for AI and ML models used in US compliance functions. Transaction monitoring models, fraud detection models, credit scoring models, and customer risk rating systems are all "models" within the SR 11-7 definition. The validation requirement creates a significant compliance obligation for institutions deploying vendor AI systems.

International Standards

FATF 40 Recommendations

Short name: FATF Recommendations Issued: 1990; last major revision 2012; ongoing updates Governing body: Financial Action Task Force (FATF); FATF-Style Regional Bodies (FSRBs) Scope: Non-binding but adopted (and made legally binding through national implementation) by 200+ jurisdictions

What They Require

The FATF 40 Recommendations establish the international standard for AML/CFT (anti-money laundering / counter-financing of terrorism). Key recommendations relevant to RegTech:

Recommendation 10: Customer due diligence (the international CDD standard) Recommendation 15: New technologies (requires countries to assess risks of new technologies; financial institutions to conduct risk assessments) Recommendation 16: Wire transfers (the Travel Rule — requires originator and beneficiary information for wire transfers) Recommendation 20: Suspicious transaction reporting Recommendation 22-23: Application of CDD to non-financial businesses and professions

FATF Mutual Evaluations assess each country's compliance with the Recommendations. The Mutual Evaluation results determine which countries appear on the FATF greylist (enhanced monitoring) and blacklist (call for countermeasures).

RegTech Relevance

FATF Recommendations are the source of most national AML compliance obligations. When MLR 2017 or the BSA require specific KYC or monitoring procedures, they are implementing FATF Recommendations. Understanding FATF provides the rationale behind specific national rules and helps anticipate regulatory evolution as FATF updates its standards.

BCBS 239: Principles for Effective Risk Data Aggregation and Risk Reporting

Short name: BCBS 239 Issued: January 2013 Governing body: Basel Committee on Banking Supervision Scope: Systemically important banks (G-SIBs and D-SIBs); applied as good practice across financial services

What It Requires

14 principles organized in four areas: (1) Overarching governance and infrastructure; (2) Risk data aggregation capabilities; (3) Risk reporting practices; (4) Supervisory review, tools, and cooperation.

Key principles include: data architecture and IT infrastructure supporting risk data aggregation (Principle 2); data accuracy and integrity (Principle 3); completeness of risk data capture (Principle 4); timeliness of risk data and reporting (Principle 5); adaptability to produce ad-hoc reporting (Principle 6).

RegTech Relevance

BCBS 239 is the foundational standard for risk data governance in banking — including compliance data. The compliance program integration challenge described in Chapter 40 (building integrated data flows, unified audit trails, consistent management information) is essentially a compliance-domain application of BCBS 239 principles. BCBS 239 compliance reviews by supervisors often surface the same integration failures that Chapter 40 identifies.

NIST Cybersecurity Framework 2.0

Short name: NIST CSF 2.0 Published: February 2024 Governing body: US National Institute of Standards and Technology Scope: Voluntary; widely adopted in US financial services; reference framework internationally

What It Provides

Six core functions (organized into categories and subcategories): 1. GOVERN (new in v2.0): Organizational context; risk management strategy; supply chain risk management 2. IDENTIFY: Asset management; risk assessment; improvement 3. PROTECT: Access control; awareness and training; data security; platform security; technology infrastructure resilience 4. DETECT: Continuous monitoring; adverse event analysis 5. RESPOND: Incident response management; communications; analysis; mitigation; improvements 6. RECOVER: Recovery planning; communications; improvements

RegTech Relevance

NIST CSF 2.0 is the primary voluntary cybersecurity framework adopted by US financial services institutions. The FFIEC CAT (Cybersecurity Assessment Tool) maps to NIST CSF. Chapter 33 provides the conceptual mapping between NIST CSF 2.0 and DORA's ICT risk management requirements — institutions with EU and US operations must maintain both frameworks.