Chapter 1: What Is RegTech? History, Definitions, and the Compliance Crisis

Opening: The Weight of Obligation

In January 2020, Maya Osei sat down at her new desk at Verdant Bank and opened her inbox to find 847 unread emails waiting for her. She had been hired as Chief Compliance Officer to lead the bank's compliance function — a role that, at Verdant's stage of growth, meant building a department nearly from scratch. The bank had grown fast, from a scrappy challenger app to a licensed deposit-taking institution with 340,000 customers, but its compliance infrastructure had not kept pace. There was a KYC backlog of roughly 14,000 customers whose identity verification was incomplete. There was a transaction monitoring system that produced hundreds of alerts per week, most of them reviewed by a team of three analysts who were already stretched. And in a regulatory review the previous quarter, the FCA had noted, in its careful but unmistakable language, that the firm's current compliance framework was "not commensurate with its growth trajectory."

Maya had a law degree and five years at the FCA itself, where she had supervised fintech firms and written guidance on digital identity verification. She knew what regulators wanted. What she had not fully reckoned with, in the abstract, was how hard it would be to provide it.

She closed the inbox and opened a blank document. At the top she typed: What actually needs to happen here?

This chapter is an attempt at an answer to that question — not for Verdant Bank specifically, but for the compliance function in financial services broadly. What is the problem that RegTech is attempting to solve? Where did the problem come from? What tools exist to address it? And how did a field called "regulatory technology" emerge as one of the most consequential specializations in finance?

1.1 The Compliance Burden: Why Regulation Became Unmanageable

The history of financial regulation is, at its core, the history of catastrophes. Regulations are rarely implemented proactively. They emerge, usually slowly and imperfectly, in response to something that went wrong — often very wrong.

The pattern is familiar: a financial crisis reveals gaps in oversight; legislators respond with new requirements; regulators implement rules; institutions struggle to comply; technology catches up with new compliance tools; another crisis reveals new gaps. The cycle repeats. Each iteration adds layers. The total weight of regulatory obligation grows.

What changed after the 2008 financial crisis was not the pattern itself, but its scale. The regulatory response to the global financial crisis — Dodd-Frank in the US, the Capital Requirements Directive IV (CRD IV) and Markets in Financial Instruments Directive II (MiFID II) in Europe, Basel III globally, and a raft of AML directives triggered by revelations about bank involvement in financial crime — produced something qualitatively different from previous regulatory waves. It produced a volume and complexity of obligation that simply could not be met by the compliance methods that had worked before.

The Numbers

Consider what compliance means in practice at a large financial institution in 2026:

• Regulatory change volume: A major global bank monitors approximately 300 significant regulatory changes per day across the jurisdictions in which it operates. That number comes from Thomson Reuters' annual regulatory intelligence survey, and it has grown every year since 2008.

• Cost of compliance: The Global Financial Regulatory Forum estimates the annual cost of compliance for the global financial industry at approximately $270 billion — a figure that excludes the costs of enforcement actions, remediation programs, and the regulatory capital that institutions must hold against model risk.

• Compliance headcount: At many large banks, compliance and risk management now employ more people than operations. For some smaller institutions, the compliance function represents a larger proportion of total staff than it did a decade ago.

• False positive burden: In anti-money laundering transaction monitoring alone, industry estimates suggest that more than 95% of alerts generated by monitoring systems are false positives — legitimate transactions flagged as potentially suspicious. Each alert requires human review. The aggregate cost of reviewing alerts that turn out to be nothing is staggering.

None of these numbers existed in their current form before 2010. They are the product of a regulatory wave that compliance functions built for a pre-crisis world were not designed to handle.

The Structural Mismatch

The core problem is a structural mismatch between the pace of regulatory obligation and the capacity of human labor to meet it. This mismatch has three dimensions:

Volume: There are simply more obligations than human analysts can efficiently process. A transaction monitoring team that can review 200 alerts per day cannot cope with a system that generates 500. An operations team that can complete 50 KYC reviews per day cannot close a backlog of 14,000.

Speed: Modern financial markets operate at speeds that human monitoring cannot match. Algorithmic trading can execute thousands of transactions per second. Market manipulation can occur and disappear within minutes. By the time a human analyst reviews a trading report, the relevant activity may be weeks in the past and the evidence scattered across systems.

Complexity: Regulatory requirements are increasingly interconnected and technically complex. The FRTB (Fundamental Review of the Trading Book) requires modelling approaches that demand sophisticated statistical expertise. GDPR data subject access requests require tracking personal data across dozens of systems. Beneficial ownership verification requires traversing corporate ownership structures that may cross dozens of jurisdictions.

Human compliance processes can solve any one of these problems in isolation. They cannot solve all three simultaneously at the scale modern institutions require. Something else is needed.

1.2 Defining RegTech: A Taxonomy of Definitions

The term "regulatory technology" or "RegTech" entered mainstream use around 2015–2016, popularized in part by the UK's Financial Conduct Authority, which began actively promoting the term as a descriptor for technology solutions to compliance problems. But like most terms that enter use before their referent is well-defined, it has meant different things to different people.

Working Definitions

Three influential definitions provide useful anchors:

The FCA definition (2016): "Technologies that facilitate the delivery of regulatory requirements more efficiently and effectively than existing capabilities." This is a broad, function-oriented definition. It centers on delivery of regulatory requirements — the what — rather than the how.

The Institute of International Finance definition (2016): "A subset of FinTech that focuses on technologies that may facilitate the delivery of regulatory requirements more efficiently and effectively than existing capabilities." The IIF definition places RegTech within the broader FinTech ecosystem while identifying its distinctive focus.

The practitioner definition that has emerged through use: RegTech refers to technology solutions — principally software, data services, and analytics — that help financial institutions comply with regulatory obligations, report to regulators, manage compliance risk, and monitor regulatory change. It is distinguished from general FinTech by its orientation toward regulatory compliance rather than commercial product innovation.

What RegTech Is Not

The definition becomes clearer by exclusion:

RegTech is not compliance itself. Compliance is the organizational function and legal obligation. RegTech is a set of tools and approaches for meeting compliance obligations more efficiently. The distinction matters because technology cannot substitute for compliance judgment — it can only augment it.

RegTech is not FinTech. FinTech encompasses the full range of technology innovation in financial services: payments, lending, wealth management, insurance, and more. RegTech is a subset with a specific focus. A payments startup is FinTech. A transaction monitoring system is RegTech. Some companies are both, but the categories are not synonymous.

RegTech is not LegalTech. LegalTech refers to technology that supports legal practice: document automation, e-discovery, contract analysis, legal research tools. There is significant overlap — particularly in areas like regulatory horizon scanning and contract analysis for compliance purposes — but LegalTech broadly serves the legal profession, while RegTech specifically serves financial services compliance.

RegTech is not a single technology. It is a category of application, not a category of underlying technology. The same machine learning techniques might power fraud detection (RegTech) or credit underwriting (FinTech), depending on the application.

A Functional Framework

For purposes of this book, we will use a functional framework that organizes RegTech solutions into five families based on the compliance problem they address:

These five families are not exhaustive, and many solutions span multiple categories. But they provide a useful organizing principle for the chapters ahead.

1.3 A Brief History: From Manual Compliance to Machine Learning

RegTech did not emerge from nowhere. It has a history — both a technological history and a regulatory history — and understanding that history illuminates why the field has developed as it has.

Phase 1: The Paper Era (Pre-1990s)

Compliance in financial services before the computing era was almost entirely manual. Customer records were kept on paper or on card files. Transaction reporting was done by hand. Suspicious activity was identified — to the extent it was identified at all — by branch employees who recognized irregular patterns in their daily interactions with customers.

This was compliance by necessity: slow, incomplete, and highly dependent on individual judgment. Its limitations were severe, but for institutions of modest size operating in simpler regulatory environments, it functioned.

Phase 2: Electronic Record-Keeping and Early Rules (1990s)

The arrival of computing in financial services brought the first wave of compliance automation: electronic record-keeping, basic transaction surveillance, and early rules-based systems. The Bank Secrecy Act in the US, enacted in 1970 but enforced increasingly seriously in the 1990s, drove financial institutions to build the first generation of automated transaction monitoring — simple threshold-based systems that flagged cash transactions above $10,000 and generated Currency Transaction Reports.

These systems were crude by modern standards. They operated on simple Boolean rules (if X, then flag) without any statistical sophistication. But they established the conceptual template — automated rules applied to transaction data to identify potentially reportable activity — that would persist for decades.

Phase 3: The Regulatory Wave and Its Aftermath (2001–2012)

The September 11, 2001 attacks drove a massive expansion of AML and counter-terrorism financing requirements under the USA PATRIOT Act. For the first time, financial institutions were required not just to report suspicious transactions but to implement comprehensive customer due diligence programs and to screen customers against government watchlists. This expanded the scope of compliance automation significantly.

Then came 2008. The global financial crisis generated the largest single wave of financial regulation in history. Within five years of the crisis, institutions were implementing:

• Dodd-Frank's hundreds of implementing rules across derivatives, consumer protection, and systemic risk
• MiFID II's sweeping reforms to trading, product governance, and best execution
• Basel III's new capital and liquidity requirements
• FATCA's global account reporting requirements
• The Fourth and Fifth EU AML Directives
• GDPR's data protection requirements (finalized 2018, effective 2018)

Each of these regulatory programs generated implementation workloads that exceeded the capacity of existing compliance teams. The demand for technology solutions exploded.

Phase 4: The RegTech Era (2013–Present)

The term "RegTech" emerged into common use around 2015, but the field it described had been forming for several years. The confluence of three developments created it:

The regulatory demand was already documented above — a volume and complexity of compliance obligation that manual processes could not handle.

The technology supply reached a tipping point. Cloud computing made scalable infrastructure accessible without capital expenditure. Machine learning frameworks became practical for business applications. Natural language processing reached a level of maturity that made regulatory text analysis viable. API-first architectures enabled integration between systems.

The capital investment arrived. Venture capital discovered RegTech as a category around 2015–2016 and invested heavily. By 2020, annual global investment in RegTech had reached several billion dollars annually. The investment created a wave of purpose-built solutions that incumbents had little incentive to build for themselves.

🔗 Chapter Connection: The RegTech market as it exists today — vendors, investors, and dynamics — is the subject of Chapter 3. The technology foundations underlying the field are covered in Chapter 4.

Timeline: Key Regulatory Drivers of RegTech

1970  Bank Secrecy Act (US) — first AML reporting requirements
1989  FATF established — global AML standard-setter created
2001  USA PATRIOT Act — expands AML/CFT obligations dramatically
2007-09  Global Financial Crisis — triggers unprecedented regulatory wave
2010  Dodd-Frank enacted (US)
2012  HSBC settlement ($1.9B) — AML failures become front-page news
2013  Basel III begins phased implementation
2015  MiFID II finalized (EU) — effective 2018
2016  GDPR finalized (EU) — effective 2018
2016  FCA begins actively promoting "RegTech" as a concept
2018  5AMLD (EU AML Directive) — corporate transparency requirements
2020  6AMLD — criminal liability for money laundering
2022  DORA finalized (EU) — digital operational resilience
2024  EU AI Act — AI regulation enters compliance scope
2025  Basel IV capital requirements fully phased in

1.4 The 2008 Financial Crisis as RegTech Catalyst

The financial crisis of 2007–2009 deserves extended attention because it is the single most important driver of the regulatory environment that RegTech exists to address. Understanding what went wrong — not just economically, but from a compliance and risk management perspective — illuminates why the post-crisis regulatory response took the shape it did.

What Failed in the Compliance System

The crisis revealed multiple simultaneous failures in how financial institutions managed compliance and risk:

Model risk: Financial institutions relied on quantitative models — particularly models of mortgage default correlation — that had been validated under conditions that turned out to be unrepresentative of stress scenarios. When housing markets declined nationally rather than locally, the models broke. The Basel II framework, which had allowed institutions to use their own models for capital calculation, had not imposed sufficient governance requirements around model validation, documentation, or challenge.

Data fragmentation: At the height of the crisis, major financial institutions discovered they could not quickly aggregate their own exposure to specific counterparties or securities. Data was scattered across systems that didn't talk to each other, maintained in formats that weren't consistent, and governed by organizational silos that prevented enterprise-wide analysis. The Basel Committee's subsequent BCBS 239 principles for risk data aggregation were a direct response to this failure.

Conduct risk: The "originate-to-distribute" model for mortgage lending created systematic incentives for loan origination without regard for borrower creditworthiness. Compliance systems were not designed to monitor for this type of conduct risk — they were looking for fraud, not for legal behavior that was nonetheless harmful. The CFPB (Consumer Financial Protection Bureau) was created by Dodd-Frank specifically to address this gap.

AML failures: Separate from the financial crisis but parallel in timing, a series of revelations about large-scale money laundering through global banks — HSBC's 2012 settlement being the most prominent — demonstrated that AML compliance programs at major institutions were fundamentally inadequate for the volume of transactions they were processing.

The Regulatory Response

The post-crisis regulatory response was shaped by these specific failures, which is why it looks the way it does:

• Model risk management guidance (SR 11-7, EBA guidelines on internal models) addressed the model failure
• BCBS 239 addressed the data aggregation failure
• Conduct regulation (FSMA amendments, MiFID II product governance) addressed the conduct risk failure
• Enhanced AML directives and enforcement addressed the financial crime failure

Each of these regulatory responses created new compliance workloads. And the aggregate workload exceeded what compliance functions were equipped to handle. That is the origin story of RegTech as an industry.

1.5 The Five Families of RegTech: A Functional Framework

Earlier in this chapter we introduced a five-family taxonomy for organizing RegTech solutions. Let us now examine each family in more depth.

Family 1: Identity and Onboarding

The obligation to know who you are doing business with is the foundation of financial crime compliance. KYC — Know Your Customer — requires financial institutions to verify the identity of their customers before establishing a relationship, and to maintain and update that verification over time.

Traditional KYC was a manual process. A customer would submit identity documents (passport, driver's license, utility bill). A compliance analyst would review the documents, check them against databases, and make a judgment. The process took days, sometimes weeks.

RegTech solutions in this family automate and accelerate that process:

• Document capture and OCR: Customers photograph documents on their phones; optical character recognition extracts the data
• Document authentication: Machine vision checks security features, expiry dates, and formatting consistency
• Biometric verification: Facial recognition compares a selfie to the document photo; liveness detection confirms the person is present
• Database screening: Names are automatically checked against PEP (politically exposed persons) lists, sanctions lists, and adverse media sources
• eIDV: Electronic identity verification pulls data from credit bureaus, government databases, and telecoms companies to confirm identity without documents

The business case is straightforward: KYC automation can reduce the time required to onboard a retail customer from days to minutes, while maintaining or improving compliance quality.

📋 Maya's Situation: Verdant Bank's KYC backlog — 14,000 customers with incomplete verification — is a textbook case for Family 1 RegTech. Any solution Maya considers will need to address both the backlog and the ongoing process for new customers. We will follow her through the KYC automation decision in Chapters 6 and 10.

Family 2: Financial Crime Compliance

This family encompasses the technology solutions for detecting, investigating, and reporting financial crime: money laundering, fraud, sanctions violations, and related illicit activity.

The core challenge is statistical: financial crime is rare relative to the volume of legitimate transactions, but the consequences of missing it are severe. The technology question is how to find the needles in a very large haystack without generating so many false positives that the review process becomes unmanageable.

Transaction monitoring systems apply rules, statistical models, and increasingly machine learning to identify transaction patterns consistent with money laundering typologies. A customer who receives many small deposits that are immediately withdrawn (a pattern associated with structuring) might trigger a monitoring alert.

Sanctions screening checks customer names and transaction counterparties against government watchlists of sanctioned individuals and entities. The technical challenge is name matching across languages, transliterations, and spelling variations.

Fraud detection models distinguish fraudulent transactions from legitimate ones in real time — often in the fraction of a second available between a card payment and its authorization.

Graph analytics maps the relationships between accounts, entities, and transactions to identify patterns — money mule networks, circular payment schemes — that would be invisible when looking at individual transactions in isolation.

🔗 Chapter Connection: Part 2 (Chapters 6–11) is dedicated entirely to this family, with detailed treatment of the technology, the regulatory requirements, and the implementation challenges.

Family 3: Risk and Regulatory Reporting

Financial institutions are required to calculate and report a vast array of risk metrics and position data to regulators on schedules ranging from daily to quarterly. The quality of this reporting has improved dramatically with technology, and the consequences of errors — late submissions, incorrect data, regulatory breaches — can be severe.

Regulatory reporting platforms aggregate data from across institutional systems, apply the calculation logic specified in regulatory standards, and generate reports in the required format (often XBRL, the eXtensible Business Reporting Language).

Capital calculation engines implement the Basel framework's complex rules for calculating risk-weighted assets and minimum capital requirements.

Liquidity monitoring tracks daily LCR (Liquidity Coverage Ratio) and NSFR (Net Stable Funding Ratio) calculations and provides intraday visibility into liquidity positions.

Model risk management tools maintain the model inventory, track validation status, and document the governance processes required by regulators.

🔗 Chapter Connection: Part 3 (Chapters 12–17) covers this family in detail.

Family 4: Trading Compliance

Securities markets are regulated for both integrity (ensuring prices reflect genuine supply and demand rather than manipulation) and investor protection (ensuring clients receive suitable advice and best execution). Technology solutions in this family monitor trading activity against these requirements.

Trade surveillance systems analyze trading data in real time and historically to identify patterns consistent with market abuse: spoofing, layering, front-running, and insider dealing.

Best execution monitoring measures whether trades executed on behalf of clients were executed at prices and conditions consistent with the firm's best execution obligations.

Algorithmic trading controls implement pre-trade risk checks (position limits, order size limits) and kill switches (the ability to immediately halt all trading activity) required by regulators.

Communications surveillance monitors voice recordings, emails, chat messages, and other communications for patterns consistent with misconduct.

🔗 Chapter Connection: Part 4 (Chapters 18–22) covers this family.

Family 5: Regulatory Intelligence

Financial institutions must monitor regulatory change, understand its impact on their operations, and manage the implementation of new requirements. This process — sometimes called "horizon scanning" — is both labor-intensive and critically important.

Regulatory change management platforms aggregate regulatory news, publications, and updates from agencies worldwide, categorize them by relevance, and help compliance teams manage implementation.

NLP-based obligation extraction uses natural language processing to read regulatory text and extract specific compliance obligations in a structured, actionable format.

Regulatory mapping tools maintain a library of compliance obligations and their relationship to internal policies, controls, and evidence.

🔗 Chapter Connection: Chapter 23 covers NLP for regulatory intelligence in detail. Chapter 39 discusses the future direction of machine-readable regulation.

1.6 RegTech vs. FinTech vs. LegalTech: Overlaps and Distinctions

These three terms co-exist in the literature and in the industry, sometimes creating confusion. The table below maps the overlaps and distinctions:

The overlaps are real and commercially significant:

FinTech/RegTech overlap: Many FinTech companies are also RegTech companies by necessity. A digital bank that automates KYC is doing RegTech even if it thinks of itself as FinTech. A payments company that embeds AML monitoring in its platform is selling a RegTech capability. The distinction is whether compliance automation is the product or a feature of the product.

RegTech/LegalTech overlap: Regulatory text is legal text. Tools that analyze legal documents — for contract obligations, for regulatory requirements, for court filings — use similar NLP techniques. Companies like Luminance or Kira, which analyze contracts, have compliance-adjacent applications. The lines blur particularly in areas like regulatory horizon scanning and obligation management.

The practical implication: when you are evaluating vendors, do not be misled by category labels. Evaluate the specific solution against the specific compliance problem. A LegalTech contract analysis tool may be exactly the right solution for a regulatory obligation management challenge, even if it is not marketed as RegTech.

1.7 Meet the Characters: Maya, Rafael, Priya, and Cornerstone

Throughout this book, four recurring characters will ground the abstract concepts of RegTech in concrete professional reality. They are introduced fully here so that when they appear in later chapters, you can situate them immediately.

Maya Osei, Chief Compliance Officer, Verdant Bank

Maya is 32 years old. She grew up in Accra, Ghana, came to the UK for university on a scholarship, and studied law at UCL before joining the FCA as a supervisory officer in the fintech team. She spent five years there, supervising challenger banks and writing guidance on digital identity verification, before being recruited as CCO by Verdant Bank's CEO, who knew her from the supervision process.

At the FCA, Maya had the authority to ask for information, examine firms, and escalate concerns to enforcement. As CCO at Verdant, she has the obligation to provide that same quality of compliance on the inside. The transition is not as smooth as she expected.

Verdant Bank has 340,000 customers, growing by roughly 15,000 per month. It holds a banking license, which means it is supervised by the FCA for conduct and the PRA for prudential matters. It offers current accounts, savings, and — since eighteen months ago — personal loans. Each product line carries its own regulatory requirements.

Maya's immediate priorities: close the KYC backlog, fix the transaction monitoring alert process, and build a regulatory reporting capability that can keep up with the firm's growth. She has a team of six compliance analysts, a budget that is better than what she expected but insufficient for everything she needs, and a CEO who is supportive but primarily focused on growth metrics.

Maya's character trajectory across this book: she begins as someone who understands regulation deeply but is learning how to manage technology and organizational change. By Part 7, she will have built a compliance function that is genuinely technology-enabled — and she will have learned some hard lessons along the way about what technology can and cannot fix.

Rafael Torres, VP Compliance Technology, Meridian Capital

Rafael is 45 years old. He was born in Puerto Rico, graduated with a degree in industrial engineering, and spent his early career in financial services operations — settlement, clearing, reconciliation. He moved into compliance operations in his mid-thirties when Meridian Capital, his employer for the past twelve years, decided that someone with his process discipline was needed in the compliance function.

He has been VP of Compliance Technology for four years. His department sits at the intersection of compliance and technology — he reports to the CCO but has a dotted line to the CTO, and his mandate is to own the technology that the compliance function runs on. He manages a team of eight, including three compliance analysts, three data engineers, and two vendor relationship managers.

Meridian Capital is a mid-size US broker-dealer with about 1,200 employees, primarily in New York, with a small London office that handles European client relationships. It serves institutional clients (hedge funds, asset managers, corporates) as well as a retail brokerage business that was acquired five years ago. The European business needs to comply with MiFID II; the US business with SEC and CFTC requirements; and the AML program spans both.

Rafael's immediate priorities: complete the MiFID II equivalence implementation (eighteen months in, projected to take another year), overhaul the AML transaction monitoring system (the current system produces an unmanageable alert volume), and build a regulatory reporting pipeline that is less dependent on manual intervention than the current spreadsheet-heavy process.

Rafael's character trajectory: he is already further along the RegTech maturity curve than Maya. His challenge is less about building from scratch than about modernizing systems that technically work but are not good enough. He will encounter the political challenges of technology change in a legacy institution, the vendor management complexities of working with large incumbent providers, and the organizational challenge of being the person who has to make ambitious commitments on behalf of two different functions.

Priya Nair, Senior Associate, RegTech Advisory, Whitmore Partners (Big 4)

Priya is 28 years old. She was born and raised in Pune, India, where her father is a software engineer and her mother runs a small textile business. She studied computer science at IIT Bombay, then completed an MBA at London Business School with a concentration in financial services regulation. She joined Whitmore Partners — one of the Big 4 advisory firms — immediately after graduating and has spent three years in their RegTech advisory practice.

In those three years, Priya has worked on implementations at seventeen different financial institutions across nine countries. She has seen what RegTech programs look like when they are designed well and when they are not. She has sat in rooms where clients told her what they wanted — usually the cheapest, fastest solution — and where she had to figure out how to tell them that what they wanted was not what they needed without losing the engagement.

Her current client portfolio: a large UK asset manager building a MiFID II transaction reporting capability, a Singapore-based bank implementing a new KYC platform, and a US insurance company assessing its regulatory reporting maturity. She is also the lead on a thought leadership paper her firm is publishing on AI governance in compliance — a project she cares about more than the billable hour pressure would suggest.

Priya's character trajectory: she begins the book as a highly competent technician who is learning that her job is as much about managing organizational dynamics and client psychology as it is about technical analysis. By Part 7, she will have developed — through some failures — a more nuanced model of what successful RegTech implementation actually requires.

Cornerstone Financial Group

Cornerstone is not a person but an institution — a composite, fictionalized financial conglomerate that will appear throughout the book as a data-rich case study.

Cornerstone's structure: - Cornerstone Bank NA — a mid-size US retail and commercial bank, OCC-regulated - Cornerstone Capital Markets — a UK-regulated investment management subsidiary - Cornerstone Securities — a US broker-dealer, SEC/FINRA regulated - Cornerstone Asset Management (Europe) — an EU-regulated fund manager based in Dublin

In aggregate, Cornerstone has approximately $120 billion in assets under management and custody, 4,200 employees, and regulatory relationships with at least eight significant regulatory bodies across three jurisdictions. It is large enough to face sophisticated regulatory requirements but not a global systemically important institution (G-SII) with the most extreme prudential demands.

Cornerstone appears in chapters where we need to illustrate institutional-scale compliance challenges — the ones that don't arise at Verdant's scale but that Priya's clients face regularly.

1.8 Chapter Summary

This chapter has established the conceptual and historical foundations for everything that follows.

The compliance burden: Post-2008 financial regulation has created an obligation environment that manual compliance processes cannot efficiently meet. The combination of regulatory volume, speed requirements, and technical complexity has driven the search for technological solutions.

RegTech defined: Regulatory technology refers to solutions — software, data services, analytics — that help financial institutions comply with regulatory obligations more efficiently and effectively than manual processes allow. It is distinct from FinTech (which innovates financial products) and LegalTech (which supports legal practice), though it overlaps with both.

The five families: RegTech solutions cluster into five functional areas: Identity and Onboarding, Financial Crime Compliance, Risk and Regulatory Reporting, Trading Compliance, and Regulatory Intelligence.

The historical arc: RegTech emerged from the convergence of regulatory demand (post-2008 wave), technology supply (cloud, ML, NLP), and investment capital (VC discovery of the category). It is a young field, but it is already transforming compliance practice.

The characters: Maya Osei, Rafael Torres, Priya Nair, and Cornerstone Financial Group are introduced. Their challenges will run through every chapter of this book.

⚖️ Regulatory Alert: The term "RegTech" is descriptive, not prescriptive. Regulators do not grant compliance credit for using RegTech tools. The obligation is to comply with the substantive requirement; technology is one means of doing so. Regulatory failures that occur through automated systems are treated as regulatory failures — the automation is not a mitigating factor.

Key Terms Introduced in This Chapter

RegTech: Technology solutions applied to regulatory compliance challenges in financial services.

KYC (Know Your Customer): The regulatory obligation to verify the identity of customers before establishing a business relationship and to maintain that verification over time.

AML (Anti-Money Laundering): The legal and regulatory framework requiring financial institutions to detect and report suspicious activity that may involve money laundering.

SupTech: Technology used by regulatory supervisors (rather than supervised institutions) to improve their oversight capabilities.

FATF: The Financial Action Task Force, an intergovernmental body that sets global standards for AML/CFT (combating the financing of terrorism).

False positive: An alert or flag generated by a monitoring system for activity that is ultimately determined to be legitimate.

XBRL: eXtensible Business Reporting Language, a standardized format used for regulatory reporting submissions.

Continue to Chapter 2: The Regulatory Landscape →