The Global Risks Alliance (GRA)
Regtech is the technology firms use to meet regulatory obligations: transaction monitoring, sanctions screening, regulatory reporting and conduct surveillance. Suptech is the technology supervisors use to collect and analyse data. Both promise better coverage at lower cost, and both can fail silently through poor data, untested models and dependence on a few vendors. This page treats compliance technology as a field of research: how it works, how its effectiveness is evaluated, and who decides whether it is fit for purpose.
Regtech and supervision · Fintech F1 · Week 39
| Women | 47 | 2 | Within |
| Rural | 47 | 7 | Review |
| Under 25 | 47 | 6 | Review |
Fig.Fintech risk and operations. Design wireframe with placeholder names and illustrative values, not a record or a live system.
Regtech and suptech are the technologies firms use to meet regulatory obligations and supervisors use to collect and analyse data. Both promise better detection at lower cost; alert volume can mask detection, data quality sets the ceiling, and a fault in a shared vendor tool can fail many firms at once.
How a failure at one financial centre can spread through settlement links. Design links, not real dependencies.
Compliance technology as research. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
Rule-based monitoring produces large volumes of false alerts. Analysts triage under pressure, and real suspicious activity can be lost among them. More alerts do not mean more detection.
Screening and reporting are only as good as the customer and transaction data fed to them. Missing fields, transliteration differences and legacy formats cause misses that no model can recover.
Rules expressed as structured data and code can be applied consistently and updated quickly, but translation from legal text can introduce errors. The legal text remains the authority.
Many firms license the same screening lists, monitoring engines and reporting platforms. A defect or outage in one tool affects compliance across the sector, and firms stay accountable for outcomes they outsourced.
Each term as this page uses it. Where a standard-setting body defines the term, the wording follows that body.
| Term | Definition |
|---|---|
| Suptech | The use of technology by supervisors to support supervision, such as data collection and analytics. |
| False positive | An alert raised on activity that turns out to be legitimate. |
| Machine-readable regulation | Rules expressed in a form software can execute, sometimes called rules as code. |
Each indicator carries its unit, its cadence, the kind of source behind it and the evidence label a value would carry. No values are shown: a programme supplies them under its own authority.
| Indicator | Unit | Cadence | Source type | Label |
|---|---|---|---|---|
| Transaction monitoring alerts closed without action | percent of alerts | quarterly | Firm compliance records | OBSERVED |
| Alert backlog | count and days outstanding | monthly | Firm case management | OBSERVED |
| Suspicious transaction reports filed | count per year | annual | Financial intelligence unit statistics | OFFICIAL |
| Regulatory report resubmissions | count by return | quarterly | Supervisor data-quality records | OFFICIAL |
| Authorities using suptech by use case | count of authorities | annual | Surveys of financial authorities | REPORTED |
| Enforcement actions citing monitoring or screening failures | count per year | annual | Regulator enforcement records | OFFICIAL |
| Regulatory sandbox participants by theme | count of firms | annual | Sandbox registers | OFFICIAL |
The topic as a computational graph: named sources feed the methods, an evidence review gates the outputs, and the decisions stay with the authorities that hold them.
Fig. 02Nodes carry their type, two metric rows and a state; connectors show what feeds what; dashed frames name the owners; the timeline is the cadence. Design of the pipeline, not a record of a run.
Named public datasets and institutional records, each with its licence class. Sources by agreement are used only under their terms and never republished.
| Source | What it gives | Licence class |
|---|---|---|
| BIS Financial Stability Institute papers on suptech | Surveys and case studies of supervisory technology use | Free, attribution under BIS terms of use |
| Cambridge SupTech Lab State of SupTech Report | Survey of financial authorities' suptech adoption, data and capacity | Free, terms per publisher |
| Regulatory sandbox registers (FCA, MAS and peers) | Cohorts, firms and themes tested under sandbox arrangements | Public records, terms per regulator |
| Global Financial Innovation Network publications | Cross-border testing and regulator cooperation on innovation | Free, terms per network |
| Regulator enforcement notices | Findings on monitoring, screening and reporting failures | Public records, terms per regulator |
| FATF reports on new technologies for AML and CFT | Opportunities and challenges of technology in compliance and supervision | Free, terms per FATF |
Fintech Nexus prepares evidence. The decisions below are taken by the authorities named, under their own rules, and never by the platform.
| Who decides | The question | Evidence this page serves |
|---|---|---|
| Supervisors and financial intelligence units | Which suptech tools to build or buy, and what data to collect from firms | Suptech surveys, data-quality evidence, comparative case studies |
| Firms' boards and compliance functions | Whether monitoring and screening tools detect what they must, at acceptable cost | Effectiveness evaluation frameworks, alert and backlog metrics, enforcement lessons |
| Standard setters and legislators | Whether rules can be issued in machine-readable form while preserving legal authority | Research on machine-readable regulation, pilot findings |
| Sandbox operators | Which firms and technologies to admit, and on what exit conditions | Sandbox outcome notes, comparative design evidence |
Regtech applications include transaction monitoring for financial crime, automated regulatory reporting, identity verification, trade surveillance and tracking of regulatory change. Many use rules engines combined with machine learning to detect anomalies. Their effectiveness depends on data quality and tuning: poorly calibrated monitoring produces floods of false alerts that overwhelm analysts, or misses real problems.
Suptech applications include collecting granular data from firms, analysing it to detect risks, monitoring markets and processing unstructured information such as complaints and filings. Some authorities are exploring machine-readable and executable regulation, in which rules are expressed in code to reduce interpretation differences.
Accountability remains with people. Automating a compliance process does not transfer responsibility to the vendor or the model, and supervisors expect firms to understand and govern the tools they use. Over-reliance on automated systems can create blind spots when conditions change.
Data standards are the quiet foundation. Common identifiers for legal entities, products and transactions make reporting comparable and analysis possible; without them, both firms and supervisors spend effort reconciling inconsistent data rather than understanding risk.
Measuring whether tools improve detection and outcomes; ground truth is often unknown.
Studying reporting standards and data quality.
Learning from authorities' published experience with suptech.
Limits: firms and supervisors rarely publish performance data, so independent evaluation is difficult, and vendor claims are hard to verify.
The current service level is R0: information and enquiries. An enquiry receives a reference and names the next step; applications, payments, compute allocations and registrations open only when their team, terms and review capacity exist.