Chapter 39: The Future of RegTech — SupTech, Digital Regulation, and What's Next

"I don't know what compliance will look like in ten years. But I know that compliance professionals who understand technology will be better positioned than those who don't. That much I'm certain of."

— Maya Osei, CCO, Verdant Bank

Opening: The Panel

The moderator's question was not a difficult one — it was the kind of question that every RegTech conference moderator asks, because it reliably generates interesting answers, confident assertions, and the occasional useful insight. She leaned forward slightly at the center of the dais and addressed the three panelists.

"You've all spent the last twenty minutes talking about what's happened in compliance technology over the past decade. Now I want to turn to the future. What does RegTech look like in ten years?"

Priya Nair answered first. She was the youngest person on the panel — not by a small margin — and she had learned over the past two years as a Partner at her firm that the most important change in her professional life was the confidence to begin speaking before she was certain. She was not certain now, but she spoke anyway.

"Ten years from now, I think we are going to be living in a world where the regulatory reporting cycle as we know it has essentially ended. Direct data feeds, API-based supervisory access, machine-readable rules — these are not aspirational anymore. They are in pilot programs. They are in FCA working groups. The question is not whether they are coming. The question is how fast, and whether institutions are building the data architecture now to be ready when they arrive." She paused. "I'm optimistic. This field has delivered real change in the last decade. The next decade will deliver more."

Rafael Torres waited. He was the kind of speaker who let silence do work, and he was old enough in the industry not to fill it prematurely. When he spoke, there was a flatness to his delivery that was not cynicism exactly — it was something closer to earned skepticism, the kind that comes from having watched fifteen years' worth of "next big things" fail to transform compliance the way their enthusiasts promised.

"I've heard that answer before," he said, and the audience laughed, because the gentleness of the observation softened what might otherwise have landed as a rebuke. "I've heard it about robotic process automation. I've heard it about blockchain. I've heard it about natural language processing and the end of manual document review. And here's what I'll tell you: all of those technologies did something. Most of them did less than promised. Some of them created new problems that nobody anticipated. I'm not saying the future Priya is describing won't arrive. I'm saying it will arrive later, in a more complicated form, and with a longer list of things that still require humans than anyone standing at a conference panel today will admit."

Maya Osei was last, and she had the most complicated relationship with the question, because she was not a consultant or a former regulator or a vendor executive. She was the CCO of a live, growing, regulated institution, and the future was not abstract to her. The future was the email she would return to after this panel ended, about a forthcoming FCA consultation on supervisory data access. She thought for a moment before she spoke.

"I don't know," she said simply. "I mean that seriously. I don't know what compliance is going to look like in ten years, and I'm skeptical of anyone who says they do." A ripple of recognition moved through the room. "What I know is this: the compliance professionals who are going to be most effective in whatever that future looks like are the ones who understand both sides of this — who understand technology well enough to evaluate what it can and cannot do, and who understand regulation well enough not to outsource that judgment to a machine. The technology is going to keep changing. The requirement to exercise judgment is not."

She glanced at Rafael. "I'm not quite as skeptical as he is. I've seen real change at Verdant in the eighteen months I've been there. But I think Priya's timeline might be optimistic." She smiled at Priya. "It usually is."

This chapter is organized around Maya's answer. Not because it is more right than Priya's or Rafael's — it contains elements of both — but because it is the most honest. The future of RegTech is genuinely uncertain. What is knowable is the direction of travel, the forces driving it, the near-term developments that are already underway, and the skills and dispositions that will position compliance professionals well regardless of how precisely the future unfolds.

We will examine all of those things. And at the end, we will return to this panel — and to these three people — to hear what they have learned and where they are going.

Section 1: The Current Trajectory — Where RegTech Is Now

A Decade of Change

The financial compliance function of 2015 and the compliance function of 2025 are recognizably related but meaningfully different. The changes are worth cataloguing clearly, because understanding what has actually changed — as opposed to what was promised — is the foundation for thinking honestly about what comes next.

What has changed:

Transaction monitoring has moved from purely rules-based to hybrid AI-assisted systems. The leading AML platforms now incorporate machine learning models for anomaly detection, network analysis for identifying structuring and layering, and natural language processing for customer due diligence document processing. These are not marginal improvements. Institutions using well-implemented AI-assisted monitoring have achieved meaningful reductions in false positive rates — typically 20–40% — while maintaining or improving detection rates for suspicious activity.

Regulatory reporting has become substantially more automated. The manual extraction, transformation, and loading of regulatory data that characterized reporting at most institutions in 2015 has been replaced, at leading institutions, by purpose-built data pipelines with automated validation, exception reporting, and submission workflows. XBRL-based reporting has become standard across major regulatory frameworks. The remaining manual work tends to cluster at the edges: complex judgment calls, exceptions, and narrative explanations.

KYC processes have been transformed by digital identity verification. Biometric verification, document authentication, and liveness detection have compressed onboarding processes that once took days into processes that take minutes, while improving accuracy. The average cost of digital KYC verification has fallen dramatically since 2018.

Regulatory intelligence has accelerated. Natural language processing tools that monitor regulatory publications, extract key obligations, and summarize changes have reduced the manual burden of horizon scanning significantly. Compliance teams that once needed a dedicated analyst to track regulatory developments can now use technology to do the initial pass, reserving human attention for interpretation and impact assessment.

What has not changed:

The pace of change in compliance technology should not obscure what has remained stubbornly constant. Regulatory judgment — the human interpretation of ambiguous regulatory language, the risk-based decision about what a rule means in a specific context, the professional assessment of whether a customer's explanation for an unusual transaction is credible — remains irreducibly human. The compliance professional's core function is not to process information; it is to exercise judgment. Technology has improved the quality and quantity of information available for that judgment. It has not replaced the judgment itself.

Regulatory relationships have also remained human. The relationship between a compliance function and its regulator — the dynamic of trust, credibility, and communication that determines how the regulator interprets a firm's culture and responsiveness — cannot be automated. The firms that have the best regulatory relationships in 2025 are the ones where senior compliance professionals invest time and credibility in those relationships, not the ones with the most sophisticated technology.

And the compliance talent shortage has persisted and, in some respects, deepened. The demand for compliance professionals who combine regulatory knowledge with technology fluency has grown faster than the supply of such people. This is not a temporary imbalance. It reflects the structural difficulty of developing expertise in both domains simultaneously.

The Gap Between Aspiration and Reality

The RegTech market has matured enough to allow a more honest assessment of where AI and machine learning in compliance have delivered and where they have fallen short of early promises.

The aspiration, circa 2018–2020, was something close to autonomous compliance: AI systems that could read regulations, understand what they required, monitor firm behavior against those requirements, and flag issues without human intervention. That vision has not arrived and is not arriving soon. The gap between what large language models and machine learning systems can do in laboratory conditions and what they can reliably do in production compliance environments — with all the ambiguity, edge cases, jurisdictional variation, and accountability requirements of real regulatory practice — remains substantial.

What has arrived is something more modest and, in practice, more useful: technology that reliably improves specific, well-defined compliance processes. AI-assisted transaction monitoring is better than purely rules-based monitoring for detecting certain patterns of suspicious activity. Automated document processing is faster and more consistent than manual document review for standard KYC documents. NLP-based horizon scanning is more comprehensive than manual monitoring of regulatory publications.

The institutions that have benefited most from RegTech are not the ones that pursued the most ambitious transformations. They are the ones that identified specific pain points, deployed targeted technology solutions, and maintained rigorous governance of those solutions. The institutions that have struggled are the ones that purchased platforms expecting them to solve systemic compliance problems that the platforms were not designed to address.

Market Consolidation: The Vendor Landscape Matures

The RegTech vendor market has undergone significant consolidation since the peak of the initial investment wave around 2017–2019. The pattern has been typical of technology market maturation: many entrants, followed by a shake-out in which the firms with the strongest products and the most sustainable business models survive, while others are acquired, pivot, or fail.

Several dynamics characterize the current vendor landscape:

Acquisition by incumbents. Financial technology incumbents — banking software firms, risk management platform companies, major data vendors — have acquired specialist RegTech firms, absorbing their capabilities into broader platforms. This has benefits for buyers (integrated platforms, more stable vendors) and costs (loss of the agility and innovation that characterized the standalone firms).

Platform consolidation. Institutions have moved from assembling many point solutions toward working with fewer, more comprehensive platforms. The era of buying fifteen different RegTech tools for fifteen different compliance functions is giving way to a preference for integrated platforms that cover multiple use cases, even if they do not individually match the depth of the best point solutions.

Surviving specialist leaders. In some domains — particularly AML, sanctions screening, and trade surveillance — established specialist vendors have survived and in some cases grown, because the depth and regulatory pedigree of their solutions create meaningful switching barriers.

Regulatory scrutiny of vendor concentration. Paradoxically, as institutions consolidate onto fewer vendors, regulators have become more attentive to the systemic risks of that concentration. DORA in Europe and the FCA's critical third-party (CTP) regime in the UK impose significant new obligations on both institutions and their critical technology vendors.

Regulators Are Becoming More Technically Sophisticated

One of the most significant structural changes of the past decade is the growing technical sophistication of financial regulators. This matters because the regulatory environment that RegTech must navigate is shaped by what regulators understand and what they can observe.

The FCA's Project Innovate, launched in 2014, was an early acknowledgment that regulators needed to understand the technologies they were regulating. A decade later, the FCA has a dedicated data science team, has published multiple papers on its use of machine learning for supervisory purposes, and has run structured pilots of supervisory technology including direct data access programs.

The US SEC has developed significant analytical capabilities through its Office of Analytics and Data. The SEC's use of EDGAR analytics to identify potential accounting fraud and market manipulation has become more sophisticated with each generation of analytical tools deployed.

The Bank for International Settlements, through its Innovation Hub, has coordinated supervisory technology development across central banks globally. The BIS SupTech inventory, published periodically, documents active SupTech programs across more than fifty jurisdictions — a breadth that would have seemed implausible a decade ago.

What this means is that the compliance function is no longer operating in an environment where the regulator sees only what the firm reports. The regulator's own analytical capabilities are growing. This is the context for understanding the most important near-term structural development in RegTech: supervisory technology.

Section 2: Supervisory Technology (SupTech)

What SupTech Is — and Why It Matters

Supervisory technology, or SupTech, refers to technology used by regulators and supervisors to enhance their own supervisory functions. It is the counterpart to RegTech: where RegTech is technology that regulated firms use to meet regulatory requirements, SupTech is technology that regulators use to oversee those firms.

This distinction is more than semantic. SupTech represents a fundamental shift in the nature of the supervisory relationship — one that has profound implications for how compliance functions operate and what they must be prepared for.

For most of the history of financial regulation, the regulator's visibility into a firm's behavior was limited to what the firm reported, supplemented by periodic examination and inspection. Firms prepared regulatory returns, submitted them on defined schedules, and operated with considerable latitude between reporting periods. The regulator's view of the firm was retrospective, periodic, and mediated through the firm's own data preparation processes.

SupTech changes this in two ways. First, it gives regulators the analytical tools to extract more signal from the data they already receive — identifying patterns, anomalies, and potential issues that manual review would miss. Second, and more significantly, it creates the architecture for regulators to access data directly and in near-real time, replacing the periodic reporting cycle with continuous supervisory visibility.

Current SupTech Deployments

SupTech is not a future aspiration. It is already operational across a significant and growing set of regulatory contexts.

FCA Project Innovate and the FCA's Data Capabilities

The Financial Conduct Authority has been among the most active regulators in developing supervisory technology. Beyond Project Innovate, the FCA has developed significant internal data analytics capabilities, including machine learning models used to identify firms and individuals exhibiting patterns associated with misconduct. The FCA's use of network analysis to identify connections between individuals, firms, and complaints has resulted in enforcement actions that would not have been feasible through manual review.

The FCA's Digital Regulatory Reporting (DRR) initiative represents perhaps the most consequential SupTech development in the UK. Launched as a joint initiative with the Bank of England, the DRR project has explored whether regulatory reporting requirements can be expressed in machine-readable form, enabling automated data collection directly from firms' systems rather than through manual report preparation.

BIS Innovation Hub

The Bank for International Settlements operates the Innovation Hub, which coordinates SupTech development across a network of central banks including the Monetary Authority of Singapore, the Swiss National Bank, the Eurosystem, and the Hong Kong Monetary Authority. The Hub has produced proof-of-concept implementations for supervisory analytics, regulatory reporting via API, and automated supervisory data collection.

The BIS's published SupTech inventory documents more than 90 active SupTech tools deployed by central banks and financial supervisors globally as of 2023. These range from relatively simple analytical dashboards to sophisticated machine learning systems for systemic risk monitoring and individual firm supervision.

ECB Supervisory Technology: AnaCredit and BIRD

The European Central Bank has deployed two significant SupTech programs. AnaCredit (Analytical Credit Datasets) collects granular loan-level data from European banks, enabling the ECB to analyse credit risk across the eurozone banking system with a level of detail that was previously impossible. The Banks' Integrated Reporting Dictionary (BIRD) is an even more ambitious initiative: a standardized data dictionary and reporting framework designed to reduce the reporting burden on banks by enabling them to report data once in a standardized form and have it automatically translated into the multiple different reporting formats required by different supervisors.

SEC EDGAR Analytics

The US Securities and Exchange Commission's EDGAR system, originally a document repository, has evolved into an analytical platform. The SEC uses text analysis of EDGAR filings to identify potential accounting irregularities, unusual risk factor language, and anomalies in financial disclosures that may warrant further investigation. The Commission has published research papers documenting how machine learning applied to EDGAR data can identify signals predictive of accounting restatements.

Direct Reporting Pipelines: The API Future

The most structurally significant SupTech development is the movement toward API-based direct regulatory data access — replacing the periodic reporting cycle with continuous or near-real-time data feeds.

Under the traditional regulatory reporting model, a firm prepares and submits regulatory returns on a defined schedule. The FCA's GABRIEL reporting system, for example, receives periodic submissions from UK-regulated firms. Between submissions, the regulator's view of the firm is limited to what was last reported, supplemented by any supervisory contact.

Under the API-based model, regulators have direct access to defined subsets of a firm's data through secure API connections. Rather than the firm preparing a report and submitting it, the regulator queries the firm's systems directly, receiving current data in standardized form. This eliminates the preparation process entirely for the queried data categories and gives the regulator a continuously current view.

The FCA's DRR initiative has piloted this model with a small group of volunteer firms. The MAS in Singapore has piloted API-based supervisory data access. The ECB's AnaCredit collection already uses API-based data submission for many institutions.

This development has implications that extend well beyond efficiency. When regulators can access data directly and continuously:

• The compliance value of periodic report preparation diminishes. The effort that goes into preparing the regulatory return — cleaning data, resolving inconsistencies, checking figures — is largely eliminated.
• The data quality problem moves upstream. If data flows to the regulator as it is created, rather than after preparation, the quality of that data is what the regulator sees. There is no opportunity to catch and correct errors before submission.
• Continuous supervisory visibility changes the nature of compliance. Firms can no longer treat compliance as a periodic reporting exercise. The regulatory view is always current.
• The gap between what the firm reports and what the firm's data actually shows becomes immediately visible to the regulator.

This last point is perhaps the most significant. The SupTech future is one in which the informational asymmetry that has characterized financial regulation — the regulator seeing only what the firm chooses to present — is substantially reduced.

What SupTech Means for Compliance Programs

The practical implications of SupTech for compliance function design are profound:

Data architecture becomes a regulatory compliance matter. If regulators are going to access your data directly, the quality, consistency, and accessibility of that data is no longer just an operational concern. It is a regulatory risk. Firms with fragmented, inconsistent, or poorly governed data architectures face material regulatory exposure as SupTech matures.

The reporting cycle gives way to continuous compliance. Compliance cannot be a function that operates in peaks around reporting deadlines. The data must be right, all the time, because the regulator may be looking at it at any time.

Internal control environment visibility increases. When regulators have direct data access, patterns that might previously have been smoothed over in report preparation are visible. Firms need to ensure their internal controls are actually working, not just that their reports suggest they are.

The regulatory relationship changes. Direct data access does not eliminate supervisory judgment or relationship. But it changes the dynamic: the regulator is less dependent on the firm's self-representation, which both reduces the value of managing the relationship for its own sake and increases the importance of having genuinely sound compliance practices.

Privacy and Governance Implications of SupTech

Direct supervisory data access raises significant questions that regulators and industry have not yet fully resolved.

Customer data protection. If regulators can query a firm's transaction records directly via API, they potentially have access to individual customer transaction data. The legal basis for this access, the data protection safeguards that apply, and the limits on how regulators can use customer data obtained through SupTech access are questions that data protection frameworks — particularly GDPR in the EU and the UK's equivalent — are only beginning to address.

The scope of access question. What data categories can the regulator access? A targeted API access regime — allowing the regulator to query specific defined data fields — is very different from broad access to a firm's entire data environment. The governance frameworks that define the scope of SupTech access are critical.

Data use limitations. Data accessed for supervisory purposes should be used only for those purposes. The governance frameworks for SupTech need to address how supervisory data is stored, who can access it within the regulatory agency, how long it is retained, and how it can be used.

Reciprocal obligations. As SupTech expands regulatory visibility, it arguably also creates new obligations on regulators to use that visibility responsibly and to protect the firms they supervise from inappropriate disclosure of commercially sensitive information.

These questions are not resolved. They are governance challenges that will accompany the technical deployment of SupTech, and compliance professionals who engage with them now — through industry association participation, consultation responses, and internal governance planning — will be better positioned than those who encounter them unprepared.

Section 3: Digital Regulation — Machine-Executable Rules

The Concept

The most ambitious near-future development in RegTech is digital regulation: the expression of regulatory requirements in machine-readable, executable form. The concept is straightforward to state and genuinely difficult to implement: rather than regulations being written in natural language and then interpreted by humans to determine what they require in specific circumstances, regulatory requirements would be expressed in formal languages that machines can read and execute.

The promise is extraordinary. If regulations are machine-executable, compliance automation becomes nearly complete for the covered requirements. A firm could configure its systems to automatically test whether its behavior complies with the machine-executable rules, flag exceptions, and adjust processes to achieve compliance — all without the human interpretation step that currently mediates between regulatory text and operational behavior.

Current Examples and Initiatives

FCA Digital Regulatory Reporting (DRR)

The FCA's Digital Regulatory Reporting initiative is the most developed example of machine-readable regulation in active development. Launched as a joint project with the Bank of England, the DRR initiative has worked with a group of volunteer firms to explore whether reporting requirements can be expressed in computer code — specifically, whether the rules that define what data needs to be reported, in what format, and at what frequency can be expressed in a formal language that both the firm's systems and the regulator's systems can read.

The Phase 1 pilot demonstrated that specific, well-defined reporting rules could be expressed in machine-readable form and used by firms to automate their reporting processes. The Phase 2 work has explored broader application and the governance challenges of maintaining machine-executable rule libraries.

Monetary Authority of Singapore — FEAT

The MAS's Fairness, Ethics, Accountability and Transparency (FEAT) framework, while not machine-executable in itself, represents a move toward principles that can be translated into verifiable computational requirements. The MAS has also been active in exploring API-based regulatory data collection, which is the SupTech complement to machine-readable regulation.

GLEIF and Legal Entity Identifiers

The Global Legal Entity Identifier Foundation (GLEIF) and the Legal Entity Identifier (LEI) system represent a foundational piece of digital regulatory infrastructure: a globally standardized, machine-readable identifier for legal entities that participate in financial transactions. The LEI is used in regulatory reporting across MiFID II, EMIR, and a growing range of other regulatory frameworks. It is an example of what digital regulatory infrastructure looks like in practice: a standardized, machine-readable reference data layer that makes downstream compliance automation possible.

XBRL Taxonomy Development

The XBRL (eXtensible Business Reporting Language) ecosystem, which underpins structured regulatory reporting across the EU and increasingly globally, represents a form of machine-readable regulatory schema. While XBRL taxonomies define reporting formats rather than substantive regulatory rules, they illustrate the principle of expressing regulatory structure in machine-processable form.

The Challenge: Law Is Not Code

The promise of machine-executable regulation runs into a fundamental problem: regulatory language is deliberately, often necessarily, ambiguous. Laws and regulations are not engineering specifications. They are expressions of policy intent in language that is designed to be interpreted by humans exercising judgment, adapted to circumstances that the drafters could not precisely anticipate.

Consider a provision from MiFID II Article 27: the obligation on investment firms to take "all sufficient steps" to obtain the "best possible result" for clients when executing orders. What does "best possible result" mean? It depends on the instruments being traded, the markets available, the client's instructions, the time of day, the size of the order, and a range of other factors that require human judgment to weigh. A machine-executable rule for best execution would need to either fix all of these parameters (eliminating the judgment that makes the rule robust to different circumstances) or build in decision trees of such complexity that they effectively reproduce human judgment in algorithmic form (creating maintenance and governance challenges of their own).

The regulatory interpretation problem runs even deeper. Regulatory requirements do not exist in isolation. They are interpreted by regulators through guidance, supervisory letters, speeches, and enforcement actions. They are shaped by judicial decisions and regulatory tribunal rulings. The meaning of a regulatory requirement at any given time reflects this accumulating interpretive record, which is itself not static. Machine-executable rules would need to be continuously updated to reflect this evolving interpretation — and someone would need to decide how the machine-executable rule should be updated when the regulatory interpretation changes.

The "who decides" problem is the central governance challenge of machine-readable regulation. When a regulation is expressed in natural language, ambiguity is a feature as much as a bug: it gives compliance professionals and regulators the flexibility to apply the rule sensibly to situations that the drafters could not anticipate. When a regulation is expressed as executable code, that ambiguity must be resolved by the person writing the code — and the compliance of a firm's behavior will depend on whether the coder's interpretation matches the regulator's. If it does not, the firm has automated its non-compliance.

Near-Term Reality vs. Longer-Term Vision

A realistic assessment of digital regulation distinguishes between what is already happening and what remains aspirational.

Currently happening: Machine-readable reporting schemas (XBRL); standardized reference data (LEI); API-based data submission; pilot programs for machine-readable reporting rules (FCA DRR Phase 1). These are substantial achievements. They have meaningfully reduced the cost and error rate of regulatory reporting for participating firms.

Emerging (2–5 year horizon): Broader deployment of API-based regulatory reporting replacing form-based submission; expanded machine-readable rule libraries for well-defined reporting requirements; SupTech platforms capable of querying firm data directly; semantic regulatory ontologies that enable more sophisticated automated interpretation.

Longer-term vision (10+ years, speculative): Comprehensive machine-executable substantive regulatory requirements, not just reporting schemas; automated compliance testing against executable regulatory code; regulatory rule libraries that update automatically as regulations change. This vision depends on resolving the interpretation problem described above and requires substantial changes to how regulations are drafted — not just how they are expressed.

Implications for compliance professionals: Even in a future where the execution of compliance requirements becomes highly automated, the interpretive function remains human. Someone must decide what the machine-executable rule should say. Someone must review the rule when regulations change and determine how the executable version should be updated. Someone must govern the exceptions and edge cases that the rule does not handle correctly. The compliance professional's role shifts from executing compliance processes to governing the systems that execute them — a shift that requires more technical fluency, not less human judgment.

Section 4: Large Language Models in RegTech

Where LLMs Are Actually Being Deployed

Large language models have entered the compliance workflow in meaningful ways since 2022. The honest picture of where they are delivering value and where they are falling short of promise is important for any compliance professional assessing how to deploy these tools.

Regulatory horizon scanning and summarization. This is the clearest current use case. LLMs can process large volumes of regulatory publications — consultation papers, policy statements, technical standards, guidance updates — and produce summaries that highlight the key changes and their potential implications. For compliance teams spending significant hours weekly on manual monitoring of regulatory outputs across multiple regulators and jurisdictions, this represents a genuine efficiency gain. The important caveat is that LLM-produced summaries require expert human review before acting on them.

Policy gap analysis. LLMs can be prompted to compare a firm's existing policy documentation against a described regulatory requirement and identify areas where the policy may not fully address the requirement. This is useful as a first-pass triage tool, identifying areas for human expert review rather than producing authoritative conclusions.

Training content generation. LLMs can draft initial versions of compliance training materials — scenarios, case studies, explanations of regulatory concepts — that human experts then review and refine. The speed advantage is real; the need for expert review remains.

Contract review and summarization. For large volumes of standard commercial contracts, LLMs can extract key terms, flag non-standard provisions, and summarize obligations. The limitations around complex or non-standard provisions require expert escalation.

SAR narrative drafting assistance. Some AML compliance teams are piloting LLM assistance for drafting Suspicious Activity Report narratives — using the model to produce a structured first draft from case notes that a human analyst then reviews, edits, and finalizes. The potential efficiency gain here is significant given the volume of SAR production at large institutions.

Where LLMs Are Not Ready

The areas where LLMs are not appropriate for compliance use require equal clarity:

Making compliance decisions. A large language model cannot reliably decide whether a transaction requires a SAR, whether a customer poses acceptable risk, or whether a trading pattern constitutes market manipulation. These are judgment calls that require contextual knowledge, regulatory expertise, accountability, and defensibility — none of which an LLM can provide.

Generating reliable regulatory advice without verification. LLMs produce plausible-sounding text. In regulatory contexts, plausible-sounding is a dangerous standard. A model that describes a regulatory requirement incorrectly, but confidently and fluently, creates exactly the kind of compliance risk that LLMs are supposed to help manage.

Replacing expert judgment in novel situations. LLMs are trained on existing text. They cannot reliably reason about genuinely novel regulatory situations, emerging requirements, or interpretive questions that turn on specific regulatory guidance that may not be well-represented in training data.

The Hallucination Risk in Compliance Contexts

The phenomenon of LLM "hallucination" — generating text that is confident, fluent, and factually wrong — is particularly dangerous in regulatory compliance contexts.

In most text generation contexts, a hallucination is an embarrassment or an error to be corrected. In a compliance context, a hallucination about a regulatory requirement can result in a firm believing it is compliant when it is not, preparing a regulatory submission that is incorrect, or providing advice to a client that is wrong. The consequences extend beyond the error itself: regulatory failures resulting from reliance on AI-generated misinformation are unlikely to attract regulatory sympathy.

The specific risk pattern in compliance is this: an analyst uses an LLM to research a regulatory requirement. The model produces a confident, well-structured summary that cites regulatory instruments and appears authoritative. The analyst, under time pressure, acts on the summary without checking it against the original source. The summary is wrong in a material respect. The resulting compliance failure is not discovered until a regulatory examination.

This risk is not hypothetical. It has already materialized in legal contexts, where courts have imposed sanctions on attorneys who cited LLM-generated case citations that did not exist. In compliance contexts, where the stakes are regulatory rather than judicial, the pattern is no less dangerous.

How to Use LLMs Safely in Compliance

The answer to hallucination risk is not to avoid LLMs in compliance. It is to deploy them in roles where their outputs are always subject to expert human verification before they influence compliance decisions or regulatory submissions.

The practical framework has two components:

Role definition: LLMs are research accelerators and drafting assistants, not decision-makers or validators. A model can help an analyst find relevant regulatory text faster. It can draft a first version of a policy document that an expert then reviews. It cannot certify that a regulatory requirement has been correctly interpreted or a compliance obligation satisfied.

Verification requirements: Any LLM output that will influence a compliance decision, a regulatory submission, or advice to a business line must be verified against primary sources by a human expert before it is acted upon. This is not optional and should be embedded in the workflow design, not left to individual discretion.

The efficiency gains from LLM use in compliance are real even with verification requirements. The model doing the initial pass still saves time, even if a human must verify the output. The gain comes from the acceleration of the first-pass work, not from eliminating the expert review step.

Model Governance for LLM-Assisted Compliance

The deployment of LLMs in compliance workflows raises a question that many institutions have not yet fully addressed: do LLM-assisted compliance decisions fall within the scope of existing model governance frameworks?

In the US, the Federal Reserve's SR 11-7 guidance on model risk management defines a model as "a quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories, techniques, and assumptions to process input data into quantitative estimates." Whether an LLM assisting with compliance tasks meets this definition is a question regulators are actively considering.

In the EU, the AI Act classifies AI systems used for "evaluation and classification of natural persons based on their social behaviour or predicted personal or professional behaviour" and certain credit and financial risk assessments as high-risk — with corresponding governance obligations. The application of the AI Act to LLMs used in compliance contexts depends on the specific use case, but several compliance applications are plausible high-risk candidates.

The prudent approach is to apply the same model risk management discipline to material LLM deployments in compliance that would apply to quantitative risk models: documentation of model purpose, limitations, and assumptions; validation of model performance; ongoing monitoring; change management procedures; and escalation protocols for situations where the model's outputs should not be relied upon. This is not simply regulatory overhead — it is the governance infrastructure that makes LLM deployment defensible.

Section 5: Emerging Trends in Financial Market Structure

DeFi Compliance Challenges

Decentralized finance — financial services built on blockchain protocols without central intermediaries — represents perhaps the most fundamental challenge to the existing regulatory framework for financial markets. The challenge is not primarily technical. It is jurisdictional and institutional.

Traditional financial regulation is built around the supervision of identifiable legal entities — banks, broker-dealers, fund managers — that hold licenses, maintain records, employ compliance staff, and can be held accountable for regulatory failures. DeFi protocols replace these intermediaries with smart contracts: self-executing code that enforces transaction rules automatically, without a controlling legal entity that can be regulated.

Automated market makers — the DeFi mechanism that replaces traditional market makers and order books with algorithmic liquidity pools — cannot be sent a subpoena. The code governing a decentralized exchange does not have a compliance officer. The anonymous pseudonymous participants in DeFi transactions may not be identifiable for AML purposes.

Regulators have responded with a combination of approaches: applying existing regulatory requirements to identifiable points of access to DeFi systems (the fiat on-ramps, wallet providers, and front-end interfaces that interact with otherwise decentralized protocols); exploring whether decentralized governance token holders or developers can be treated as controlling parties for regulatory purposes; and working toward international coordination on DeFi regulation.

For the compliance professional at a regulated institution, the DeFi compliance challenge manifests primarily in customer due diligence: the need to understand whether customers are using DeFi protocols to move or obscure funds, and whether transactions that interact with decentralized protocols require enhanced due diligence or SAR consideration. The FATF's updated guidance on virtual assets addresses these questions.

CBDC Compliance Implications

Central bank digital currencies — digital forms of central bank money, distinct from commercial bank deposits or private cryptocurrencies — are in various stages of development at central banks globally. The People's Bank of China has deployed its digital renminbi at significant scale. The ECB's digital euro project is in preparation phase. The Federal Reserve has conducted research on a potential digital dollar.

The compliance implications of CBDCs are significant and largely unexplored in practice, because no major CBDC is yet in full deployment in a large economy.

The most discussed implication is the programmability of CBDC. Unlike physical cash, a CBDC can in principle carry embedded rules: restrictions on what it can be used for, expiry conditions, reporting triggers that automatically notify the central bank of defined transaction types. This programmability represents the most radical form of compliance-by-design — regulatory requirements embedded in the currency itself, requiring no reporting because the behavior is controlled at the transaction level.

The compliance-by-design possibility is also a surveillance risk. A CBDC with extensive programmability and transaction monitoring represents a level of financial surveillance by the state that raises profound privacy and civil liberties questions. These are not purely technical questions. They are political and constitutional questions that will shape how CBDCs are ultimately designed and deployed.

For regulated financial institutions, the CBDC deployment scenario creates compliance questions about the interaction between CBDC systems and existing AML and sanctions screening obligations. If a customer holds both commercial bank deposits and CBDC, and moves value between them, how does the institution's transaction monitoring treat those movements? The answers depend on regulatory guidance that does not yet exist in most jurisdictions.

Embedded Finance Compliance

Embedded finance — the integration of financial services into non-financial platforms and products — has grown significantly over the past five years. Banking-as-a-service platforms enable brands and technology companies to offer financial products under their own brand without holding banking licenses. Buy-now-pay-later products offered at point of sale by retailers involve credit products delivered through non-financial platforms. Payment services embedded in social media platforms handle significant transaction volumes.

The compliance question that embedded finance raises is deceptively simple: who is regulated? When a fintech company offers a financial product through a bank's license via a banking-as-a-service arrangement, the bank is the regulated entity — but the fintech controls the customer relationship, the product design, and the user experience. The distribution of compliance responsibility between the licence-holder and the distributor is a question that regulators are actively working through.

In the UK, the FCA has been explicit that regulated firms cannot outsource their regulatory obligations by embedding financial products in third-party platforms. The firm holding the authorisation is responsible for the compliance of the products sold under its authorisation, regardless of through which channel they are sold. This creates significant compliance oversight obligations for banks operating banking-as-a-service models.

In the EU, the Payment Services Directive 2 (PSD2) and the forthcoming PSD3 address payment services embedded in non-payment platforms. The scope of authorisation requirements for embedded payment services is an active area of regulatory development.

ESG Data and Climate Risk as a Compliance Frontier

Environmental, Social, and Governance (ESG) reporting and climate risk disclosure have emerged as significant new compliance obligations in the past five years, and the trajectory is toward more, not less.

In the EU, the Corporate Sustainability Reporting Directive (CSRD) and the Taxonomy Regulation create extensive disclosure obligations for large companies and financial institutions. The European Sustainability Reporting Standards (ESRS) specify the granular data requirements that firms must gather and report. For financial institutions, the EU Taxonomy Regulation requires disclosure of the proportion of activities that are "sustainable" under defined criteria — creating new data collection, verification, and reporting obligations.

In the US, the SEC's climate disclosure rules — after extended legal challenge — are moving toward requiring public companies to disclose material climate-related risks and, for larger companies, Scope 1 and Scope 2 greenhouse gas emissions.

The compliance challenge in ESG is primarily a data challenge. The financial data infrastructure that underlies existing regulatory reporting is relatively mature. The ESG data infrastructure is not. Firms are grappling with how to collect reliable data on financed emissions, counterparty ESG characteristics, supply chain environmental impacts, and a range of other metrics for which standardized data sources do not yet exist at scale.

RegTech has an important role to play in ESG compliance — providing data aggregation tools, automating the translation of raw ESG data into reporting formats, and enabling ongoing monitoring of portfolio exposure to climate risk. This is an area where RegTech capability is still being built, and where the compliance professional who develops ESG data expertise now is early in a long growth curve.

Section 6: The Regulatory Horizon

Regulation Is Catching Up with Technology

A recurring theme in technology and regulation is the "pacing problem": technology moves faster than regulation, creating periods of reduced oversight during which innovation flourishes (and risks accumulate). Eventually, regulation catches up, often through a crisis that makes the risks visible.

The current period is one in which regulation is catching up meaningfully. The EU AI Act, which entered into force in 2024 and applies progressively through 2026–2027, is the world's first comprehensive legal framework for artificial intelligence. It is not the last such framework. The UK has announced its intention to develop AI governance frameworks adapted to its policy priorities. The US has issued executive orders and regulatory guidance on AI risk management. The OECD and G7 have adopted AI principles. The momentum toward AI regulation globally is real and unlikely to reverse.

The implications for RegTech specifically are significant. If the AI systems used in compliance functions fall within the scope of the EU AI Act's high-risk provisions — and some do — they must meet requirements for transparency, human oversight, accuracy, robustness, and documentation that go substantially beyond current industry practice in many firms. The EU AI Act is not simply an ethical standard; it is a compliance obligation that compliance professionals need to understand and address.

Beyond AI, the digital financial infrastructure is attracting increasing regulatory attention. Crypto-asset markets regulation (MiCA in the EU), operational resilience (DORA in the EU, the FCA's operational resilience framework in the UK), critical third-party oversight, and CBDC governance frameworks are all active areas of regulatory development that will create new compliance obligations over the next three to five years.

Anti-Fragility as a Compliance Strategy

The regulatory horizon described above presents a challenge for compliance program planning: how do you build a compliance program in an environment of continuous, significant regulatory change?

The concept of anti-fragility — developed by Nassim Nicholas Taleb in risk theory and applicable to organizational design — is useful here. An anti-fragile compliance program is one that gets stronger, rather than weaker, under stress. It is designed not to cope with a fixed regulatory environment but to adapt to changing requirements without catastrophic disruption.

The structural characteristics of an anti-fragile compliance program include:

Modular architecture. Compliance systems and processes designed as modular components can be updated when specific requirements change without requiring the entire program to be rebuilt.

Data infrastructure investment. The compliance program's biggest vulnerability to regulatory change is usually data — the inability to produce data in the format and at the frequency that new regulations require. Institutions with well-governed, accessible, standardized data can adapt to new reporting requirements substantially faster than those without.

Early regulatory engagement. Compliance professionals who participate in regulatory consultations, industry working groups, and regulatory sandbox programs have more advance notice of regulatory change and more influence over its form than those who wait for regulations to be finalised.

Vendor diversification with standardized interfaces. Dependence on a single vendor for critical compliance functions is a fragility risk. Maintaining standardized data interfaces and governance protocols that are vendor-agnostic reduces the switching cost when vendor technology cannot keep pace with regulatory requirements.

Continuous learning culture. Anti-fragile compliance teams develop their own regulatory expertise rather than relying entirely on vendor or external advisory support. In-house expertise enables faster assessment of regulatory change and more effective direction of vendor and advisory relationships.

Compliance-by-Design

The traditional model of compliance is additive: businesses design products and processes, and compliance reviews them to identify regulatory concerns that need to be addressed after the fact. This model is increasingly inadequate in a regulatory environment where products contain embedded financial services, where digital customer journeys must satisfy regulatory requirements as well as user experience objectives, and where the cost of retrofitting compliance into non-compliant products can be prohibitive.

Compliance-by-design is the alternative: embedding compliance considerations into product and process design from the outset, making regulatory requirements part of the product specification rather than a constraint applied after the specification is written.

The technology conditions for compliance-by-design are improving. Machine-readable regulatory requirements, when available, can be directly translated into product design specifications. Automated testing environments can verify compliance of a product design before deployment. Regulatory sandboxes allow firms to test new product designs with regulatory engagement before full authorization.

The organizational challenge of compliance-by-design is greater than the technology challenge. It requires that compliance professionals be involved in product development from the earliest stages — before commercial decisions have been made that constrain the compliance options. This requires a compliance function that is seen by the business as a design partner rather than a reviewer or gatekeeper, and a business culture that genuinely values regulatory credibility rather than treating compliance as a cost of doing business.

Regulatory Collaboration and Industry Shaping

Compliance professionals who participate in regulatory consultation processes and industry working groups are not merely fulfilling a civic obligation. They are engaging in a direct form of regulatory influence that shapes the environment their institutions will need to comply with.

Regulatory consultations — particularly in the UK and EU — are not formalities. Regulators read the responses. Evidence-based, technically informed responses from industry participants influence regulatory design decisions. Compliance professionals who engage with consultations on SupTech data access, machine-readable regulation, AI governance, and CBDC frameworks have an opportunity to shape these frameworks in ways that reflect the operational realities of regulated institutions.

Industry associations — the Association for Financial Markets in Europe (AFME), the International Swaps and Derivatives Association (ISDA), the Risk Management Association (RMA), UK Finance, and similar bodies — coordinate industry responses to regulatory consultations and provide a forum for compliance professionals to develop shared positions on complex regulatory questions. Engagement with these bodies is an investment that compounds: the relationships and shared knowledge developed in industry working groups pay dividends when new regulations create implementation challenges.

Section 7: What This Means for Compliance Professionals

The Skills That Remain Valuable

The future of compliance technology is uncertain in its specifics. The skills that will remain valuable to compliance professionals regardless of how the technology develops are much clearer.

Regulatory judgment. The ability to read regulatory language and understand what it means in context — not just what it says — is a skill that becomes more valuable as compliance automation expands, not less. Automated systems handle routine determinations. The hard cases, the novel situations, the edge cases that the algorithm was not designed for, all require human judgment. As automation handles more of the routine, the compliance professional's portfolio shifts toward the more complex and more consequential. Regulatory judgment is the core of that portfolio.

Communication and translation. The compliance professional's most important communication skill is the ability to translate between regulatory and business language — to explain what a regulatory requirement means for a business decision in terms that are accurate but accessible, and to explain what a business practice implies for regulatory risk in terms that are specific enough to be actionable. This skill cannot be automated because it requires understanding both domains and bridging between them.

Ethical reasoning. Compliance is not only a legal function. It is an ethical one. The ability to reason about what behavior is right — not just what is required — becomes more important, not less, as automation handles the mechanical aspects of compliance. Automated systems do what they are programmed to do. Ethical judgment is what determines what they should be programmed to do.

Regulatory relationship management. The relationship between a regulated institution and its regulators is a professional relationship built on credibility, trust, and sustained engagement. It cannot be outsourced to technology. The compliance professional who invests in regulatory relationships — who knows the supervisors, who engages in consultations, who builds a reputation for honesty and competence with the regulators — is creating an institutional asset that no software can replicate.

The Skills That Need to Develop

The compliance professional of 2030 will need capabilities that were not required in 2015 and that many current compliance professionals have not systematically developed.

Data literacy. The ability to understand data structures, data quality issues, data lineage, and the basic concepts of data governance is no longer optional for compliance professionals who need to work with RegTech systems. This is not the same as being a data engineer or a data scientist. It is the ability to have an informed conversation about data, to evaluate data quality claims, to understand what a data architecture can and cannot produce, and to specify data requirements for compliance systems.

Technology architecture understanding. Compliance professionals do not need to be software engineers. But they do need to understand, at a conceptual level, how compliance technology systems are built and how they interact. What does an API do? What is the difference between a cloud-hosted system and an on-premises one, and why does it matter for regulatory purposes? How does a machine learning model produce its output, and what does that imply for explainability and validation? These are not esoteric questions. They are questions that a compliance professional needs to be able to engage with when evaluating vendor systems, governing technology deployments, and explaining technology use to regulators.

AI governance. The use of artificial intelligence in compliance creates governance obligations that are specific to AI: model validation, ongoing performance monitoring, explainability requirements, human oversight protocols, and documentation requirements. The compliance professional who understands AI governance — not at the level of the data scientist, but at the level of the governance practitioner — is equipped to manage the compliance program's most significant technology risk.

Vendor management sophistication. As compliance functions become more technology-dependent, the ability to evaluate, negotiate with, and oversee technology vendors becomes a core compliance competency. This includes technical due diligence, contract negotiation with an understanding of the regulatory requirements that contracts must satisfy, implementation oversight, and ongoing performance governance.

The Career Trajectory

The careers that will be most valuable in compliance over the next decade are those that bridge the technology-regulation gap. The most valuable compliance professional is not the one who understands algorithms best among compliance professionals. It is the one who can govern technology deployments with regulatory expertise — who can specify what a compliance system needs to do, evaluate whether it does it, explain its operation to regulators, and take responsibility for its outcomes.

This is a broader role than traditional compliance and a different one. It is not the compliance professional who happens to know some Python, nor the data scientist who has read the AML regulations. It is someone who has developed genuine competence in both domains — not necessarily to the depth of specialists in either, but to the depth of an effective translator and integrator.

The career path toward this role involves deliberate investment: taking on RegTech implementation projects rather than avoiding them; working closely with technology teams; developing regulatory expertise specifically in the technology-intensive domains (AI governance, SupTech, digital regulatory reporting); engaging with regulatory consultations on technology topics; and building relationships with both regulators and technologists.

The Most Dangerous Posture

The most dangerous posture for a compliance professional in 2025 is to assume that the skills and approaches that produced a successful compliance career in 2015 are sufficient for 2030. This is not a gentle observation. It is a candid one, offered in the spirit of the same honest uncertainty that characterized Maya's answer on the conference panel.

The compliance function that does not adapt to the technology transformation underway is not staying still. It is falling behind. Regulators are investing in SupTech. Vendors are using AI. Peer institutions are building data capabilities. The compliance professional who does not develop technology fluency is increasingly unable to evaluate what their institution's compliance systems are doing, assess whether vendor claims are credible, engage with regulatory consultations on technology topics, or hire and manage technically sophisticated compliance staff.

This is not an argument that every compliance professional needs to become a technologist. It is an argument that every compliance professional needs to develop enough technology literacy to govern the technology they are responsible for.

Code Example: A RegTech Trend Radar

The following Python implementation demonstrates a structured approach to tracking emerging regulatory technology trends. Institutions use trend radars to maintain a current assessment of the technology landscape and make deliberate decisions about where to invest attention and resources. The code below provides a simple but extensible framework for this kind of systematic tracking.

from dataclasses import dataclass, field
from enum import Enum


class TrendHorizon(Enum):
    NOW = "0-2 years"    # Currently happening
    NEAR = "2-5 years"   # Emerging
    FAR = "5-10 years"   # Speculative


class TrendReadiness(Enum):
    MONITOR = "Monitor"
    ASSESS = "Assess capability gaps"
    PILOT = "Run a pilot"
    IMPLEMENT = "Implement now"


@dataclass
class RegTechTrend:
    name: str
    description: str
    horizon: TrendHorizon
    readiness_action: TrendReadiness
    regulatory_driver: str
    impact_areas: list[str] = field(default_factory=list)
    confidence: str = "medium"  # high, medium, low


@dataclass
class TrendRadar:
    institution_name: str
    assessment_date: str
    trends: list[RegTechTrend] = field(default_factory=list)

    def by_horizon(self, horizon: TrendHorizon) -> list[RegTechTrend]:
        return [t for t in self.trends if t.horizon == horizon]

    def implement_now(self) -> list[RegTechTrend]:
        return [
            t for t in self.trends
            if t.readiness_action == TrendReadiness.IMPLEMENT
        ]

    def summary(self) -> str:
        lines = [
            f"RegTech Trend Radar: {self.institution_name}",
            f"Assessment: {self.assessment_date}",
            "",
            "=== IMPLEMENT NOW ===",
        ]
        for t in self.implement_now():
            lines.append(f"  * {t.name}: {t.description[:60]}...")
        lines.append("")
        lines.append("=== NOW HORIZON (0-2 years) ===")
        for t in self.by_horizon(TrendHorizon.NOW):
            lines.append(f"  * {t.name} [{t.readiness_action.value}]")
        lines.append("")
        lines.append("=== NEAR HORIZON (2-5 years) ===")
        for t in self.by_horizon(TrendHorizon.NEAR):
            lines.append(f"  * {t.name} [{t.readiness_action.value}]")
        lines.append("")
        lines.append("=== FAR HORIZON (5-10 years) ===")
        for t in self.by_horizon(TrendHorizon.FAR):
            lines.append(f"  * {t.name} [{t.readiness_action.value}]")
        return "\n".join(lines)


# Example: Verdant Bank's trend radar assessment
radar = TrendRadar(
    institution_name="Verdant Bank",
    assessment_date="2025-Q1",
    trends=[
        RegTechTrend(
            name="FCA Digital Regulatory Reporting",
            description=(
                "FCA moving toward API-based direct data feeds "
                "replacing GABRIEL"
            ),
            horizon=TrendHorizon.NOW,
            readiness_action=TrendReadiness.IMPLEMENT,
            regulatory_driver="FCA DRR initiative",
            impact_areas=["regulatory reporting", "data architecture"],
            confidence="high",
        ),
        RegTechTrend(
            name="LLM-assisted regulatory intelligence",
            description=(
                "Using large language models to scan and summarize "
                "regulatory updates"
            ),
            horizon=TrendHorizon.NOW,
            readiness_action=TrendReadiness.PILOT,
            regulatory_driver="Internal efficiency",
            impact_areas=["horizon scanning", "policy management"],
            confidence="medium",
        ),
        RegTechTrend(
            name="SupTech direct data access",
            description=(
                "FCA gaining capability to query firm systems directly "
                "via API"
            ),
            horizon=TrendHorizon.NOW,
            readiness_action=TrendReadiness.ASSESS,
            regulatory_driver="FCA supervisory technology program",
            impact_areas=["data architecture", "data governance"],
            confidence="high",
        ),
        RegTechTrend(
            name="Machine-executable regulation",
            description=(
                "FCA and BoE piloting machine-readable rule expressions"
            ),
            horizon=TrendHorizon.NEAR,
            readiness_action=TrendReadiness.MONITOR,
            regulatory_driver="FCA DRR Phase 2",
            impact_areas=["compliance automation", "regulatory reporting"],
            confidence="medium",
        ),
        RegTechTrend(
            name="EU AI Act compliance requirements",
            description=(
                "High-risk AI system requirements applying to compliance "
                "AI tools"
            ),
            horizon=TrendHorizon.NOW,
            readiness_action=TrendReadiness.IMPLEMENT,
            regulatory_driver="EU AI Act (phased 2024-2027)",
            impact_areas=["model governance", "AI governance", "vendor risk"],
            confidence="high",
        ),
        RegTechTrend(
            name="Digital euro / CBDC integration",
            description=(
                "ECB digital euro requiring new compliance and "
                "payment infrastructure"
            ),
            horizon=TrendHorizon.NEAR,
            readiness_action=TrendReadiness.MONITOR,
            regulatory_driver="ECB digital euro project",
            impact_areas=["payments", "AML", "data architecture"],
            confidence="low",
        ),
        RegTechTrend(
            name="Comprehensive machine-executable substantive rules",
            description=(
                "Full regulatory requirements expressed as executable code"
            ),
            horizon=TrendHorizon.FAR,
            readiness_action=TrendReadiness.MONITOR,
            regulatory_driver="FCA long-term DRR vision",
            impact_areas=["compliance automation", "legal interpretation"],
            confidence="low",
        ),
    ],
)

print(radar.summary())

When this code is run, it produces a structured radar output organized by implementation urgency and time horizon. The TrendHorizon enum distinguishes between trends that are already happening (0–2 years), emerging trends that firms should be assessing (2–5 years), and longer-term speculative developments (5–10 years). The TrendReadiness enum captures the recommended action: some trends warrant immediate implementation; others warrant capability assessment, piloting, or simply monitoring.

The value of this kind of structured tracking is not precision — no one can predict the regulatory technology future with precision — but discipline. A quarterly review of the trend radar forces a compliance leadership team to maintain current awareness of the technology landscape and make explicit decisions about where to invest attention. The alternative — reacting to regulatory changes as they arrive — is consistently more expensive and more disruptive.

Closing: The Conference Room, Later

The panel was over. The moderator had thanked the three panelists and reminded the audience of the next session. The audience had largely dispersed into the conference hallway, forming the smaller clusters of conversation that are, at most professional events, where the actual thinking happens.

Priya, Maya, and Rafael were standing near the stage, still wearing their conference lanyards, holding cups of coffee that were slightly too hot to drink. There was a particular quality to the conversation that sometimes occurs between people who have just performed a version of themselves for an audience — a slightly more honest register, available now that the room had emptied.

Priya had made her announcement at the beginning of the panel, when the moderator introduced the speakers. "Partner, RegTech Advisory," she'd said, and the applause had been warm. She had said it quietly, almost hoping the moderator would move on. Now, in the smaller space of the emptying room, Rafael looked at her.

"Congratulations, by the way. That's real."

"It still doesn't feel real," she admitted. "I keep thinking I'm going to walk into my next client meeting and they'll know I don't know what I'm doing."

"They all feel that way," Rafael said. "The good ones, at least. It's the ones who are certain they know what they're doing who worry me."

Maya laughed. "That's your skepticism working for you."

"It's kept me employed."

Priya looked at her coffee. She had been thinking, since the panel, about what she wished she had said differently. Not what she would have said to be more impressive — she had given up on that as a primary objective some years ago — but what she wished she had known when she was a senior associate, three years and several client engagements behind her current self.

"When I started in this field," she said, "I thought the work was about knowing things. Knowing the regulations. Knowing the technology. Knowing the answer when a client asked me a question." She paused. "I think the work is actually about asking better questions. The more I know, the more I understand why the questions are harder, not easier."

Maya nodded slowly. There was a recognition in her expression. She was one year into her role as CCO of Verdant Bank — not the newest person in the room anymore, but not yet the most experienced one either. She occupied a professional position she had wanted and had found more complicated than she anticipated.

"Law school didn't prepare me for this," she said. "I mean that as a factual observation, not a complaint. Law school gave me a framework for how to think about regulation. It didn't give me any preparation at all for the technology dimension — for what it means to govern a compliance program where half the work is evaluating and managing systems that I can't fully see into." She looked at Rafael. "How did you deal with that? When you started?"

Rafael considered the question with the seriousness it deserved. He was thinking about leaving consulting. He hadn't told them that. He was thinking about the regulatory side — a position he'd been approached about three months ago that he hadn't yet turned down. He would be fifty in five years. He had spent twenty-three years helping institutions build compliance programs. He was considering, for the first time in his career, what it would feel like to sit on the other side.

"Honestly? I didn't deal with it well," he said. "I spent a lot of energy trying to appear more certain than I was, because I thought uncertainty was a weakness. It took me a long time to understand that the uncertainty was the job. That a compliance professional who tells you they know exactly what the regulation means and exactly how the technology should work is either very junior or hasn't thought hard enough about it."

He looked out at the emptying room. Somewhere in the hallway, a session was being called to order.

"What hasn't changed," he continued, "in twenty-three years — is the underlying purpose. Compliance exists because financial markets require trust to function. Regulated institutions have obligations to customers, to market integrity, to financial stability. Technology doesn't change that. It changes how we fulfill those obligations. It creates new capabilities and new risks. But the reason compliance exists — the reason it matters — is as constant as it's ever been."

Priya thought about this. She thought about the clients she'd worked with over the past six years — the ones who'd built good programs and the ones who hadn't; the ones who understood technology and the ones who were intimidated by it; the ones who saw compliance as a cost center and the ones who understood it as an institutional trust mechanism. She thought about the Partner she was now, and the senior associate she'd been, and the CS student she'd been before that.

"What I wish I'd told myself," she said finally, "was to stay curious. Not curious in the sense of reading every paper that gets published — that way lies madness. Curious in the sense of never assuming that the current answer is the final one. Because in this field, it never is."

Maya looked at both of them. She thought about the FCA email waiting for her on her phone. She thought about her team at Verdant — smart, committed people who were navigating the same uncertainty she was, one regulatory change at a time. She thought about the conference panel answer she'd given, and whether she believed it.

She did.

"I'll add one thing," she said. "The professionals who are going to matter most in the next ten years are the ones who keep the institution's purpose in view while they're managing the technology. Because the technology is going to get more complicated, not less. And the purpose — serving customers well, maintaining market integrity, operating honestly within the regulatory framework — doesn't change. Keeping those two things in view simultaneously, without losing either, is the actual job."

Rafael looked at her for a moment.

"You're going to be good at this," he said.

Maya picked up her coffee, finally cool enough to drink.

"I hope so," she said. "I'm certainly going to keep trying."

Summary

This chapter has examined the forward trajectory of regulatory technology across seven domains: the current state of the field, supervisory technology and its implications for regulated institutions, digital regulation and machine-executable rules, the practical role of large language models in compliance, emerging trends in financial market structure, the regulatory horizon, and the evolving skills and career trajectory of compliance professionals.

The central argument of the chapter — and, in a sense, of this book — is that technology changes how compliance is practiced, not what it is for. The purpose of compliance is constant: maintaining the trust and integrity that financial markets require to function. The technology serves that purpose. It is never a substitute for the human judgment, ethical reasoning, and regulatory expertise that effective compliance demands.

The most valuable compliance professional in 2030 will be neither the one who knows the most code nor the one who knows the most regulation. It will be the one who understands enough of both to govern the intersection well — to deploy technology in service of genuine compliance objectives, to maintain human oversight of automated systems, to engage with regulators as a credible expert, and to build programs that adapt gracefully as both technology and regulation continue to evolve.

That is, ultimately, what Maya was saying on the conference panel. And she was right.

Key Terms

SupTech (Supervisory Technology) — Technology deployed by regulatory supervisors to enhance their own supervisory capacity, including analytics of regulatory data, direct data access from regulated firms, and systemic risk monitoring tools.

Digital Regulatory Reporting (DRR) — The FCA/Bank of England initiative to express regulatory reporting requirements in machine-readable form, enabling automated data submission and, ultimately, direct regulatory data access.

Machine-Executable Regulation — The concept of expressing regulatory requirements in formal, computer-executable languages rather than natural language, enabling automated compliance testing.

Hallucination (LLM) — The phenomenon by which a large language model generates text that is confident and fluent but factually incorrect, posing particular risks in high-stakes compliance contexts.

AnaCredit — The ECB's analytical credit dataset program, which collects granular loan-level data from eurozone banks via direct data submission, a leading example of SupTech data collection.

Legal Entity Identifier (LEI) — A globally standardized, machine-readable identifier for legal entities participating in financial transactions, maintained by GLEIF, and used in regulatory reporting across multiple frameworks.

Compliance-by-Design — An approach that embeds regulatory compliance requirements into product and process design from inception, rather than applying compliance review after design decisions are made.

Anti-Fragility — Organizational characteristic by which systems become stronger, not merely resilient, when exposed to regulatory and operational stress; applied to compliance program design.

FEAT — The Monetary Authority of Singapore's Fairness, Ethics, Accountability and Transparency framework for the responsible use of AI and data analytics in financial services.

Embedded Finance — The integration of financial services products (payments, credit, insurance) into non-financial platforms and customer experiences, raising compliance questions about the distribution of regulatory obligations.

Chapter 39 complete. Proceed to Chapter 40: Integrating the RegTech Stack — A Full Program Review.