Treat cloud concentration as a market level resilience risk

Whether the obligations that keep the system standing are measurable: operational tolerances, incident reporting, safeguarding that is checked, and a regulator that reports on itself.

Resilience obligations are frequently written as intentions. A firm is required to have appropriate arrangements, and nobody can say afterwards whether it did. This pillar looks for numbers, deadlines, and verification.

It covers operational resilience tolerances, incident reporting windows, third party and concentration risk, financial crime expectations, and the safeguarding of customer funds. Safeguarding is treated strictly: an annual attestation from the firm is not the same as a reconciliation somebody outside the firm has checked.

Integrity also runs upward. The pillar includes appeal rights against supervisory decisions and the regulator's own reporting against its stated objectives, because a supervisor that cannot be corrected is a single point of failure like any other.

Covers operational resilience, cybersecurity governance, third-party and cloud risk, incident reporting, AML and CFT clarity for digital channels, and crypto-asset integrity controls where applicable. Excludes pure prudential capital and liquidity, and national cyber policy not directed at financial services.

Resilience assesses whether a jurisdiction's fintech-relevant regulatory framework is designed to keep digital financial services safe, reliable and trustworthy. It looks at operational resilience, cybersecurity, third-party and cloud dependency, incident reporting, AML and CFT clarity for digital channels, and crypto-asset integrity where the jurisdiction permits it.

This pillar does not measure regulatory strictness. It rewards clarity, coverage and implementability across the range of fintech models in scope, and it does not reward a supervisor for being difficult.

Cybersecurity: baseline controls, governance, supervisory guidance

Third-party, outsourcing and cloud risk, including exit and portability

Incident reporting: triggers, timelines, severity thresholds, channels

AML and CFT regime quality for digital channels, including the travel rule

Crypto-asset integrity controls where CASPs are permitted

Prudential capital and liquidity, unless tied to operational resilience or safeguarding

National cybersecurity policy not directed at financial services

Enforcement intensity and supervisory track record, except where published material clarifies expectation

Operational resilience expectations

Cybersecurity governance and controls

Third-party, outsourcing and cloud risk

Incident reporting and crisis handling

AML and CFT clarity and integrity controls

Weights are a starting point. The working group may revise them with documented rationale, which means they are open to an edit too.

Published material only

The assessment reads what a jurisdiction has published. Supervisory expectations communicated privately are invisible to it, which understates jurisdictions that supervise well without writing much down.

Coverage is not effectiveness

A clear, complete framework scores well whether or not it is enforced. Enforcement outcomes sit in pillar 02 and are deliberately not double counted here.

Crypto scope varies

Where a jurisdiction prohibits crypto-asset services, the integrity sub-dimension is reweighted across the remaining four rather than scored as absent.

Seven indicators. This is the canonical text. Select any passage to propose an alternative.

Pillar definition

Rules Clarity & Comprehensiveness (RCC) measures whether a jurisdiction’s fintech‑relevant rules are:

Findable and understandable (“clarity”), and complete enough to cover common fintech activities and risks (“comprehensiveness”), in a way that a regulated firm, or prospective entrant, can determine what licence it needs, what obligations apply, and how to comply, using publicly available materials.

This is not a “friendliness” or deregulatory score. It does not reward laxity; it rewards clarity, coherence, and coverage of the fintech rulebook itself.

Scope and boundaries

In scope (fintech‑relevant rule corpus):

Primary laws and regulations covering:

Core: Payments / payment systems / e-money Banking / lending / credit Securities / investment / advice / management Insurance Digital assets: custody, issuance of crypto tokens / asset tokenisation / stablecoins, crypto‑asset services (if applicable) Subareas within core: Regtech / suptech Digital banking / fintech licensing / regulation digital lending / BNPL Roboadvisory / automated trading Financial infrastructure / trading systems Data analytics / AI Internal IT systems Crowdfunding (if applicable)

Cross‑cutting supervisory requirements that materially affect fintech operations, including:

Core: AML/CFT / (e)kyc Data protection Data use / portability / consent in financial services Identity Subareas: Outsourcing / cloud Cybersecurity Operational resilience Safeguarding of funds Market conduct requirements

Out of scope:

Ecosystem outcomes (e.g. investment levels, number of fintechs). Enforcement “toughness” (except as it affects interpretive clarity and transparency). Broader “quality of regulation” debates unrelated to clarity or coverage.

RCC evaluates the quality and navigability of the rulebook as a rulebook, not the substantive policy stance or outcomes.

Scoring conventions and evidence rule

RCC uses a 0–3 evidence‑based scale:

0 = Opaque / materially unclear: key requirements are hard to find, ambiguous, contradictory, or not operational. No regulation at all.

1 = Partially clear: some guidance exists but significant ambiguity or gaps remain, creating material uncertainty for common models. Advisory / policy statements etc, providing some level of clarification. Role of supervisory processes.

2 = Clear and workable: most relevant rules are findable and understandable; some gaps or fragmentation remain.

3 = Highly clear, coherent, and comprehensive: rules are well‑organised, well‑defined, publicly accessible, consistently explained, and cover the core fintech perimeter with clear compliance pathways.

Across the RCC matrix, a score of 3 should normally require all of the conditions for a 2, plus evidence that the framework is clearly organised and easy to navigate. In practice, this should usually mean that a firm can see how the relevant pieces fit together through a clear official entry point such as a portal, consolidated handbook, licensing map, rulebook structure, or equivalent public navigational tool.

For any score of 3, the evidence log should normally include at least:

a public navigational or mapping tool (for example, portal, handbook, licensing map, or guidance that helps users find obligations), and at least one public binding instrument (law, regulation, rulebook or equivalent) supporting the underlying obligations.

Every score must be supported by public sources (laws / regulations, regulator handbooks, licensing pages, official FAQs / guidance, consultation documents, official portals, policy statements / judicial decisions etc.). “Reputation” or private information cannot be used as evidence.

Conduct of review

The initial review will typically be undertaken as a desk review process. Ideally, it will be followed by direct engagement with participants, similarly to other international standards review processes.

For purposes of FRFI scoring, the RCC Working Group has adopted the following definition of Fintech:

“Fintech businesses use existing or new technology via centralised or decentralised systems to disrupt, to reimagine, to expand a services offering, to create financial instruments, to inhabit a niche, or to offer new ways for people to participate in their financial lives, either directly or through existing financial services providers, from a business, sales, information, analytics, product, regulatory or risk management standpoint.”

This definition is intentionally broad and inclusive. It encompasses new entrants and legacy players, retail and institutional services, and both the provision of financial services directly to end users and the provision of technology that enables others to provide such services. It covers activities conducted on both centralised systems (traditional software, cloud infrastructure) and decentralised systems (blockchain, distributed ledger technology).

A regulatory framework that does not keep pace with new technologies and fintech business models slows the realisation of these potential benefits, by creating uncertainty and friction around licensing, obligations, and compliance

Implication for Scoring: The Regulatory Status Problem

A critical feature of this definition is that it deliberately spans the full spectrum of regulatory status. Fintech businesses as defined above may be:

Category A, Directly Regulated: The firm itself holds a license or registration and is subject to direct regulatory obligations. Forward looking approach. Category B, Unregulated: The firm’s activities do not trigger a licensing or registration requirement and the firm is not subject to direct regulatory obligations. Category C, Unregulated but Indirectly Regulated: The firm is not itself licensed or registered, but provides services to a regulated entity that enable regulated functions, and as a result is subject to regulatory requirements imposed through the regulated entity’s obligations via outsourcing rules, vendor management requirements, or contractual terms imposed by regulatory compulsion.

This three-way distinction creates the following two scoring challenges.

First, for firms in Category B: how does the regulatory framework communicate to an unregulated FinTech firm that it is unregulated, and do so with sufficient clarity that the firm can rely on that determination? A firm that is simply silent in the regulatory framework faces uncertainty, which is itself a form of regulatory unclarity. A well-functioning regulatory environment provides clear negative perimeter guidance, affirmative statements about what is not regulated, not just positive licensing requirements.

Second, for firms in Category C: how does the regulatory framework communicate to an indirectly regulated FinTech firm what obligations flow to it through its regulated clients, and does it do so in a way that is publicly accessible and operationally usable? This category is growing rapidly as regulators extend supervisory reach to critical third-party technology providers, and the clarity, or lack thereof, of those indirect obligations is a material issue for FinTech firms operating as vendors to the regulated sector.

These are addressed through the indicators in the instructions and considerations .

Why this Distinction Matters for RCC

Regulatory regimes differ fundamentally in how they express obligations, and this difference has direct consequences for how RCC indicators should be scored. The RCC pillar measures whether a jurisdiction’s fintech-relevant rules are clear, findable, and complete. But “clear” means something different depending on the regulatory philosophy underlying the framework being assessed. Scorers who fail to account for this distinction will systematically undervalue sophisticated principles-based systems and overvalue prescriptive rules-based systems that may in practice be less navigable.

Rules-Based Regimes

A rules-based regime specifies obligations in precise, detailed terms. It tells regulated firms exactly what they must do, when, how, and in what form. Typical features include numerical thresholds, prescribed reporting formats, mandatory contract terms, defined timelines, enumerated prohibited activities, and specific procedural requirements. The firm’s compliance question is essentially binary: did it follow the specified rule or not?

Rules-based regimes are strong on operational clarity: a firm generally knows exactly what it must file, in what format, and by when. Their limitation is that detailed rules can become outdated quickly as technology and business models evolve, may produce compliance-with-the-letter-but-not-the-spirit behaviour, and can create rigidity that impedes legitimate innovation.

Principles-Based Regimes

A principles-based regime specifies obligations in terms of outcomes or standards of conduct, leaving firms to determine how to achieve them. It tells regulated firms what to achieve, treat customers fairly, maintain adequate capital, manage risk prudently, act with integrity, without dictating the specific means. The firm exercises judgment about how to comply.

Principles-based regimes are strong on outcome clarity: a firm generally knows what standard it is expected to meet and what objective it is expected to achieve. Their limitation is operational ambiguity: a firm may understand perfectly well that it must “treat customers fairly” while remaining genuinely uncertain about whether a specific product feature, disclosure format, or complaint-handling procedure satisfies that obligation. In a principles-based system, that operational content is typically supplied not by the rules themselves but by supplementary interpretive mechanisms, supervisory guidance, published case studies, regulatory speeches, enforcement decisions, and FAQs, which accumulate over time to give the principles practical meaning.

Outcomes-based Regimes

An outcomes-based regime focuses on a particular set of results. The system is then designed to achieve the results which are being targeted.

Such systems - to be effective - must have clear outcomes. Those outcomes must then be clearly tied to the elements of the regulatory system. [add example]

Merit-based Regimes

Merit-based regimes focus on qualitative results: decisions are based on intentions. A merit-based regime may thus be similar in some ways to an outcome based system. However, an outcome based system typically seeks objective results while a merit-based system targets more subjectively. An outcome based system may target “better quality financial products and services” while a merit-based system may target “good financial products and services”.

Merit-based systems often lack clarity of merits being targeted. For clarity, a merits-based regime would need to have clear targets enabled by a regulatory system designed to achieve those targets.

The Spectrum in Practice

Real regulatory systems sit at various points on a spectrum between these categories and most are hybrids. A jurisdiction may use principles for conduct and outcomes while using precise rules for technical requirements such as capital ratios, prescribed reporting taxonomies, and defined timelines for complaint resolution. The UK’s FCA Handbook is a well-known example of a sophisticated hybrid: it contains both high-level principles (the FCA’s Principles for Businesses) and highly detailed prescriptive rules. The EU’s approach under MiCA tends toward greater prescriptiveness. The US operates differently again, with some agencies using a mix of principles and rules while others rely more heavily on supervisory guidance.

How This Affects RCC Scoring

The key analytical point for RCC scoring is this: a principles-based regime can be highly clear on outcomes while being less clear on operations; a rules-based regime tends toward the opposite: clearer on operations but potentially less adaptable and less clear on the underlying purpose of the obligation. To be effective, an outcomes or a merit based regime must have clear outcomes or targets and a system designed to achieve these. No approach is inherently superior from a clarity standpoint, and the FRFI does not take a position on which regulatory philosophy produces better outcomes. What the FRFI measures is how well each jurisdiction achieves clarity within its own chosen approach, and whether the mechanisms it uses to supply operational content are adequate for a regulated firm to determine and implement its obligations.

This has three practical consequences for scoring:

Multiple paths to a high score exist. For indicators where this tension arises, principally RCC-2, RCC-4, RCC-5, RCC-6, and RCC-7, a jurisdiction can reach a score of 3 via a rules-based path, a principles-based path, an outcomes-based path or a merits-based path. The evidence required differs and these paths are specified explicitly in the affected indicators. A principles-based regime should not receive a 3 solely because the underlying principles are well expressed at a high level. A 3 requires that those principles be made operationally usable through a sufficiently mature public interpretive infrastructure, for example through FAQs, speeches, case studies, examples, supervisory statements, enforcement summaries, or equivalent materials that show how the principles are applied in practice. RCC-6 carries greater weight in principles-based systems. In a rules-based system, the rules themselves supply operational content. In a principles-based system, that content is supplied through guidance, FAQs, supervisory statements, and enforcement precedent. For principles-based jurisdictions, RCC-6 is the mechanism by which principles acquire operational clarity. Scorers should read RCC-5 and RCC-6 together for principles-based jurisdictions. Scorers must identify the regulatory philosophy before scoring and note it in the evidence log. This affects both the evidence sought and the rubric path applied. See Section 7 (Evaluator Instructions) for the required procedure.

Sub-dimension: Weight / Indicators A: Accessibility & Usability: 20%: RCC-1, RCC-2 B: Definitions & Perimeter Clarity: 30%: RCC-3, RCC-4, RCC-8, RCC-9 C: Coverage & Completeness: 30%: RCC-4, RCC-5 D: Consistency, Change Management & Interpretive Support: 20%: RCC-6, RCC-7

Working Group decision required on whether to adjust weights following addition of RCC-8 and the elevated importance of RCC-6 in principles-based systems. [Weights are indicative and subject to revision; there is no strict scientific basis for their distribution.]

RCC currently uses eight core indicators. The detailed objective-trigger tables in Section 4 specify how to score 0–3; this overview summarises the purpose of each indicator.

RCC-1 Public accessibility & findability: Whether fintech-relevant rules are freely available online and easy to locate via official sources. RCC-2 Regulatory “map” of obligations: Whether regulators provide an official, usable pathway explaining how a fintech firm, across all three regulatory status categories, determines what license it needs, what licensing conditions apply, what obligations apply, and how to navigate the regulatory framework.. RCC-3 Definitions, Taxonomy & Perimeter Clarity for Common Fintech Activities: Whether key regulatory terms and fintech-relevant activity categories are defined clearly enough that a firm can tell, from public sources, whether it falls within the regulatory perimeter and which regime applies. RCC-4 Coverage across core fintech verticals: Whether the rule corpus covers the major fintech activity verticals without large gaps. RCC-5 Compliance operability: Whether a regulated firm, and where applicable an indirectly regulated vendor, can determine how to implement its obligations in practice RCC-6 Interpretive support & Q&A mechanisms: Whether regulators provide reliable public mechanisms (FAQs, guidance, interpretive processes) to reduce uncertainty. RCC-7 Change management & version control: Whether rule changes, whether to prescriptive rules or to principles and their interpretive elaboration, are made transparently and predictably, with sufficient notice for firms to adapt.. RCC-8: Outsourcing Perimeter & Indirect Supervision Clarity: Whether a regulated FinTech firm, or a regulated entity that uses FinTech vendors, can determine from publicly available sources which of its outsourced or delegated functions remain subject to regulatory oversight, and what it must therefore ensure of the third parties to whom those functions have been delegated.

The Resilience pillar assesses whether a jurisdiction's fintech-relevant regulatory framework is designed to keep digital financial services safe, reliable, and trustworthy. It evaluates operational resilience expectations, cybersecurity governance, third-party and cloud risk controls, incident reporting requirements, and AML/CFT regime quality for digital channels — so that fintech innovation can scale without creating unacceptable systemic, consumer, or crime risks.

Section 0

Overview

This pillar does not measure regulatory strictness. It rewards clarity, coverage, and implementability of resilience and integrity expectations across the range of fintech models in scope: payment service providers (PSPs), e-money institutions, digital banks, digital lenders, and crypto-asset service providers (where applicable).

Section 1

SCOPE AND BOUNDARIES

22

• Operational resilience requirements — business continuity planning, disaster recovery, incident response, critical service mapping, and resilience governance for regulated fintech entities. • Cybersecurity expectations — baseline security controls, governance requirements, and supervisory guidance applicable to regulated entities. • Third-party, outsourcing, and cloud risk — material outsourcing frameworks, cloud-specific guidance, concentration risk rules, and exit/portability planning requirements. • Incident reporting — mandatory reporting obligations for cyber and operational incidents, including triggers, timelines, severity thresholds, and reporting channels. • AML/CFT regime quality for digital channels — clarity of customer due diligence (CDD) and eKYC expectations, suspicious transaction reporting (STR) obligations, and the travel rule where applicable to fintech models. • Crypto-asset integrity controls (where applicable) — custody standards, asset segregation requirements, governance expectations, and market integrity requirements for crypto-asset service providers.

03

Section 2

SCORING CONVENTIONS

Applies the index-wide 0 to 3 scale and four scoring paths specific to this pillar.

0

Absent or unclear

No meaningful requirements exist, or material ambiguity prevents regulated entities from determining their obligations.

1

Emerging

Partial requirements exist. Coverage is limited, applicability to fintech models is uncertain, or guidance is too high-level to be operationally useful.

2

Established

Clear requirements apply across most relevant entity types. Some gaps remain — for example, limited coverage of non-bank fintechs, fragmentation across agencies, or absence of supervisory guidance.

3

Comprehensive & implemented

A robust, coherent framework is in place with clear expectations, documented reporting pathways, and published supervisory guidance. Requirements apply explicitly across core fintech models — not only to banks.

Evidence rule:

Every score must be grounded in publicly available primary sources — laws, regulations, supervisory handbooks, circulars, guidance notes, or official reporting rules. No anecdotal or reputation-based scoring.

Four-scale scoring

Each RI indicator carries a main rubric plus three further 0–3 scales, all recorded for every jurisdiction:

Main rubric

The substance of the requirement itself.

Evidence rating

The legal force of the sources found, graded against four levels: Level 1 primary legislation; Level 2 binding subordinate legislation (regulations, technology-risk standards, licensing conditions); Level 3 binding supervisory requirements (directives, notices, enforceable circulars, binding handbooks); Level 4 non-binding guidance.

Applicability rating

Whether the binding instrument reaches non-bank fintechs specifically and by name or clear functional definition, rather than through ambiguous or uncodified extension of bank rules.

Outcome-based rating

What the framework actually delivers in practice.

Note

Multi-path anchors. RI-1 sets out separate rules-based and outcomes-based (principles) anchors for scores 2 and 3, with scores 0 and 1 shared.

Section 3

Sub-Dimensions

Sub-dimension

Weight / Indicators

RI-1 — Operational Resilience Baseline Requirements

22% — RI-1

RI-2 — Cybersecurity Governance and Minimum Controls

20% — RI-2

RI-3 — Third-Party Risk Management Framework

19% — RI-3

RI-4 — Incident Reporting Requirements and Timelines

5% — RI-4

RI-5 — Resilience Testing and Assurance Expectations

14% — RI-5

RI-6 — AML/CFT Clarity for Digital Onboarding and Fintech Models

20% — RI-6

6

Section 4

Indicator Matrix

06

A

B

C

D

E

F

RI-1

Operational Resilience Baseline Requirements

Sub-dim A

00 sug

RCC-1

Public Accessibility & Findability

Sub-dimension:

What it measures

RI-1 measures whether a jurisdiction's fintech-relevant regulatory framework has established clear, binding, and published expectations ensuring that digital financial service providers can maintain core operations, safeguard financial stability, and recover rapidly when an operational shock or technology breakdown occurs.

Framing Note

Draft international best-practice standard. A jurisdiction meets the RI-1 standard where its financial-sector framework requires regulated entities to maintain: Board- and senior-management accountability for operational resilience and continuity; Documented continuity frameworks integrated with either quantitative Recovery Time Objectives (RTOs) or defined impact tolerances for severe but plausible disruptions; Identification and mapping of critical business functions/important business services, internal sub-processes, and external dependencies; and Mechanisms for supervisory review and challenge, with all of the foregoing applying consistently across entities in scope.

Components

Component A Governance and C-Suite Accountability: The framework assigns explicit responsibility for operational resilience and continuity to the board and senior management. It requires executive-level oversight, dedicated operational risk resourcing, and formal integration of continuity strategies into enterprise risk management.

Component B Business Continuity & Operational Targets

The framework requires a documented approach to business continuity designed to withstand severe operational disruptions. Depending on the regulatory model, this is demonstrated through prescriptive Disaster Recovery (DR) frameworks with fixed Recovery Time Objectives (RTOs) or through the setting of "impact tolerances" that define the maximum tolerable level of disruption to an important business service.

Component C Critical Service & Interdependency Mapping

The framework requires entities to map their end-to-end critical business functions or important business services, identifying internal asset interdependencies (people, technology, processes) and external third-party dependencies. (Boundary Note: Specific vendor contractual terms and cloud exit strategies are evaluated under RI-3.)

Component D Supervisory Review and Enforceability

The requirements sit in a binding or enforceable instrument supported by a supervisory mechanism allowing the regulator to actively challenge, audit, and sign off on an entity's operational resilience parameters. (Boundary Note: Active threat-led penetration testing is evaluated separately under RI-5.)

Component E Cross-Entity Applicability

The requirements apply consistently across entities in scope: Banks, PSPs, e-money institutions, digital banks, digital lenders, and CASPs where permitted. Explicit statutory or binding supervisory applicability to non-bank fintechs forms the primary boundary condition for a score above Level 1.

Scoring Rubric

Score

Proposed Objective Trigger

No operational resilience or continuity requirements directed at financial entities exist in published law, regulation, or binding supervisory instruments; or provisions are so ambiguous that a regulated entity cannot determine its obligations. Entity-coverage test: No instrument references non-bank fintechs.

No evidence found in Levels 1 - 4;

No regulated fintech provider is subject to operational resilience requirements.

No assurance that fintech services can survive operational shocks or system outages.

A binding instrument or Level 4 guidance imposes a general obligation to manage continuity (e.g., "entities must have a BCP"), but core elements are missing: governance accountability is not assigned to the board; explicit recovery metrics/impact tolerances are absent; or requirements are drafted for prudential banks only. Entity-coverage test: Requirements do not clearly reach non-bank fintechs, or reach them only by generic, uncodified reference.

Outcomes-Based (Principles) Path

Binding requirements (Levels 1-3) clear the Resolution Gate by establishing BOTH: (1) Explicit applicability extending directly to non-bank PSPs and e-money institutions; and (2) Binding operational minimums including C-suite/board governance accountability, the identification of important business services, and the setting of defined impact tolerances for severe but plausible disruptions. At least one significant gap remains: end-to-end dependency mapping is absent; scenario testing expectations are uncodified; or there is no verifiable operationalization record.

Evidence only in Level 4, or limited Level 1-3 provisions applying to banks or via generic reference.

Applies directly to several major non-bank fintech categories (PSPs, EMIs), but excludes others without documented rationale.

Regulated fintechs maintain accountable governance and defined recovery targets/impact tolerances, but gaps remain in interdependency mapping and supervisory testing.

Main rubric - Rules-Based Path

Binding requirements (Levels 1-3) establish all of: (i) Explicit board/senior-management accountability; (ii) Binding BCP/DR frameworks with numeric RTOs for core services; (iii) Mandated critical service, business function, and dependency mapping; (iv) Interactive supervisory review and challenge mechanisms; and (v) Explicit, consistent applicability across core non-bank fintech models. Operationalization requirement: A published supervisory examination, thematic review, or enforcement action demonstrating application to fintech operational resilience is required.

Binding requirements in Levels 1-3 exist, but are incomplete in mapping depth, supervisory challenge, or operationalization record.

Requirement applies to several major fintech providers categories but excludes one or more significant categories without a clear risk based justification.

Functional Consumer Protection Outcome Most consumers receive standardised disclosures before purchasing or using digital financial products. Material fees and product features are disclosed, but gaps remain in coverage, digital presentation, ongoing updates, or supervisory monitoring.

Binding requirements (Levels 1-3) establish all of: (i) Explicit board/senior-management accountability; (ii) A mandate to ensure important business services can remain within defined impact tolerances under severe but plausible scenarios; (iii) Mandated resource and dependency mapping for all identified important business services; (iv) Interactive supervisory review and challenge mechanisms; and (v) Explicit, consistent applicability across core non-bank fintech models. Operationalization requirement: A published supervisory thematic review, enforcement action, or public assessment demonstrating application to fintech operational resilience is required.

Comprehensive, enforceable requirements in Levels 1-3, supported by supervisory review and a verifiable operationalization record.

Applies consistently across all relevant fintech categories, with any exclusions explicitly risk-based, documented, and proportionate.

Regulated fintechs maintain fully mapped, executive-backed operational resilience architectures capable of maintaining critical services through major disruptions.

Scoring paths

Two paths: rules-based and outcomes-based (principles). Coders identify the jurisdiction’s dominant regulatory philosophy first, apply the matching path for scores 2 and 3, and note the path used in the evidence log.

Primary evidence sources

Evidence Tiers

Scores are anchored strictly to publicly verifiable primary sources, classified by legal force: Level 1: Primary legislation: Financial services acts, payment systems statutes, or operational resilience acts. Level 2: Binding subordinate legislation: Regulations, technology-risk standards, and licensing conditions. Level 3: Binding supervisory requirements: Directives, notices, enforceable circulars, and binding supervisory handbooks. Level 4: Non-binding guidance: Guidance notes, best-practice papers, supervisory expectations, and FAQs.

Entity-Coverage Test

For each requirement, ask: Does the binding instrument reach non-bank entities (PSPs, e-money institutions, digital lenders, CASPs) specifically and by name or clear functional definition, rather than through ambiguous or uncodified extension of bank rules? Record which provider category forms the binding constraint on the score.

Reference-versus-Mandate Rule

Reference-versus-Mandate Rule: Financial regulators frequently reference soft-law principles without mandating them. A reference alone or a non-binding guidance paper (Level 4) caps the score at 1 (Emerging). Transposition into binding domestic instruments (Levels 1-3) is required for a score of 2 or higher.

Operationalization Requirement for a Score of 3

A score of 3 requires evidence that the framework has been applied in practice to fintech operational resilience via a published supervisory examination report, thematic review, or enforcement action demonstrating active application. A framework that is comprehensive on paper but lacks a verifiable operationalization record is capped at a Score 2.

Aggregation rule

Direct

single integer score 0–3. The same score is also rated on three further 0–3 scales — evidence, applicability and outcome-based. All four sit together in each score cell, each under its own label.

Suggest an edit

Endorse a level

Cite this indicator

RI-2

Cybersecurity Governance and Minimum Controls

Whether regulated entities have clear, published expectations for cybersecurity governance (board/management accountability) and baseline technical and organisational security controls.

Note on the Standard

The standard is written by reference to established international standard-setting bodies. Jurisdictions are used only to validate and improve the standard rather than to rate the jurisdictions themselves at this stage.

Technology-neutral

The standard asks whether a jurisdiction’s financial-sector framework requires sound cyber governance and a defined baseline of controls. It takes no position on any particular technology or architecture, including the question of centralized versus decentralized infrastructure. Where a framework is silent on a novel architecture, that silence is noted as a gap rather than scored as a technology preference.

Proportionality

The standard is applied proportionately to the scale, complexity, and cross-border reach of the fintech activity actually present in a jurisdiction. It rewards a framework that is appropriate to the entities operating in that market, rather than the presence of every element regardless of relevance, and it is not benchmarked to any single jurisdiction or region. A smaller or less-mature market whose framework comprehensively addresses the entity types and risks actually present is not marked down for omitting elements that are not relevant to it, provided the regulator’s rationale is adequately documented.

Terminology

The entity categories used in this indicator (banks, payment service providers, e-money or stored value issuers, digital banks and lenders, and crypto-asset service providers) are functional descriptions, not any single jurisdiction’s licensing labels. Scorers map local entity types to these functions and do not mark a jurisdiction down for using different terminology, or for drafting in a language other than English.

Standard Statement

A jurisdiction meets the RI-2 standard where its financial-sector framework requires regulated entities to maintain (a) board- and senior-management accountability for cyber and information and communications technology (ICT) risk; (b) a documented cyber/ICT risk-management framework integrated into enterprise risk management; (c) a defined baseline of minimum technical and organizational controls; (d) a continuous detection and monitoring capability; and (e) mechanisms for supervisory review and enforcement with all of the foregoing (f) applying consistently across entities and technologies in scope.

Component A: Governance and Accountability

The framework assigns explicit responsibility for cyber and ICT risk to the board and senior management, identifies a designated accountable function (e.g., a Chief Information Security Officer or equivalent), requires board-level oversight and reporting, and calls for adequate resourcing and independence of the security function and for cyber-risk awareness across the organization.

Component B: Cyber/ICT Risk-management Framework

The framework requires a documented approach to identifying, assessing, and managing cyber/ICT risk, including asset and critical-function identification, a defined risk appetite, and integration into enterprise risk management, using a common risk taxonomy.

Component C: Minimum Baseline of Technical and Organizational Controls

The framework specifies a baseline of controls rather than instructions to “manage cyber risk.” At minimum: identity and access management (least privilege, multi-factor authentication, and privileged-access management); asset and configuration management; vulnerability and patch management; data protection and encryption in transit and at rest; secure configuration; and network security.

Component D: Detection and Monitoring Capability

The framework requires the capability to detect cyber events on a timely basis: logging, security monitoring, and use of threat intelligence. Note that the obligation to externally report incidents and the applicable timelines are assessed under RI-4 while RI-2 assesses the internal detection capability.

Component E: Supervisory Review and Enforceability

The requirements are set out in a binding or enforceable instrument and supported by a supervisory mechanism: examination powers, reporting to the supervisor, or an equivalent means by which the authority can assess compliance and take corrective action.

Component F: Cross-entity Applicability

The requirements apply consistently across entities in scope: banks, PSPs, e-money institutions, digital banks and lenders, and CASPs where permitted. Any exclusion of a provider category is explicitly risk-based, proportionate, and documented by the regulator.

No cybersecurity governance or control expectations directed at financial entities exist in published law, regulation, or binding supervisory instruments; or provisions are high-level or ambiguous to a point that a regulated entity cannot determine any governance responsibility or minimum control obligation. Entity-coverage test: no instrument references financial-sector entities, or only aspirational statements exist.

No evidence found in Levels 1 - 4.

No fintech provider is subject to the relevant legal or regulatory requirements.

No assurance that regulated fintechs govern or control cyber risk; no binding obligation exists.

A binding instrument imposes a general obligation to manage cyber/ICT risk, but at least one core element is missing: governance accountability is not assigned (no board/senior-management responsibility); or no minimum controls are specified; or the obligation is drafted for banks/prudential institutions only. Requirements may rest only on non-binding guidance (Level 4). Entity-coverage test: requirements do not clearly reach non-bank fintechs, or reach them only by generic reference.

Evidence only in Level 4, or limited provisions in Levels 1-3 applying to some entity types or as generic references.

Applies only to traditional banks/prudential institutions or a single category, excluding most fintechs.

Some entities are subject to cyber expectations, but coverage is fragmented; users cannot expect consistent cyber governance across digital financial services.

Binding requirements (Levels 1-3) establish both (a) cyber/ICT governance accountability at the board/senior-management level and (b) a defined set of minimum technical and organizational controls, applying to most relevant regulated fintech categories. At least one significant gap remains: e.g., a fintech category excluded without a documented risk-based rationale; fragmentation across the financial regulator, cyber authority, and financial intelligence unit (FIU) that leaves responsibilities unclear; controls are stated only at a high level with no implementation guidance; or an external standard is referenced but not mandated; or there is no verifiable operationalization record. Entity-coverage test: binding requirements reach several major fintech categories but are not applied consistently across all relevant entities.

Binding requirements in Levels 1-3 exist but are incomplete in governance scope, control specificity, or fintech application.

Applies to several major fintech categories but excludes one or more significant categories without a published risk-based justification.

Most regulated fintechs are subject to governance accountability and baseline of controls, but gaps remain in coverage, control specificity, or supervisory monitoring.

Binding requirements (Levels 1-3) establish all of: (i) explicit board/senior-management accountability with a designated responsible function; (ii) a documented cyber/ICT risk-management framework integrated into enterprise risk management, with a defined risk appetite; (iii) a minimum baseline of technical and organizational controls (identity and access management including MFA and privileged-access control; asset and configuration management; vulnerability and patch management; data protection and encryption logging and monitoring/detection); (iv) a supervisory review mechanism with examination or reporting powers; and (v) explicit, consistent applicability across core fintech models, with any exclusions explicitly risk-based and proportionate. A jurisdiction may alternatively reach 3 through a proportionate path: its framework comprehensively covers the entity types and risks actually present in its market, and any element that is absent is documented by the regulator as not relevant to that market. Operationalization requirement: a published supervisory examination or thematic review, enforcement action, or supervisory guidance demonstrating application to fintech cyber governance is required.

Comprehensive, enforceable requirements in Levels 1-3, supported where appropriate by supervisory guidance and a verifiable operationalization record. A Level 4 source alone would not justify a score of 3.

Applies consistently across all relevant regulated fintech categories, with any exclusions explicitly risk-based, documented, and proportionate. An undocumented carve-out would be considered an unexplained gap and would receive a score of 2.

Regulated fintechs consistently maintain accountable cyber governance and a baseline of controls, subject to supervisory oversight and corrective action, producing predictable protection of digital financial services.

One path — the anchors apply to all four approaches.

Primary sources to consult

Cyber or technology risk rules; security standards mandated by the financial regulator; supervisory guidance on cyber governance. The following were utilized in the drafting of these standards.

G7 Cyber Expert Group

Fundamental Elements of Cybersecurity for the Financial Sector; Fundamental Elements for Third-Party Cyber Risk Management.

Basel Committee on Banking Supervision (BCBS)

Principles for Operational Resilience; Principles for the Sound Management of Operational Risk.

CPMI–IOSCO

Guidance on Cyber Resilience for Financial Market Infrastructures; CPMI guidance on endpoint security for wholesale payments.

Financial Stability Board (FSB)

Cyber Lexicon; Effective Practices for Cyber Incident Response and Recovery; incident-reporting convergence work.

IOSCO

Cyber-resilience guidance for securities markets.

NIST

Cybersecurity Framework 2.0 (Govern, Identify, Protect, Detect, Respond, Recover); post-quantum cryptography standards.

ISO/IEC

27001 (ISMS) and 27002 (controls); 27005 (risk management).

EU DORA

Digital Operational Resilience Act, as a leading implemented regime (referenced for governance and ICT-risk-management structure; the standard is drafted to apply beyond DORA jurisdictions).

Score against publicly verifiable primary sources, classified by legal force. A higher tier carries greater weight.

level

Primary legislation: financial services acts; ICT/cybersecurity statutes applicable to financial entities.

Binding subordinate legislation: regulations, prudential and technology-risk standards, licensing conditions, mandatory ICT/cyber rules.

Binding supervisory requirements: directives, notices, enforceable circulars, and codes incorporated by reference into regulation.

4

Non-binding guidance: guidance notes, best-practice papers, supervisory expectations, FAQs.

For each requirement, ask: does the binding instrument reach non-bank entities such as PSPs, e-money institutions, digital lenders, CASPs, and is it drafted to apply to them specifically, rather than by generic extension of bank rules? Record which provider category is the binding constraint on the score.

Reference-versus-mandate Rule

Financial regulators frequently reference external standards (e.g., NIST CSF, ISO/IEC 27001) without mandating them. A reference alone does not raise the score. Where a regulator incorporates or mandates an external standard in a binding or enforceable way, that supports a higher score than one that only encourages it.

A score of 3 requires evidence that the framework has been applied in practice to fintech cyber governance: a published supervisory examination or thematic review, an enforcement action, or supervisory guidance demonstrating application (not just the existence of a rule). For example, a framework that is strong on paper but lacks a verifiable operationalization record would receive a score of 2.

Two-variable Threshold

Consistent with the shared scoring convention used across pillars, each score combines two variables: (i) whether a binding legislative or regulatory basis exists and (ii) whether that basis is operationalized in practice. A score of 2 reflects certainty on one of these variables for the core requirements; a score of 3 requires certainty on both across the full scope of the indicator.

Maturity Cap

Proposals and consultations do not count as implemented and cap the attainable score at 1. Rules enacted but not yet in force, and without accompanying operational guidance, cap the attainable score at 2.

Edge cases & scoring notes

Scoring note

Do not require adoption of a specific external standard (NIST, ISO 27001). Score whether the financial regulator has issued binding or enforceable cybersecurity expectations with clear content. A regulator that mandates compliance with an external standard explicitly scores higher than one that merely references it.

Evidence and Edge-case Conventions

Use only public, citable sources; do not infer a score from reputation. For non-English sources, note the language and whether an official or machine translation was used, and do not penalize a jurisdiction for language alone. Where a score is a close call between two levels, record the specific rubric trigger that was not met. In federal or multi-agency systems, score the regime that actually binds financial entities, document the allocation, and treat unresolved fragmentation that leaves obligations unclear as a scoring factor in its own right.

single integer score 0–3. The same score is also rated on three further 0–3 scales — evidence, applicability and outcome-based. All four sit together in each score cell, each under its own label. Each component (A to F) is scored 0 to 3 and logged at component level; the indicator-level RI-2 score is the simple average of the component scores.

RI-3

Third-Party Risk Management Framework

RI-3 assesses whether (1) regulated fintechs are subject to a proportionate third-party risk management regulatory framework that considers the complexity of regulated entities and criticality of their third-party service relationships, (2) the regulatory framework reinforces sound governance standards over third-party risk management, and (3) regulatory requirements and expectations are aligned with the third-party service relationship lifecycle, ensuring a structured regulatory framework that appropriately addresses the risks relevant to fintechs and their third-party relationships.

A jurisdiction meets the RI-3 standard when its third-party risk management regulatory framework is operationalized (see description of Cap 1 below in the Scoring Notes) and exhibits the following characteristics (each, a Sub-Dimension):

Proportionality is a core regulatory principle across the third-party risk management framework, such that (i) the regulatory framework establishes a structure in which third-party risk (and thereby third-party risk management) may be commensurate with a fintech’s business model, complexity, cross-border operations, risk profile, scale, structure and size; and (ii) regulatory requirements are flexible based on a criticality or materiality basis. Applicability is consistent across core fintech models (including digital lenders and CASPs where permitted), with any exclusion explicitly risk-based and documented. The regulatory framework establishes requirements that assign explicit responsibility for third-party risk management to the board and/or senior management, require a documented third-party risk-management framework, and state that accountability for outsourced functions remains with the regulated entity. Applicability is consistent across core fintech models, with any exclusion explicitly risk-based and documented; and A binding framework covers the full relationship lifecycle on a criticality basis and core risk areas are covered with clear, implementable regulatory guidance; the scope of the regulatory framework extends beyond formal outsourcing to material third-party relationships generally; and applicability is consistent across core fintech models, with any exclusion explicitly risk-based and documented.

RI-3A: Proportionality — Assesses whether proportionality functions as a core regulatory principle across the third-party risk-management framework, indicating the regulator has considered how third-party risk (and therefore third-party risk management) varies with a fintech’s business model, complexity, cross-border operations, risk profile, scale, structure, and size. Regulatory obligations should scale based on the criticality or materiality of the third-party service relationship and the nature of the regulated entity’s business, rather than applying uniformly. RI-3B: Governance — Assesses whether the regulatory framework assigns explicit responsibility for third-party risk management to the board and/or senior management, requires a documented third-party risk-management framework, and makes clear that accountability for outsourced functions remains with the regulated entity. RI-3C: Alignment with and Coverage Across the Third-Party Relationship Lifecycle — Assesses whether the framework aligns with the third-party service relationship full lifecycle (planning and risk assessment, risk-based due diligence, contracting, ongoing monitoring, and termination/exit) and provides guidance on core third-party risk areas, such as: (i) contractual obligations; (ii) third-party supply-chains; (iii) third-party relationship registers; (iv) concentration risk; and (v) business continuity planning.

RI-3A: Proportionality

No third-party or outsourcing risk-management framework exists in published instruments; or a framework exists but applies uniformly with no recognition (in any instrument, at any evidence level) that third-party risk varies with the entity or the criticality of the relationship.

RI-3B: Governance

No third-party or outsourcing risk-management framework exists in published instruments; or no governance requirements for third-party or outsourcing risk are directed at financial entities in published law, regulation, or binding supervisory instruments.

RI-3C: Alignment with and Coverage Across the Third-Party Relationship Lifecycle

No third-party or outsourcing risk-management framework exists in published instruments; or the risk management framework does not align with an articulated third-party relationship lifecycle (or is not otherwise organized under some structural principle).

Proportionality is only referenced in general terms (e.g., a bare “risk-based approach” statement) without articulating the calibration factors or how obligations scale; proportionate treatment appears only in Level 4 guidance; or the framework in which proportionality operates is drafted for banks or prudential institutions and does not clearly reach non-bank fintechs (or reaches them only by generic, uncodified reference).

A general obligation to manage third-party or outsourcing risk exists, but responsibility is not assigned to the board or senior management; no documented third-party risk-management framework is required; and/or retained accountability of the regulated entity for outsourced functions is unstated. Regulatory requirements are drafted for banks or prudential institutions only and do not clearly reach non-bank fintechs.

The third-party risk management framework only addresses isolated lifecycle stages (e.g., due diligence at onboarding, with no ongoing monitoring or exit expectations) or applies only to formal “outsourcing” arrangements. The risk management framework does not provide any guidance across identified risk areas. Finally, the regulatory requirements do not clearly extend to non-bank fintechs (or reach them only by generic reference).

A framework exists at some level across Level 1–4 instruments. The framework is built upon proportionality as a principle: obligations apply based on the complexity (or risk-profile) of a regulated entity and/or the criticality or materiality of the third-party service relationship. At least one of the following gaps remain: The framework is only established in Level 4 instruments; While the regulatory framework identifies entity- and/or relationship-level factors (business model, complexity, risk profile, scale, structure) that impact the applicability of regulatory requirements/guidance, there is no guidance on how obligations scale and apply in practice; or The regulatory framework applies to some major non-bank fintech categories (e.g., PSPs and e-money institutions); however the scope of the regulatory framework is not clearly defined or at least one or more fintech categories is excluded without a documented risk-based rationale.

A framework exists at some level across Level 1–4 instruments. The framework assigns explicit responsibility for third-party risk management to the board and/or senior management, requires a documented third-party risk-management framework, and states that accountability for outsourced functions remains with the regulated entity, applying directly to the major non-bank fintech categories (at minimum PSPs and e-money institutions). At least one of the following gaps remain: The framework is only established in Level 4 instruments; or One or more fintech categories is excluded without a documented risk-based rationale.

A framework exists at some level across Level 1–4 instruments. The framework aligns with the full relationship lifecycle — planning and risk assessment, risk-based due diligence, contracting, ongoing monitoring, and termination/exit – and identifies core risk areas for regulated entities. The third-party risk management regulatory framework establishes clear expectations, applies to major non-bank fintech categories (e.g., PSPs and e-money institutions). At least one of the following gaps remain: The framework is only established in Level 4 instruments; The regulatory framework only covers core risk areas at a high level; The regulatory framework centers around outsourcing only, excluding material non-outsourcing third-party services without rationale; or One or more fintech categories is excluded without a documented risk-based rationale.

Core obligations are established in Level 1–3 instruments, as applied to in-scope fintechs. Proportionality is a core regulatory principle across the third-party risk management framework, such that (i) regulatory requirements are flexible based on a criticality or materiality basis; and (ii) the regulatory framework establishes a structure in which third-party risk (and thereby third-party risk management) may be commensurate with a fintech’s business model, complexity, cross-border operations, risk profile, scale, structure and size. Applicability is consistent across core fintech models (including digital lenders and CASPs where permitted), with any exclusion explicitly risk-based and documented.

Core obligations are established in Level 1–3 instruments, as applied to in-scope fintechs. The regulatory framework establishes all of the Score 2 elements and applicability is consistent across core fintech models, with any exclusion explicitly risk-based and documented.

Core obligations are established in Level 1–3 instruments, as applied to in-scope fintechs. The regulatory framework covers the full relationship lifecycle on a criticality basis and core risk areas are articulated with clear, implementable regulatory guidance; the scope of the regulatory framework extends beyond formal outsourcing to material third-party relationships generally; and applicability is consistent across core fintech models, with any exclusion explicitly risk-based and documented.

Score using publicly verifiable primary sources, classified by legal force and effect (i.e., does a failure to comply result in liability).

Primary legislation: laws related to financial services and payment services; laws and/or regulations that impose outsourcing or third-party requirements on financial entities (e.g., DORA as directly applicable EU regulation).

Binding subordinate legislation: outsourcing regulations, technology-risk standards, licensing conditions, mandatory notices (e.g., MAS Notice 658), regulatory technical standards on contractual and sub-outsourcing requirements.

Binding supervisory requirements: directives, notices, enforceable circulars (including cloud circulars), and codes or guidelines incorporated by reference into regulation.

Non-binding guidance: guidance notes, best-practice papers, supervisory expectations, FAQs, and discussion papers.

Scoring Notes

The RI-3 indicator score is the highest band whose conditions are met, subject to the cap below. Add the score from all sub-dimensions and assign the jurisdiction a Band.

Band 3: The combined score between the sub-dimensions is greater than or equal to 8 and a verifiable operationalization record exists (see Cap 1 below). For example, a jurisdiction with the following sub-dimension scores (and a verifiable operationalization record) should be scored at Band 3: RI-3A = 3; RI-3B = 3; RI-3C = 2 or above. Band 2: The combined score between the sub-dimensions is between 5 - 7 or the combined score is 8 or higher but a verifiable operationalization record does not exist (see Cap 1 below). For example, a jurisdiction with the following sub-dimension scores should be scored at a Band 2: RI-3A = 2; RI-3B = 2; and RI-3C = 1 or above. Band 1: The combined score between the sub-dimensions is between 1-4. In effect, third-party or outsourcing requirements exist in a published instrument, but the Band 2 conditions are not met (including because regulatory requirements apply to fintechs only by generic reference). Band 0: Absent — all three sub-dimensions score 0.

Sub-dimension scores should not be averaged. If a jurisdiction scores below Band 3, record why: the specific trigger not met, the binding sub-dimension, and/or the cap (if any) that applied. The three sub-dimensions should be scored independently and were designed to complement each other. For example, a criticality threshold cited as evidence of proportionality under RI-3A may also be the basis on which obligations apply throughout the third-party service lifecycle under RI-3C.

Cap 1: Evidence of Operationalization for a 3

A score of 3 requires evidence that the regulatory framework has been applied in practice to fintech’s third-party arrangements. Examples of an operationalized supervisory framework include evidence suggesting the relevant regulatory body actively administers the regulatory framework, such as the issuance of supervisory guidance; physical or digital offices / forums through which regulated entities can engage the regulator; evidence of supervisory actions; enforcement actions; online forums through which regulated entities may submit filing applications, reports, or complaints; and/or published inspection findings.

Core Risk Areas (RI-3C)

Historically, outsourcing and third-party risk management frameworks are designed to mitigate risks across a range of areas. Instead of mandating the risk areas that a regulatory framework should address, scorers should evaluate whether the regulator establishes clear expectations in Level 1–3 sources regarding risk areas that are relevant for the regulatory regime. Examples of core risk areas and controls include:

Contractual Obligations: Third-party and outsourcing risk management frameworks often include a minimum set of required contractual provisions for critical or material relationships, such as service descriptions and measurable service levels; security, confidentiality, and data-protection obligations, including data location and processing; provider business-continuity and incident obligations; conditions on sub-outsourcing (notification or consent, and flow-down of obligations); enforceable audit, access, and information rights for the regulated entity, its auditors, and its regulator; termination rights; and cooperation with the entity’s exit plan. Third-Party Supply Chains : Third-party risk management regulatory frameworks often provide guidance (and/or impose requirements) related to maintaining visibility into material supply chains (fourth- and n-th-party dependencies) supporting critical functions; conditions under which sub-contracting is permitted; downstream security, audit, and continuity obligations; and intra-group arrangements expressly within scope of the framework. Third-Party Relationship Registers: Some regulatory frameworks may, in certain circumstances, require regulated entities to maintain a register of third-party relationships (at minimum, critical ones), producible to the regulator on request. Concentration risk : Increasingly, third-party risk management frameworks include mechanisms by which concentration risk is identified and managed by regulated entities, including through entity-level assessment and reporting to regulators. Business Continuity Planning: Third-party risk management frameworks often require regulated entities to maintain documented exit strategies for critical service relationships, addressing both stressed and non-stressed exits, linked to the entity’s business continuity planning. Note, RI-3C only scores continuity for critical third-party service relationships.

Regulatory Structure and Scope

Note, regulatory requirements may not be clearly labeled as “third-party risk management” and/or otherwise be imposed through a complex series of regulatory requirements and expectations. For example, third-party risk management may be established in an outsourcing regime, an ICT third-party risk regime, a technology risk management framework, and/or general vendor-management guidance. A regulatory framework comprising various instruments (e.g., an outsourcing notice plus a cloud circular) should be scored on the consolidated regulatory framework, with any lack of clarity documented when uncertainty arises.

Entity Coverage

Entity coverage has been considered across each sub-dimension in the scoring rubric. For each sub-dimension, ask whether the instrument reaches in-scope entities (PSPs, e-money institutions, digital banks, digital lenders, and CASPs where permitted) specifically and by name or clear functional definition, rather than by generic extension of bank rules, and record which provider category is the binding constraint. Note, digital banks are adequately covered if/when the banking regime applies to them by charter or license.

Federal / Multi-Regulator Convention

For federal or multi-regulator systems, assess the dominant applicable regulatory framework for the entity category being tested and document which regime was scored. Where different regulators impose materially different outsourcing regimes on comparable entities, treat any unexplained fragmentation as a gap under the rubric.

single integer score 0–3. Three further 0–3 scales (evidence, applicability, outcome-based) are recorded alongside it, each under its own label.

RI-4

Incident Reporting Requirements and Timelines

Sub-dim C

Whether firms that are authorised, regulated or supervised in the financial services sector are required to report material ICT-related, cyber, security and operational incidents to the relevant authority under a clear, binding and proportionate framework. The indicator assesses whether the framework tells firms what must be reported, when it must be reported, to whom it must be reported, and what follow-up is required.

This standard is informed by established international frameworks and implemented supervisory models, including the FSB’s work on cyber incident reporting convergence and the Format for Incident Reporting Exchange (FIRE), the FSB Cyber Lexicon, BCBS Principles for Operational Resilience, CPMI-IOSCO cyber resilience guidance for financial market infrastructures, EU DORA, the EBA Guidelines on major incident reporting under PSD2, UK payment services and operational resilience materials, and MAS technology risk and incident reporting materials. It also reflects regulatory frameworks under the EU Markets in Crypto-Assets Regulation (MiCA), the UK FCA Payment Services and Electronic Money regimes, Hong Kong's virtual asset service provider licensing regime, and the broader EU payment services framework (PSD3 and the Payment Services Regulation (PSR))

The RI-4 standard considers whether firms that are authorised, regulated or supervised in the financial services sector are subject to a clear, binding and proportionate framework for reporting material ICT-related, cyber, security and operational incidents to the relevant authority, so that the regulator receives early, useful and sufficiently precise information about material incidents, without unduly burdening the firm’s operational processes for monitoring and identifying such incidents. The key difficulty is designing a system that is clear and stringent enough to be followed, but flexible enough to apply proportionately depending on the size, complexity, business model and risk profile of the firm.

Scores should be assigned holistically by reference to the criteria for each component. The criteria are not a numerical checklist and should not be averaged mechanically. A strong performance on one element should not compensate for the absence of a fundamental feature of an incident reporting regime.

Core Criteria. A framework should contain the following core criteria:

Scope of the framework: the framework applies to a broad set of firms that are authorised, regulated or supervised in the financial services sector, and captures a broad and non-exhaustive set of material ICT-related, cyber, security and operational incidents affecting the firm, its customers, its regulated services, or the wider financial system. This should include incidents involving outsourced, cloud, technology, infrastructure or other third-party services where they materially affect, or are reasonably likely to materially affect, the firm, its customers, its regulated services, or the wider financial system. The definition of reportable incident must be functional and non-exhaustive. Materiality and impact assessment: the framework contains proportionate materiality thresholds that assess both the nature of the reporting firm and the impact of the incident. This assessment must take account of the size, complexity, business model and risk profile of the firm, the criticality of the affected service, and the possible impact on customers, counterparties, market confidence or the wider financial infrastructure. Reporting process and content: the framework requires staged reporting with defined timelines. It must identify when the reporting clock starts, what information must be provided at each stage, and the reporting channel or authority to which the report must be submitted. Post incident review: Firms must review the incident, identify root causes and weaknesses, implement corrective and preventive measures, keep the relevant authority updated where required, and use lessons learned to strengthen their wider resilience arrangements. This should include appropriate senior management accountability and, where relevant, incidents involving outsourced, cloud, technology, infrastructure or other third-party services. The framework gives the competent authority power to request further information, challenge classification decisions, require or supervise remediation, and take appropriate supervisory or enforcement action where reporting obligations are breached or incidents reveal material weaknesses in the firm's risk management or operational resilience. It should also be supported by implementation materials or supervisory practice, such as templates, portal guidance, FAQs, supervisory guidance, statistics, thematic reviews or enforcement evidence.

The minimum content requirement should be proportionate to the reporting stage. Initial notifications may be based on information known or reasonably estimable at the time, while follow-up updates and final reports should provide more complete information as it becomes available.

Component A: Scope of the Framework

The framework must define both who is required to report and what must be reported.

The reporting obligation must apply to a broad set of firms that are authorised, regulated or supervised in the financial services sector. The standard should not depend on local labels or terms of art. It should not distinguish between traditional and digital firms where both provide technology-dependent financial services.

The framework must use a non-exhaustive, functional definition of reportable incidents. Reportability should be determined by reference to the effect of the incident, not by a closed list of event types.

A reportable incident is an ICT-related, cyber, security or operational event that has, or is reasonably likely to have, a material adverse effect on one or more of the following, in respect of the firm or the wider financial system:

availability of regulated financial services; continuity of critical or important business services; integrity of transactions, records, systems or data; confidentiality of customer, transaction or authentication data; safety of customer funds, assets or balances; ability of the firm or another relevant market participant to meet legal, regulatory, settlement or payment obligations; market confidence, consumer protection or financial stability.

Incidents involving outsourced, cloud, technology, infrastructure or other third-party services must be covered where they materially affect, or are reasonably likely to materially affect, regulated services, customers, transactions, data, funds, assets or the wider financial system. The reporting obligation should not depend on whether the incident began inside the firm or inside a third-party provider.

Component B:

Materiality and Impact Assessment. The framework must contain thresholds that allow firms to determine whether an incident is reportable. The thresholds must be clear enough to apply, but flexible enough to avoid over-reporting and to capture incidents whose significance comes from the role of the affected service in the wider financial system.

The framework must cover assessment of both:

the nature of the reporting firm, including its size, complexity, business model and risk profile; and the impact of the incident, including the importance of the affected service to the firm, its customers, counterparties, other market participants and the wider financial infrastructure.

The framework should require firms to assess the impact of an incident in a way that captures the following categories in substance:

Customer and user impact: the number or proportion of customers, clients or users affected, including the nature and severity of harm caused or likely to be caused. Service disruption and duration: the duration of the disruption or degradation, and the impact on the availability or continuity of critical or important services, functions or systems. Transaction and financial impact: the value or volume of transactions affected, including failed, delayed, erroneous or unauthorised transactions. Security, data and asset impact: unauthorised access to systems or networks; loss, compromise, corruption or unavailability of data; or compromise or suspected compromise of customer funds, assets, balances or credentials. Third-party and operational dependency impact: involvement of outsourced, cloud, technology, infrastructure or other third-party services, where that involvement materially affects the firm, its customers, regulated services or the wider financial system. Wider financial-system impact: geographic or cross-border impact, consumer protection impact, market confidence, financial stability, reputational impact, or impact on another relevant market participant.

An incident should be reportable where it has, or is reasonably likely to have, a material adverse effect in relation to one or more of the impact categories listed above.

Materiality should be assessed by reference to proportionate thresholds that combine, as appropriate:t

relative measures, such as the proportion of customers affected, proportion of transaction volume or value affected, proportion of critical services disrupted, severity ratings, criticality ratings or other measures assessing impact relative to the firm, the affected service or the wider financial system; absolute measures, such as the number of customers affected, duration of outage or service degradation, value or volume of transactions affected, number of failed or delayed transactions, or number of accounts, balances or systems affected; and qualitative factors, such as the sensitivity of data affected, compromise of customer funds, assets, balances or credentials, unauthorised access to systems, inability to meet regulatory, settlement or payment obligations, impact on a critical or important service, cross-border impact, market confidence, consumer protection or financial stability.

Those thresholds should be calibrated to the size, complexity, business model and risk profile of the firm, the criticality of the affected service, and the size, structure and complexity of the local financial system.

The mere engagement of one impact category should not automatically make an incident reportable. The question is whether the effect is material, assessed in context. However, an incident may still be material and reportable even if its impact appears limited when assessed by one measure, where the affected customer, data, service, asset or dependency is critical, or where the incident reveals a wider vulnerability. The framework must require the firm to document its classification decision, including the facts considered and the reason why the incident was or was not reportable.

Note:

Where a jurisdiction has separate incident reporting frameworks for different categories of regulated financial institutions, each applicable framework should be assessed in its own context, while the overall scoring should reflect the coherence, consistency, and completeness of the jurisdiction's incident reporting regime as a whole. Material gaps or inconsistencies between sectoral frameworks should reduce the overall assessment and should not be offset by stronger requirements in another sector.

Component C:

Reporting Process, Timelines, Content and Channels. The reporting process must include:

Initial notification: required when the firm has reasonable grounds to believe that a reportable incident has occurred or may be occurring. The initial notification must be made within a defined period and should contain the information reasonably available at the time. Follow-up update: required where there is a material change in the facts, impact, severity, affected services, third-party involvement, containment status or expected resolution. Final report: required after the incident is resolved or stabilised. It must contain root cause, actual impact, remediation, corrective and preventive measures, and lessons learned.

The framework must specify when the reporting clock starts. Acceptable triggers include awareness of the incident, reasonable grounds to believe the incident may be reportable, or formal classification as reportable. The trigger must be clear enough for firms to apply.

The framework must designate the reporting authority or channel in advance. This may be a supervisory portal, secure email address, incident reporting form, hotline or other specified mechanism.

Where more than one authority may have an interest in an incident, the framework should clarify the reporting route or interaction between obligations. This may include identifying the primary financial-sector reporting authority, explaining whether notification to one authority satisfies or is separate from notification to another, clarifying which timeline applies where obligations overlap, or providing for inter-authority coordination or information sharing.

The framework should prescribe the minimum content of incident reports. This means the core information that a firm must provide to the authority at each reporting stage, so far as known or reasonably estimable at the time, to allow the authority to understand the nature, severity, impact and status of the incident.

Minimum content should cover, in substance:

Firm and contact details: the reporting firm, responsible contact point and relevant internal reference details. Timing and status: when the incident was detected, classified and reported, and whether it is ongoing, contained, resolved or under investigation. Incident description: the nature of the incident, affected services, systems or business functions, and known or suspected cause where available. Impact assessment: known or estimated impact on customers, transactions, data, funds, assets, services, third parties or the wider financial system. Response and remediation: containment steps, remediation measures, communications made or planned, root cause where known, corrective measures and lessons learned.

Indicator-level anchor

No mandatory incident reporting framework exists for firms authorised, regulated or supervised in the financial services sector.

Component A

Scope of the Framework: no incident reporting framework exists.

Component B

Materiality and Impact Assessment: no incident reporting framework exists, or the framework contains no materiality threshold or impact assessment.

Component C

Reporting Process, Timelines, Content and Channels: no incident reporting framework exists, or the framework contains no defined reporting process.

An incident reporting framework exists, but it is not workable. It applies only to a narrow set of firms or incidents, reportable incidents are undefined or described only as “significant”, “material” or “serious”, timelines are absent or expressed only as “promptly” or “without delay”, or no reporting channel is identified.

Scope of the Framework: the framework applies only to a narrow set of firms or a narrow set of incidents, or uses undefined terms such as “significant incident” or “serious incident” without further criteria.

Materiality and Impact Assessment: the framework uses only undefined terms such as “material”, “significant” or “serious”, or uses a narrow or mechanical threshold that does not allow firms to assess the nature of the firm, the affected service or the impact of the incident.

Reporting Process, Timelines, Content and Channels: reporting is required only in general terms, such as “promptly”, “immediately” or “without undue delay”, with no defined deadline, clock-start point, reporting authority or minimum content requirement.

Binding incident reporting rules apply to a broad set of firms authorised, regulated or supervised in the financial services sector and include defined reportable-event triggers, a stated initial notification timeline, an identifiable reporting authority or channel, and some materiality or severity guidance. However, one or more important elements remains incomplete, such as proportional thresholds, staged reporting, third-party incident treatment, multi-authority coordination, supervisory follow-up powers or operational evidence.

Scope of the Framework: the framework covers a broad set of firms and a broad set of incidents, and includes defined criteria for reportability, but the criteria are not clearly proportionate to the firm’s size, complexity, business model, risk profile or role in the wider financial system.

Materiality and Impact Assessment: the framework includes defined materiality thresholds or impact criteria, but the assessment is incomplete, overly mechanical, insufficiently calibrated to the firm or local financial system, or does not adequately capture the potential impact on customers, regulated services, other market participants or the wider financial system.

Reporting Process, Timelines, Content and Channels: the framework includes a defined initial notification deadline and identifies a reporting authority or channel, but the process is incomplete. For example, it lacks staged reporting, does not specify when the reporting clock starts, gives limited guidance on report content, does not clearly require updates or final reporting, or does not address overlapping reporting obligations where these are likely to arise.

A comprehensive and operational incident reporting regime is in place. Binding requirements meet the RI-4 core criteria: broad incident and entity scope, proportional materiality thresholds calibrated to the firm and to the local financial system, mandatory impact-factor assessment, staged reporting, defined timelines, designated reporting channels, third-party incident treatment, supervisory follow-up powers and evidence of operational implementation.

Scope of the Framework: the framework applies broadly to relevant firms authorised, regulated or supervised in the financial services sector across all firms, covers a broad and non-exhaustive list of incidents, and applies reportability criteria proportionately by reference to the firm, the affected service and the potential impact on the wider financial system.

Materiality and Impact Assessment: the framework contains proportionate materiality thresholds and an impact assessment that captures the relevant impact categories in substance; assesses materiality by reference to the firm, the affected service and the wider financial system; uses, or is capable of taking into account, relative measures, absolute measures and qualitative factors; calibrates thresholds to the local financial system; avoids automatic reportability based on the mere engagement of a category.

Reporting Process, Timelines, Content and Channels: the framework provides a clear staged reporting process, including initial notification and follow-up updates or final reporting; specifies defined timelines and a clear clock-start point; designates the reporting authority or channel; prescribes minimum report content sufficient for the authority to assess the nature, severity, impact and status of the incident; clarifies the reporting route or interaction between obligations where more than one authority may be relevant; and allows information to be supplemented as it becomes available.

Primary sources to consult. Incident reporting regulations or circulars; financial services rules; banking, payments, lending, investment, market infrastructure, crypto-asset or other sectoral financial services rules; operational resilience rules; cyber or ICT risk-management rules; technology risk guidelines; official incident classification guidance; reporting forms, portals, templates or FAQs. The review should not be limited to bank-sector regulations and rules but should cover those designed specifically for non-bank and digital financial service providers, where applicable.

Scoring note. Score clarity, proportionality and usability. Do not score based on the shortest reporting deadline. A 72-hour timeline with clear thresholds and reporting mechanics is better than a 24-hour rule that leaves firms uncertain about whether an incident is reportable.

Component-based

Scores should be assigned holistically by reference to the criteria for each component. The criteria are not a numerical checklist and should not be averaged mechanically. A strong performance on one element should not compensate for the absence of a fundamental feature.

RI-5

Resilience Testing and Assurance Expectations

RI-5 assesses whether a jurisdiction's fintech-relevant regulatory framework requires regulated entities to validate their resilience and security arrangements through testing, and whether the results of that testing are subject to independent assurance and supervisory use.

The distinction from RI-1 is one of design versus proof. RI-1 assesses whether a jurisdiction requires entities to have resilience arrangements (governance, continuity plans, recovery objectives, dependency maps). RI-5 assesses whether a jurisdiction requires anyone to demonstrate that those arrangements actually work, and whether the resulting evidence reaches the board and the supervisor. A jurisdiction can score well on RI-1 with a framework that has never been exercised. RI-5 is the indicator that detects this.

As described further below, RI-5 is comprised of three sub-dimensions:

Testing Obligation and Coverage. A binding obligation to test exists, spans the distinct testing types needed to validate resilience, extends to third-party-supported services, and reaches non-bank fintechs (RI-5A); Proportionality and Calibration. The depth, type and frequency of testing scale with the entity's size, complexity and criticality, with a defined floor for smaller entities and a documented rationale where advanced testing is not required (RI-5B); and Assurance, Independence and Supervisory Use. Test results are independently validated, escalated to the board, tracked to remediation, and available to and used by the supervisor (RI-5C).

The goal of RI-5 is to evaluate whether testing happens, whether it is calibrated sensibly, and whether anyone acts on the results.

Written to international standard-setters, not to leading jurisdictions. The standard is drafted by reference to the international frameworks listed below. Named national testing regimes are used only as illustrations of how a requirement can be met, never as the requirement itself.

Terminology-neutral. Testing regimes are labelled differently across markets — threat-led penetration testing, intelligence-led red teaming, adversarial attack simulation, scenario testing, cyber drills, disaster recovery exercises. Scorers assess the function performed, not the label used, and do not mark a jurisdiction down for using different terminology or for drafting in a language other than English. Technology- and method-neutral. The standard takes no position on testing methodology, tooling, or whether testing is performed internally, by industry-coordinated exercise, or by external providers, provided the independence condition in RI-5C is satisfied. Proportionality is scored, not assumed. A smaller or less-mature market whose testing regime is appropriate to the entities actually operating in it is not marked down for omitting requirements that are not relevant to it, provided the regulator's rationale is documented. Absence of a requirement is not the same as a proportionate decision not to impose one. See the Proportionality Evidence Rule below.

A jurisdiction meets the RI-5 standard where its financial-sector framework requires regulated entities to maintain:

a binding, periodic testing programme covering recovery and continuity capability, technical security controls, and end-to-end scenario response; testing that extends to critical services delivered through or dependent on third parties, irrespective of whether the entity owns the underlying infrastructure; calibration of testing type, depth and frequency to the entity's size, complexity, business model, risk profile and the criticality of the service tested, with any exemption from advanced testing documented and risk-based; an independence condition ensuring that those who validate or assess results are functionally separate from those who own the systems and controls tested; escalation of results to the board or senior management, with identified weaknesses tracked to documented remediation and re-testing; and supervisory visibility and challenge, the supervisor can obtain, review and act on testing outcomes,

With the foregoing applying consistently across core fintech models (at minimum PSPs and e-money institutions, and including digital lenders and CASPs where permitted) and with any exclusion explicitly risk-based and documented.

RI-5A: Testing Obligation and Coverage — Assesses whether a binding obligation to test exists; whether it spans the three functionally distinct testing types (recovery/continuity validation, technical security and vulnerability testing, and end-to-end scenario or simulation exercises); whether it reaches critical services delivered through third parties; and whether it applies to non-bank fintechs rather than prudential institutions alone. RI-5B: Proportionality and Calibration — Assesses whether testing type, depth and frequency scale with entity size, complexity, business model, risk profile and service criticality; whether a defined baseline applies to smaller entities rather than exempting them entirely; and whether any exemption from advanced testing rests on documented, risk-based criteria rather than silence. RI-5C: Assurance, Independence and Supervisory Use — Assesses whether results are subject to independent validation; whether they are escalated to the board or senior management; whether findings are tracked to documented remediation and re-testing; and whether the supervisor can obtain, review and challenge testing outcomes, with evidence that it does.

Testing Types. (RI-5A)

Frameworks label these differently, and scorers assess function rather than nomenclature. A framework need not use three separate instruments, but it must address three functionally distinct questions:

Recovery and continuity validation — can the entity actually restore service within its stated objectives? Exercises of continuity and disaster recovery plans, failover testing, restoration testing against declared RTOs/RPOs. Technical security and vulnerability testing — do the controls hold? Vulnerability assessment, penetration testing, control effectiveness testing. End-to-end scenario or simulation exercise — does the organisation respond? Severe-but-plausible scenario testing, tabletop and live simulation, adversarial or threat-informed exercises, industry-coordinated drills. This is the type most frequently absent; a framework requiring only (1) and (2) is testing components, not resilience.

Forward-Looking Statement on AI-Assisted Operations and Post-Quantum Readiness Testing

The following are recorded as items for observation and future index development, rather than scored directly in the current version, as most domestic frameworks have not yet codified specific testing rules for these emerging risks:

Testing of AI and agentic system failure modes: Framework tracking evaluates whether testing programmes extend to autonomous or AI-assisted operational processes, including whether scenario exercises are required to cover model failure, agentic execution loops, degraded-mode operation on fallback to manual processes, and validation of human-override and circuit-breaker controls. A framework may require testing of AI-supported services under existing critical-service definitions without addressing AI-specific failure modes; this should be recorded as a coverage observation rather than scored. Post-quantum migration and cryptographic-agility testing: Framework tracking evaluates whether resilience testing expectations require entities to validate the accuracy of their cryptographic inventory and to exercise migration and rollback pathways for core clearing, messaging and authentication architectures, rather than treating post-quantum transition solely as a planning exercise.

No testing or assurance expectations directed at financial entities exist in published law, regulation, or binding supervisory instruments; or provisions are so ambiguous that a regulated entity cannot determine whether, what, or how often it must test. Entity-coverage test: No instrument references non-bank fintechs.

RI-5A

Testing Obligation and Coverage: No testing or assurance expectations directed at financial entities exist in published instruments; or a requirement is stated so ambiguously (e.g. that plans should be "kept up to date") that an entity cannot determine whether, what, or how often it must test.

RI-5B

Proportionality and Calibration: No framework exists; or testing obligations apply uniformly with no recognition, at any evidence level, that testing needs differ by entity or by service criticality.

RI-5C

Assurance, Independence and Supervisory Use: No requirements address what happens to test results; testing is required (if at all) with no stated consequence, reporting line, or follow-up.

No evidence found in Levels 1–4.

No regulated fintech provider is subject to resilience testing requirements.

No assurance that continuity, recovery or security arrangements have ever been validated.

Testing is encouraged or voluntary, appears only in Level 4 guidance, or rests on an industry-association framework the regulator has not mandated; or a binding obligation exists but covers only one testing type, typically continuity plan review. Assurance requirements are absent or limited to documentation and retention. Entity-coverage test: Requirements do not clearly reach non-bank fintechs, or reach them only by generic, uncodified reference.

Testing Obligation and Coverage: Testing is encouraged, voluntary, or addressed only in Level 4 guidance or an industry-association framework the regulator has not mandated; or a binding obligation exists but covers only one testing type (typically continuity plan review); or the obligation is drafted for prudential institutions and reaches non-bank fintechs only by generic or uncodified extension.

Proportionality and Calibration: Proportionality is referenced only in general terms (a bare "risk-based approach" statement) without articulating calibration factors or how obligations scale; or calibration appears only in Level 4 guidance; or proportionality operates in practice as a blanket exemption: smaller entities are carved out with no baseline obligation at all.

Assurance, Independence and Supervisory Use: Results must be "documented" or "retained" with no independence condition, no escalation route, and no remediation obligation; or assurance expectations appear only in Level 4 guidance; or the supervisor has no stated route to obtain or review testing outcomes.

Evidence only in Level 4, in an unmandated industry framework, or limited Level 1–3 provisions applying to banks or via generic reference.

Applies only to traditional banks and prudential institutions, excluding most non-bank fintechs.

Some entities test voluntarily, but coverage is fragmented, testing types are narrow, and results carry no consequence.

Binding requirements (Levels 1–3) impose periodic testing reaching at minimum PSPs and e-money institutions by name or clear functional definition, identify calibration factors, and establish board escalation and an obligation to remediate identified weaknesses. At least one significant gap remains: one of the three testing types is absent, most commonly end-to-end scenario or simulation exercise; testing of third-party-supported critical services is unaddressed; no independence condition attaches to validation; supervisory access to results is uncodified; or there is no verifiable operationalization record.

Testing Obligation and Coverage: A binding obligation (Levels 1–3) requires periodic testing and reaches at minimum PSPs and e-money institutions by name or clear functional definition. At least one of the following gaps remains: one of the three testing types is absent (most commonly end-to-end scenario or simulation exercise); testing of third-party-supported critical services is unaddressed; or one or more fintech categories is excluded without a documented risk-based rationale.

The framework identifies calibration factors (size, complexity, business model, risk profile, service criticality) and scales at least one dimension of testing (type, depth, or frequency) accordingly. A defined baseline applies to smaller entities. At least one of the following gaps remains: calibration factors are identified but no guidance is given on how obligations scale in practice; calibration exists only for frequency and not for testing type or depth; or exemptions from advanced testing are available without documented criteria.

Binding requirements establish an escalation route to the board or senior management and an obligation to remediate identified weaknesses. At least one of the following gaps remains: no independence condition attaches to validation or testing; re-testing of remediated weaknesses is not required; the supervisor's access to results is not codified; or no operationalization record exists (see Cap 2).

Binding requirements in Levels 1–3 exist, but are incomplete in testing coverage, calibration, independence, supervisory access, or operationalization record.

Regulated fintechs test periodically and escalate findings, but gaps remain in scenario response, third-party dependency testing, or independent challenge of results.

Binding requirements (Levels 1–3) establish all of: (i) periodic testing across all three testing types; (ii) express extension to critical services delivered through or dependent on third parties; (iii) calibration of testing type, depth and frequency to articulated entity- and service-level factors, with a baseline obligation retained for smaller entities; (iv) an independence condition separating validators from system and control owners; (v) board or senior-management escalation with remediation tracked to closure and re-testing; and (vi) codified supervisory access, review and challenge.

Operationalization requirement

A published thematic review, supervisory finding, coordinated sector exercise, or enforcement action demonstrating application to fintech resilience testing is required.

Testing Obligation and Coverage: Binding obligations (Levels 1–3) address all three testing types, expressly extend to critical services delivered through or dependent on third parties, and apply consistently across core fintech models, with any exclusion explicitly risk-based and documented.

Proportionality and Calibration: Calibration operates as a core principle across the testing framework: type, depth and frequency all scale by reference to articulated entity- and service-level factors; a baseline obligation applies to all in-scope entities regardless of size; and any exemption from advanced testing rests on published, risk-based criteria.

Assurance, Independence and Supervisory Use: Binding requirements establish all of: an independence condition separating validators from system and control owners; board or senior-management escalation; documented remediation tracked to closure with re-testing; and codified supervisory access, review and challenge powers. Supported by a verifiable operationalization record (see Cap 2).

Comprehensive, enforceable requirements in Levels 1–3, supported by an independence condition, codified supervisory access, and a verifiable operationalization record.

Regulated fintechs routinely validate resilience across recovery, security and scenario response, with independently assured results driving tracked remediation and supervisory challenge.

Evidence Tiers. Score using publicly verifiable primary sources, classified by legal force and effect (i.e., does a failure to comply result in liability).

Primary legislation: financial services acts, payment systems statutes, operational resilience legislation.

Binding subordinate legislation: regulations, technology risk standards, licensing conditions, mandatory notices.

Binding supervisory requirements: directives, enforceable circulars, binding supervisory handbooks, and codes incorporated by reference into regulation.

Non-binding guidance: guidance notes, best-practice papers, supervisory expectations, FAQs, and industry-association testing frameworks not mandated by the regulator.

Primary Sources to Consult. Supervisory handbooks; technology and ICT risk management guidelines; business continuity and operational resilience rulebooks; cyber resilience circulars; testing and assurance frameworks issued or mandated by the financial regulator; internal audit requirements; licensing conditions; published thematic reviews of testing outcomes.

The following international frameworks were utilised in drafting this standard:

Basel Committee on Banking Supervision (BCBS): Principles for Operational Resilience (March 2021), particularly on scenario testing of severe-but-plausible disruptions; Principles for the Sound Management of Operational Risk. Financial Stability Board (FSB): Effective Practices for Cyber Incident Response and Recovery, on testing and exercising response capability; Cyber Lexicon. CPMI–IOSCO: Guidance on Cyber Resilience for Financial Market Infrastructures, on testing programmes and the role of independent assurance. G7 Cyber Expert Group: Fundamental Elements for Threat-Led Penetration Testing; Fundamental Elements of Cybersecurity for the Financial Sector. European Union: Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, Chapter IV (Articles 24–27), covering testing programme requirements, testing of ICT tools and systems, advanced testing based on threat-led penetration testing, and requirements for testers. Referenced for structure; the standard is drafted to apply beyond DORA jurisdictions. NIST: Cybersecurity Framework 2.0 (Identify, Protect and Detect functions as they bear on control validation).

Illustrative national and industry testing frameworks, for calibration reference only and not as scoring benchmarks: TIBER-EU; UK CBEST; Singapore's adversarial attack simulation exercise guidelines; Hong Kong's iCAST; Saudi Arabia's FEER. Several of these are voluntary or industry-issued and would engage Cap 1 where not mandated by the regulator — the presence of a well-known testing framework in a jurisdiction is not by itself evidence of a binding obligation.

Scoring note. Do not require all three at maximum intensity for every entity. Require that the framework addresses all three and calibrates them under RI-5B. A framework silent on scenario response caps at 2 on RI-5A regardless of how detailed its penetration testing requirements are. Scoring notes. The RI-5 indicator score is the highest band whose conditions are met, subject to the caps below. Add the score from all sub-dimensions and assign the jurisdiction a Band.

Band 3: The combined score is greater than or equal to 8 and a verifiable operationalization record exists (see Cap 2 below). For example: RI-5A = 3; RI-5B = 3; RI-5C = 2 or above. Band 2: The combined score is between 5 and 7, or the combined score is 8 or higher but no verifiable operationalization record exists. For example: RI-5A = 2; RI-5B = 2; RI-5C = 1 or above. Band 1: The combined score is between 1 and 4. Testing requirements exist in a published instrument, but the Band 2 conditions are not met (including because requirements apply to fintechs only by generic reference). Band 0: Absent — all three sub-dimensions score 0.

Sub-dimension scores should not be averaged. Where a jurisdiction scores below Band 3, record the specific rubric trigger not met, the binding sub-dimension, and any cap that applied. Consistent with the RI-4 approach, strong performance on one sub-dimension does not compensate for the absence of a fundamental feature of a testing regime: a framework with sophisticated penetration testing requirements but no assurance or supervisory loop is not a mature testing regime.

Component-Cap 1: Binding Instrument Requirementbased

Testing expectations resting solely on Level 4 guidance, or on an industry-association testing framework that the regulator has referenced but not mandated, cap the relevant sub-dimension at 1 (Emerging). This mirrors the Reference-versus-Mandate Rule under RI-1 and is particularly consequential for RI-5, because several major markets locate their most sophisticated testing methodologies in voluntary or industry-led frameworks. The sophistication of a methodology is irrelevant where compliance with it is optional.

Cap 2: Operationalization Requirement for a 3

A score of 3 on RI-5C requires evidence that the assurance loop has been used in practice: a published thematic review of testing outcomes, supervisory findings on testing quality, a coordinated sector-wide exercise the supervisor convened or reported on, or enforcement action arising from testing failures. Actions directed solely at traditional banking organisations do not count; actions or reviews covering digital banks or other in-scope fintech categories do. A framework that is comprehensive on paper with no verifiable record of use should receive a score of 2.

Proportionality Evidence Rule

A jurisdiction that has deliberately calibrated its testing regime to the entities present in its market, and can point to a published rationale, scores as a proportionate framework. A jurisdiction that has simply not addressed advanced testing scores as a gap. The two are indistinguishable from the absence of a requirement alone; they are distinguishable by the presence of a documented regulatory rationale — a consultation response, policy statement, explanatory memorandum, licensing framework, or supervisory publication explaining the calibration decision.

Where a jurisdiction has no entities of the scale or criticality that would warrant advanced adversarial testing, and says so in a published instrument, RI-5B is scored on the calibration logic rather than on the presence of the omitted requirement. Where the record is silent, score the gap and document that no rationale was located.

Note for Working Group discussion: this rule may be worth generalising across the pillar. It addresses the same difficulty raised in relation to emergent regulatory frameworks under RI-3, and gives scorers an evidentiary test rather than a judgement call.

For each sub-dimension, ask whether the binding instrument reaches in-scope entities (PSPs, e-money institutions, digital banks, digital lenders, and CASPs where permitted) specifically and by name or clear functional definition, rather than by generic extension of bank rules, and record which provider category forms the binding constraint on the score. Digital banks are adequately covered where the banking regime applies to them by charter or licence.

Scoring note specific to RI-5: testing obligations are unusually prone to entity-coverage failure, because advanced testing regimes are frequently scoped by systemic-importance thresholds calibrated to bank balance sheets. A threshold that no domestic fintech could realistically cross should be recorded as an effective exclusion of the fintech sector, and the rationale (or its absence) assessed under RI-5B.

Multi-Regulator Convention

Testing obligations are frequently split between a financial regulator and a national cyber authority, and in some markets the operative methodology sits with an industry association. Assess the dominant applicable framework for the entity category being tested and document which regime was scored. Where a national cyber authority imposes testing obligations on financial entities that the financial regulator does not, score the consolidated framework and note the coordination gap. Unexplained fragmentation is a gap under the rubric.

Cross-pillar boundary note

Boundary Notes

RI-5 is drafted to sit alongside the adjacent indicators, and scorers should not double-count:

RI-1 (Operational Resilience Baseline). The existence of BCP/DR frameworks, RTOs/RPOs, critical service mapping and governance accountability is scored under RI-1. The requirement to exercise, validate and evidence those arrangements is scored here. RI-1 Component E carries a reciprocal boundary note offloading threat-led testing, vulnerability scanning and live simulation to RI-5. RI-2 (Cybersecurity Governance and Controls). The specification of a minimum control baseline is scored under RI-2. The requirement to test whether those controls hold under adversarial conditions is scored here. RI-3 (Third-Party Risk). Contractual audit and access rights, exit planning and concentration risk sit under RI-3. Whether the testing regime reaches into third-party-supported critical services; including the entity's right and obligation to test dependencies it does not own is scored here. RI-4 (Incident Reporting). Reporting of actual incidents sits under RI-4. Testing against simulated incidents sits here. Where a framework requires post-incident lessons learned to feed the testing programme, score the reporting obligation under RI-4 and the testing feedback loop under RI-5C.

Sub-dimension anchors

The indicator also carries anchors written per sub-dimension; each score cell holds one labelled block for each.

The same score is also rated on three further 0–3 scales — evidence, applicability and outcome-based. All sit together in each score cell, each under its own label.

RI-5 assesses whether a jurisdiction's fintech-relevant regulatory framework requires regulated entities to validate their resilience and security arrangements through testing, and whether the results of that testing are subject to independent assurance and supervisory use. The distinction from RI-1 is one of design versus proof. RI-1 assesses whether a jurisdiction requires entities to have resilience arrangements (governance, continuity plans, recovery objectives, dependency maps). RI-5 assesses whether a jurisdiction requires anyone to demonstrate that those arrangements actually work, and whether the resulting evidence reaches the board and the supervisor. A jurisdiction can score well on RI-1 with a framework that has never been exercised. RI-5 is the indicator that detects this. As described further below, RI-5 is comprised of three sub-dimensions: - Testing Obligation and Coverage. A binding obligation to test exists, spans the distinct testing types needed to validate resilience, extends to third-party-supported services, and reaches non-bank fintechs (RI-5A); - Proportionality and Calibration. The depth, type and frequency of testing scale with the entity's size, complexity and criticality, with a defined floor for smaller entities and a documented rationale where advanced testing is not required (RI-5B); and - Assurance, Independence and Supervisory Use. Test results are independently validated, escalated to the board, tracked to remediation, and available to and used by the supervisor (RI-5C). The goal of RI-5 is to evaluate whether testing happens, whether it is calibrated sensibly, and whether anyone acts on the results.

RI-6

AML/CFT Clarity for Digital Onboarding and Fintech Models

Whether an AML/CFT compliance framework clearly addresses the obligations of fintech entities for remote and digital customer onboarding (including CDD, eKYC, and digital identity acceptance), ongoing monitoring, suspicious transaction reporting, and the travel rule where applicable; whether supervisory guidance addresses fintech business model typologies; and whether law enforcement participates in real-time information-sharing and interdiction mechanisms alongside regulated entities.

The standard is written by reference to FATF as the primary international AML/CFT standard-setter, supplemented by IOSCO, BIS/CPMI, and FSB material where they address payment-system or market-infrastructure dimensions of digital finance. Jurisdictions are used only to validate and refine the standard at this stage rather than to score jurisdictions directly.

Technology-neutral and business-model-neutral

The standard asks whether a jurisdiction's AML/CFT framework gives fintech entities a clear, usable answer to their obligations for digital onboarding, ongoing monitoring, suspicious transaction reporting, and travel rule compliance. It takes no position on any specific onboarding technology, digital ID architecture, or messaging standard. Where a framework is silent on a novel onboarding method or asset class, that silence is a coverage gap, not a defect in the underlying policy stance.

A jurisdiction meets the RI-6 standard where its AML/CFT framework requires regulated fintech entities to maintain: (a) clear, risk-based rules for remote and digital customer identification and verification, including the conditions under which digital ID systems may be relied upon; (b) defined expectations for ongoing monitoring of digital-channel transactions; (c) suspicious transaction reporting obligations that are explicitly workable for digital and remote business models; (d) travel rule / payment-transparency obligations that clearly extend to virtual asset transfers and fintech payment chains, consistent with the revised FATF Recommendation 16; (e) supervisory guidance addressing fintech and VASP business-model typologies rather than only traditional bank models; (f) consistent applicability of the foregoing across core fintech models, with any exclusions explicitly risk-based and documented; and (g) participation by law enforcement in a real-time or near-real-time public-private partnership capable of interdicting illicit funds, alongside — not in place of — traditional STR-based reporting channels.

Component A: Digital and Remote CDD / eKYC Framework

The framework specifies when non-face-to-face identification and verification may be treated as standard or lower risk, rather than defaulting to enhanced due diligence for all remote onboarding. FATF's dedicated guidance in this space sets out that authorities and regulated entities should apply a risk-based approach to using digital ID systems for customer identification and verification, and clarifies that remote onboarding relying on reliable, independent digital ID systems with appropriate safeguards can present standard, or even lower, risk rather than automatically triggering enhanced scrutiny. The guidance is explicitly framed as supplementing Recommendation 10 on customer due diligence and Recommendation 17 on reliance on third parties, and covers both identity proofing at onboarding and the use of authentication for ongoing due diligence on the business relationship. A regulated entity that authenticates an existing customer through a digital ID system is encouraged to use the data generated by that authentication to support ongoing due diligence and transaction monitoring, not only fraud prevention. A jurisdiction scores well here where its own rules or guidance translate this FATF approach into binding or clearly enforceable expectations for PSPs, e-money institutions, and digital lenders — not only banks.

Component B: Ongoing Monitoring and STR Obligations for Digital Channels

The framework requires ongoing transaction monitoring calibrated to digital-channel risk indicators (device/IP data, behavioral anomalies, velocity patterns) and gives regulated fintechs a clear, workable trigger and process for filing suspicious transaction reports arising from digital or remote transactions. This component tracks FATF Recommendations 20 and 21 as applied to non-bank payment and virtual asset businesses. Because STR quality depends heavily on typology guidance, this component also asks whether the supervisor or FIU has published fintech- or VASP-specific red flags and case typologies, rather than leaving digital-channel STR filing to generic bank-oriented guidance.

Component C: Travel Rule / Payment Transparency Obligations

The framework requires the transmission of originator and beneficiary information with qualifying transfers, consistent with FATF Recommendation 16, and clearly states how this obligation applies to virtual asset transfers and VASPs.

FATF substantially revised Recommendation 16 at its June 2025 Plenary, with an October 2025 update publishing Annex IV to FATF's assessment methodology setting out how compliance with the revised standard will be assessed in mutual evaluations. Key substantive changes clarify which institution in a payment chain bears the initial data-collection responsibility: under the revised standard, the payment chain is treated as starting with the financial institution that receives the transfer instruction directly from the customer, with standardized information requirements applying from that point. The revisions are not self-executing — the revised requirements take effect by the end of 2030 and must still be adopted by individual jurisdictions.

On the virtual asset side specifically, implementation is real but uneven. In FATF's 2025 survey, 73% of responding jurisdictions — excluding those that prohibit or plan to prohibit VASP activity — reported having passed travel rule legislation. FATF has also clarified how the revised Recommendation 16 interacts with the VASP-specific framework: FATF has indicated it is not applying the travel rule directly to VASPs, but instead applying it to them indirectly through the tailored VASP framework, and has committed to publish further implementation guidance. A jurisdiction with published national guidance addressing the sunrise issue, messaging-standard interoperability, and threshold treatment should score above one that has legislated the rule but left these questions to individual firms.

Component D: Fintech and VASP Business-Model Typology Guidance

The framework — through the AML/CFT regulator, the FIU, or both — publishes guidance addressing fintech-specific business models (e-money issuance, payment initiation, digital lending, stablecoin issuance, VASP custody and exchange services) rather than treating all obligations as bank-rule extensions. This reflects FATF's continuing supervisory work tracking VASP and virtual-asset implementation globally, including its recurring targeted updates on Recommendation 15 compliance.

The requirements under Components A through D must sit in a binding or enforceable instrument, supported by a supervisory mechanism — examination, reporting, or an equivalent means of assessing compliance and taking corrective action. Non-binding FIU advisories alone do not satisfy this component.

Component F: Cross-Entity Applicability

Requirements apply consistently across PSPs, e-money institutions, digital lenders, and CASPs where permitted. Any exclusion of a provider category — including a full prohibition on VASP activity — is explicitly documented and risk-based, and the regulatory perimeter itself is clearly stated so that a firm can determine whether it is inside or outside scope.

Component G: Public-Private Partnership Membership and Real-Time Interdiction Capability

The framework supports, or the jurisdiction's law enforcement and financial intelligence authorities participate in, a public-private partnership capable of real-time or near-real-time information sharing between regulated fintechs/VASPs and law enforcement — not solely retrospective STR-based exchange through an FIU.

FATF has moved decisively toward endorsing this model. Its November 2025 guidance on virtual asset recovery promotes emerging public-private partnership models built for real-time crypto crime response, noting that these partnerships enable rapid information sharing between law enforcement and industry and accelerate the shift from detecting financial crime to disrupting it. In that same guidance, FATF pointed to specific operational examples of this model, citing the T3 Financial Crime Unit and TRM's Beacon Network as concrete illustrations of how public-private collaboration can function at operational speed, including T3's freeze of nearly USD 6 million connected to a pig-butchering scheme carried out with law enforcement across five continents. FATF has separately described T3 as a joint initiative among TRON, Tether, and TRM Labs that FATF recognized for its role in combating illicit activity across blockchain networks.

At its June 2026 Plenary, FATF approved a new global overview of public-private partnership models, finding at least 84 such partnerships operating worldwide, with more than 50 surveyed jurisdictions reporting at least one domestic PPP, and concluding that PPPs function as durable, effective tools against money laundering, terrorist financing, and proliferation financing when backed by a solid legal basis, clear governance, and real technological capability. FATF carried this work forward under the incoming UK Presidency, alongside a public consultation on new implementation guidance for the revised Recommendation 16.

A comparable government-anchored model exists in the US: the Illicit Virtual Asset Notification (IVAN) partnership brings together the FBI, US Secret Service, DEA, IRS Criminal Investigation, Army Criminal Investigation Division, US Postal Inspection Service, and the UK's National Crime Agency, alongside private-sector members, to share information on virtual-asset-enabled illicit activity and to identify and mitigate related threats. IVAN is described by its own board members as a global public-private partnership built specifically to let governments, law enforcement, and industry counter emerging criminal threats in real time.

No binding AML/CFT provisions address digital/remote onboarding, digital-channel STR, or the travel rule for fintech or virtual asset models; or provisions are too ambiguous for a regulated entity to determine its obligations. Entity-coverage test: no instrument reaches non-bank fintechs or VASPs.

No evidence in Levels 1–4 addressing digital onboarding or virtual asset travel rule.

No regulated fintech or VASP is subject to a stated obligation.

Firms cannot determine their digital-channel AML/CFT obligations; no assurance of consistent CDD, STR, or travel rule practice.

Partial rules exist — e.g., a general CDD obligation or a travel rule provision limited to traditional wire transfers — but at least one core element is missing: digital ID reliance conditions are unaddressed; VASP application of the travel rule is unaddressed or unclear; or fintech typology guidance does not exist. Requirements may rest only on Level 4 guidance.

Evidence only in Level 4, or limited Level 1–3 provisions applying to some entity types or via generic reference.

Applies only to banks or a single fintech category, excluding VASPs or most non-bank fintechs.

Some entities are covered, but fintech and virtual-asset business models operate with material uncertainty about digital onboarding and travel rule obligations.

Binding requirements (Levels 1–3) establish clear digital/remote CDD rules and a travel rule obligation that reaches VASPs, applying to most relevant fintech categories. At least one significant gap remains: e.g., no published fintech/VASP typology guidance; the jurisdiction has not begun transposing the 2025 Recommendation 16 revisions; sunrise-issue or messaging-interoperability treatment is unaddressed; or there is no verifiable operationalization record.

Binding requirements exist but are incomplete in digital ID reliance conditions, VASP travel rule specificity, or typology guidance.

Applies to several major fintech categories but excludes one or more significant categories (e.g., digital lenders, stablecoin issuers) without documented rationale.

Most regulated fintechs have workable digital CDD and travel rule obligations, but gaps in typology guidance or transition-readiness for the 2025 revisions create residual uncertainty.

Binding requirements establish all of: (i) risk-based digital ID / remote CDD rules consistent with FATF's digital identity guidance; (ii) ongoing monitoring and STR obligations explicitly workable for digital channels; (iii) a travel rule regime that clearly reaches VASPs and fintech payment chains, with a stated position on the 2025 Recommendation 16 revisions and the sunrise issue; (iv) published fintech/VASP typology guidance; (v) a supervisory review mechanism; and (vi) consistent, documented applicability across core fintech models, with any prohibition or exclusion clearly stated as a perimeter decision. A score of 3 also reflects Component G credit where a qualifying real-time PPP exists. Operationalization requirement: a published thematic review, typology report, or enforcement action addressing fintech/VASP AML/CFT compliance is required.

Comprehensive, binding requirements across CDD, STR, and travel rule, supported by published typology guidance and a verifiable operationalization record.

Applies consistently across PSPs, e-money institutions, digital lenders, and VASPs, with any prohibition or exclusion explicitly stated as a documented perimeter decision.

Regulated fintechs and VASPs can determine and meet their digital onboarding, STR, and travel rule obligations with confidence, subject to active supervisory oversight and (where applicable) law enforcement participation in real-time interdiction networks, producing predictable AML/CFT outcomes for digital financial services.

Primary Sources to Consult. AML/CFT legislation and regulations; FIU circulars and guidance; financial regulator AML guidance specific to fintech or digital channels; FATF Recommendations, Interpretive Notes, and Guidance documents.

Primary AML/CFT legislation.

Binding subordinate regulation — CDD rules, travel rule implementing regulations, VASP licensing conditions.

Binding supervisory instruments — FIU directives, enforceable circulars, mandatory typology reporting requirements.

Non-binding guidance — FIU advisories, supervisory FAQs, red-flag indicator papers. Entity-Coverage Test: For each requirement, ask whether the binding instrument reaches PSPs, e-money institutions, digital lenders, and VASPs by name or clear functional definition, rather than through generic extension of bank-oriented CDD rules. Record which provider category is the binding constraint on the score. Reference-versus-mandate Rule: Many jurisdictions reference FATF Recommendations or FATF guidance documents without transposing them into binding domestic obligations. A reference alone does not raise the score. Domestic transposition into binding CDD, STR, or travel rule rules is required for a score above 1. Travel Rule Currency Test: Given the active 2025–2030 transition period, scorers should record whether a jurisdiction's travel rule regime reflects the pre-2025 Recommendation 16 framework, has begun transposing the 2025 revisions, or remains silent on virtual assets entirely. A jurisdiction actively transposing the revised standard ahead of the 2030 deadline should not be penalized relative to one that has done nothing, even though both may currently be "compliant" with the un-revised text. Operationalization Requirement for a Score of 3: A top score requires evidence the framework has been applied in practice — a published FIU typology report addressing fintech/VASP models, a supervisory thematic review of digital onboarding or travel rule compliance, or an enforcement action — not merely the existence of the rule.

Scoring note. This indicator measures the clarity and coverage of obligations — not whether the AML/CFT regime is "strict" or produces good outcomes. A jurisdiction with proportionate, well-explained digital AML obligations scores as well as one with extensive but unclear requirements. Scoring criteria. To score under this component (Component G), a qualifying partnership should demonstrate: standing law enforcement membership — a defined seat and defined access rights for a police, cybercrime, or financial-crime authority, not an ad hoc liaison arrangement; real-time or near-real-time operating tempo — architected to move from a shared alert to a freeze, hold, or interdiction request while funds are still traceable and recoverable, not only after the fact; a documented legal basis for the sharing — data protection and tipping-off constraints addressed by statute, MOU, or regulatory gateway rather than informal practice; fintech and VASP inclusion, not banks alone. Scoring treatment: This is a modifier within RI-6 rather than a standalone weighted indicator. A jurisdiction otherwise scoring 2 elsewhere in RI-6 that also has law enforcement in a qualifying real-time PPP moves to 3. A jurisdiction otherwise scoring 3 without one does not move down — this is additive credit for a documented practice, not a penalty for its absence, since only a minority of surveyed jurisdictions currently report even one domestic PPP.

single integer score 0–3 on the main rubric.

RI-6 and RI-7 share a single 20% weighting in the source document. RI-6 and RI-7 share a combined 20% weight (RI module, Section 4).

The Resilience & Integrity pillar assesses whether a jurisdiction's fintech-relevant regulatory framework is designed to keep digital financial services safe, reliable, and trustworthy. It evaluates operational resilience expectations, cybersecurity governance, third-party and cloud risk controls, incident reporting requirements, and AML/CFT regime quality for digital channels — so that fintech innovation can scale without creating unacceptable systemic, consumer, or crime risks.

Draft international best-practice standard. A jurisdiction meets the RI-1 standard where its financial-sector framework requires regulated entities to maintain: - Board- and senior-management accountability for operational resilience and continuity; - Documented continuity frameworks integrated with either quantitative Recovery Time Objectives (RTOs) or defined impact tolerances for severe but plausible disruptions; - Identification and mapping of critical business functions/important business services, internal sub-processes, and external dependencies; and - Mechanisms for supervisory review and challenge, with all of the foregoing applying consistently across entities in scope.

Applies only to traditional banks/prudential institutions, excluding most non-bank fintechs.

Binding requirements (Levels 1-3) clear the Resolution Gate by establishing BOTH: 1. Explicit applicability extending directly to non-bank PSPs and e-money institutions; and 2. Binding operational minimums including C-suite/board governance accountability, mandatory BCP/DR frameworks, and defined numeric RTOs. At least one significant gap remains: critical service mapping is absent; supervisory review mechanisms are uncodified; or there is no verifiable operationalization record.

Binding requirements (Levels 1-3) clear the Resolution Gate by establishing BOTH: 1. Explicit applicability extending directly to non-bank PSPs and e-money institutions; and 2. Binding operational minimums including C-suite/board governance accountability, the identification of important business services, and the setting of defined impact tolerances for severe but plausible disruptions. At least one significant gap remains: end-to-end dependency mapping is absent; scenario testing expectations are uncodified; or there is no verifiable operationalization record.

Binding requirements (Levels 1-3) establish all of: (i) Explicit board/senior-management accountability; (ii) A mandate to ensure important business services can remain within defined impact tolerances under severe but plausible scenarios; (iii) Mandated resource and dependency mapping for all identified important business services; (iv) Interactive supervisory review and challenge mechanisms;< and (v) Explicit, consistent applicability across core non-bank fintech models. Operationalization requirement: A published supervisory thematic review, enforcement action, or public assessment demonstrating application to fintech operational resilience is required.

Two paths: rules-based and outcomes-based (principles)

Financial regulators frequently reference soft-law principles without mandating them. A reference alone or a non-binding guidance paper (Level 4) caps the score at 1 (Emerging). Transposition into binding domestic instruments (Levels 1-3) is required for a score of 2 or higher.

Direct — single integer score 0–3. The same score is also rated on three further 0–3 scales — evidence, applicability and outcome-based. All four sit together in each score cell, each under its own label.

Sub-dim B

Sub-dim D

Sub-dim E

AML/CFT and Integrity Controls for Digital Finance

Sub-dim F

RI-6 — AML/CFT and Integrity Controls for Digital Finance

Whether an AML/CFT compliance framework clearly addresses the obligations of fintech entities for remote and digital customer onboarding (including CDD, eKYC, and digital identity acceptance), ongoing monitoring, suspicious transaction reporting, and the travel rule where applicable; whether supervisory guidance addresses fintech business model typologies; and whether law enforcement participates in real-time information-sharing and interdiction mechanisms alongside regulated entities. Where crypto-asset service providers (CASPs) are permitted to operate, RI-6 also assesses whether the jurisdiction has a clear, binding, and implementable CASP integrity framework covering the regulatory perimeter, custody and safeguarding, client-asset segregation and insolvency protection, governance and conflicts of interest, and market-integrity requirements. CASP-specific cybersecurity and operational-resilience requirements are assessed only for scope/applicability here; their substantive content remains assessed under the relevant RI resilience and cybersecurity indicators.

No binding legal, regulatory, or supervisory framework meaningfully governs fintech or CASP/VASP activity. This includes the absence of clear AML/CFT requirements for digital or remote onboarding, digital-channel STR obligations, payment-transparency/travel-rule requirements, or a defined CASP regulatory perimeter. The framework is absent, materially incomplete, or so ambiguous that regulated entities cannot determine whether they are covered, what obligations apply, or whether the activity is permitted, prohibited, or left in an unaddressed gap. Ad hoc, informal, or unenforceable measures do not qualify as a sufficient framework. Entity-coverage test: No binding instrument clearly reaches non-bank fintechs, VASPs, or CASPs, or defines their regulatory status and applicable obligations.

No evidence in Levels 1–4 of binding provisions addressing digital onboarding, digital-channel AML/CFT obligations, virtual-asset travel-rule requirements, or a regulatory framework applicable to CASPs.

No regulated fintech, VASP, or CASP is subject to a clearly stated and enforceable set of obligations; the regulatory perimeter is absent, undefined, or materially ambiguous.

Firms cannot reliably determine their digital-channel AML/CFT obligations, creating no assurance of consistent CDD, STR, payment-transparency, or travel-rule practices. Users of crypto-asset services likewise lack predictable protection against custody failures, asset misappropriation, market manipulation, or insolvency-related loss, including assurance that client assets are segregated and recoverable.

Partial legal, regulatory, or supervisory requirements exist, but material gaps, uncertainty, or fragmented coverage remain. For fintech AML/CFT, this may include a general CDD obligation or payment-transparency/travel-rule provision that does not clearly address digital or remote onboarding, digital-ID reliance conditions, digital-channel STR obligations, VASP/CASP application of the travel rule, or fintech-specific typologies. Requirements may depend principally on Level 4 guidance rather than binding Levels 1–3 instruments. For CASPs, a licensing or registration regime may exist, but the regulatory perimeter or integrity framework remains materially incomplete, unclear, or unusable. At least three of the six core CASP components are missing, materially deficient, or present only at Level 4—for example, custody requirements do not extend beyond a general safekeeping obligation, no client-asset segregation rule is in force, or market-integrity requirements do not extend to CASPs. Proposals or consultations not yet in force do not raise the score above Level 1. Cap — Where CASP activity is permitted, an absent, materially unclear, or unusable CASP regulatory perimeter, or the absence of a meaningful CASP integrity framework, caps RI-6 at 1. Entity-coverage test: Binding requirements reach only some relevant entities or activities—for example, banks or a single fintech category while excluding VASPs or most non-bank fintechs, or only certain CASP activity types or asset classes without a documented risk-based rationale for the exclusions.

Evidence exists only at Level 4, or Levels 1–3 contain limited or generic provisions covering only some fintech entities, AML/CFT obligations, CASP activities, or components of a CASP regulatory framework.

Some fintechs, VASPs, or CASPs are subject to defined requirements, but significant entity types, activity categories, asset classes, or digital-channel obligations remain outside the framework or are subject to materially unclear rules.

Some entities are covered, but material uncertainty remains about digital onboarding, CDD, STR, or travel-rule obligations. Where CASPs are permitted, firms cannot reliably determine applicable CASP integrity obligations, or users lack a meaningful and predictable baseline of protections relating to custody, client-asset segregation, market integrity, or insolvency.

Binding legal, regulatory, or supervisory requirements in Levels 1–3 establish clear digital/remote CDD, monitoring/STR, and payment-transparency/travel-rule obligations for most relevant fintech and VASP/CASP categories, supported by supervisory mechanisms. For CASPs, a clear authorization or licensing perimeter exists and several core integrity components are addressed, including governance/fit-and-proper requirements and custody or safeguarding obligations. However, one or more significant gaps remain in entity coverage, digital-ID reliance conditions, fintech/VASP typology guidance, transition treatment for the 2025 Recommendation 16 revisions, sunrise or messaging-interoperability issues, operationalization, client-asset segregation and insolvency treatment, market integrity, cybersecurity/operational resilience, or supervisory enforcement. Cap — Where CASPs are permitted and the perimeter is clear but one or more significant gaps remain in custody/safeguarding, segregation/insolvency, governance/conflicts, market integrity, cybersecurity/operational resilience, or demonstrated implementation, the CASP sub-dimension caps RI-6 at 2. Entity-coverage test: Binding requirements apply to most major fintech and CASP activity types, but one or more significant categories—such as digital lenders, stablecoin issuers, or particular CASP services—remain excluded without a documented risk-based justification.

Binding Levels 1–3 requirements establish workable digital CDD, monitoring/STR, travel-rule, and CASP authorization frameworks, but documented gaps remain in one or more areas such as digital-ID reliance, VASP travel-rule specificity, typology guidance, asset segregation, market integrity, cyber coverage, or operationalization.

Most relevant fintechs, VASPs, and licensed CASPs are subject to defined and enforceable obligations, but coverage is not yet comprehensive across all significant entity types, activities, or operational scenarios.

Most regulated fintechs have workable digital CDD, STR, and travel-rule obligations. Where CASPs are permitted, users receive several core integrity protections, but remaining gaps in custody, client-asset segregation and insolvency treatment, governance, market integrity, cyber resilience, or implementation leave firms or users exposed in specific failure scenarios.

Binding legal, regulatory, and supervisory requirements in Levels 1–3 establish a comprehensive, risk-based framework for fintech and CASP/VASP activity. For fintech AML/CFT, this includes: (i) clear digital-ID and remote CDD/eKYC requirements consistent with FATF digital-identity principles; (ii) ongoing monitoring and STR obligations that are explicitly workable for digital channels; (iii) payment-transparency/travel-rule requirements that clearly reach VASPs and relevant fintech payment chains, including a stated position on the 2025 Recommendation 16 revisions and sunrise/interoperability issues; (iv) published fintech/VASP typology guidance; (v) supervisory review mechanisms; and (vi) consistent, documented applicability across core fintech models, with any prohibition or exclusion clearly stated as a perimeter decision. For CASPs, the framework must also establish a clear regulatory perimeter and binding, usable requirements for custody/safeguarding, client-asset segregation and insolvency protection, governance/fit-and-proper standards and conflicts management, cybersecurity and operational resilience, incident reporting, and market-integrity controls covering conduct such as manipulation, wash trading, insider dealing, and front-running. A score of 3 requires a verifiable operationalization record, such as a published thematic review, supervisory examination, typology report, or enforcement action demonstrating application of the framework in practice. Component G may provide additive credit only where no Component H cap applies. Cap — A score of 3 is not available where a material Component H deficiency remains. An undocumented or unjustified CASP carve-out, incomplete regulatory perimeter, material gap in custody/safeguarding, segregation/insolvency protection, governance/conflicts, cybersecurity/resilience, market integrity, or absence of verifiable operationalization caps RI-6 at 2. Level 4 evidence alone cannot support a score of 3. Entity-coverage test: For each requirement, ask whether the binding instrument reaches PSPs, e-money institutions, digital lenders, CASPs, VASPs by name or clear functional definition, rather than through generic extension of bank-oriented CDD rules. and other permitted digital-finance models. Record which provider category is the binding constraint on the score.

Comprehensive binding requirements are established in Levels 1–3 across digital CDD, monitoring/STR, travel-rule, CASP authorization, custody, segregation, governance, cyber/resilience, and market integrity, supported by published supervisory or typology guidance and a verifiable record of implementation or enforcement. Level 4 evidence may supplement but cannot independently justify this score.

Requirements apply consistently and with sufficient legal certainty across permitted fintech and CASP activity types. Firms can identify whether they are in scope, which obligations apply, and how those obligations operate in practice. Any prohibition, exclusion, or carve-out is explicitly documented, risk-based, and proportionate.

Regulated fintechs can determine and meet their digital onboarding, monitoring, STR, and travel-rule obligations with confidence. Where CASPs are permitted, users benefit from predictable custody, client-asset segregation and insolvency protections, governance safeguards, cyber-resilient operations, and enforceable market-integrity protections under active supervisory oversight.

Whether the obligations that keep the system standing are measurable: operational tolerances, incident reporting, safeguarding that is checked, and a regulator that reports on itself.

Resilience obligations are frequently written as intentions. A firm is required to have appropriate arrangements, and nobody can say afterwards whether it did. This pillar looks for numbers, deadlines, and verification.

It covers operational resilience tolerances, incident reporting windows, third party and concentration risk, financial crime expectations, and the safeguarding of customer funds. Safeguarding is treated strictly: an annual attestation from the firm is not the same as a reconciliation somebody outside the firm has checked.

Integrity also runs upward. The pillar includes appeal rights against supervisory decisions and the regulator's own reporting against its stated objectives, because a supervisor that cannot be corrected is a single point of failure like any other.

Covers operational resilience, cybersecurity governance, third-party and cloud risk, incident reporting, AML and CFT clarity for digital channels, and crypto-asset integrity controls where applicable. Excludes pure prudential capital and liquidity, and national cyber policy not directed at financial services.

Resilience assesses whether a jurisdiction's fintech-relevant regulatory framework is designed to keep digital financial services safe, reliable and trustworthy. It looks at operational resilience, cybersecurity, third-party and cloud dependency, incident reporting, AML and CFT clarity for digital channels, and crypto-asset integrity where the jurisdiction permits it.

This pillar does not measure regulatory strictness. It rewards clarity, coverage and implementability across the range of fintech models in scope, and it does not reward a supervisor for being difficult.

Cybersecurity: baseline controls, governance, supervisory guidance

Third-party, outsourcing and cloud risk, including exit and portability

Incident reporting: triggers, timelines, severity thresholds, channels

AML and CFT regime quality for digital channels, including the travel rule

Crypto-asset integrity controls where CASPs are permitted

Prudential capital and liquidity, unless tied to operational resilience or safeguarding

National cybersecurity policy not directed at financial services

Enforcement intensity and supervisory track record, except where published material clarifies expectation

Operational resilience expectations

Cybersecurity governance and controls

Third-party, outsourcing and cloud risk

Incident reporting and crisis handling

AML and CFT clarity and integrity controls

Weights are a starting point. The working group may revise them with documented rationale, which means they are open to an edit too.

Published material only

The assessment reads what a jurisdiction has published. Supervisory expectations communicated privately are invisible to it, which understates jurisdictions that supervise well without writing much down.

Coverage is not effectiveness

A clear, complete framework scores well whether or not it is enforced. Enforcement outcomes sit in pillar 02 and are deliberately not double counted here.

Crypto scope varies

Where a jurisdiction prohibits crypto-asset services, the integrity sub-dimension is reweighted across the remaining four rather than scored as absent.

Seven indicators. This is the canonical text. Select any passage to propose an alternative.

Pillar definition

Rules Clarity & Comprehensiveness (RCC) measures whether a jurisdiction’s fintech‑relevant rules are:

Findable and understandable (“clarity”), and complete enough to cover common fintech activities and risks (“comprehensiveness”), in a way that a regulated firm, or prospective entrant, can determine what licence it needs, what obligations apply, and how to comply, using publicly available materials.

This is not a “friendliness” or deregulatory score. It does not reward laxity; it rewards clarity, coherence, and coverage of the fintech rulebook itself.

Scope and boundaries

In scope (fintech‑relevant rule corpus):

Primary laws and regulations covering:

Core: Payments / payment systems / e-money Banking / lending / credit Securities / investment / advice / management Insurance Digital assets: custody, issuance of crypto tokens / asset tokenisation / stablecoins, crypto‑asset services (if applicable) Subareas within core: Regtech / suptech Digital banking / fintech licensing / regulation digital lending / BNPL Roboadvisory / automated trading Financial infrastructure / trading systems Data analytics / AI Internal IT systems Crowdfunding (if applicable)

Cross‑cutting supervisory requirements that materially affect fintech operations, including:

Core: AML/CFT / (e)kyc Data protection Data use / portability / consent in financial services Identity Subareas: Outsourcing / cloud Cybersecurity Operational resilience Safeguarding of funds Market conduct requirements

Out of scope:

Ecosystem outcomes (e.g. investment levels, number of fintechs). Enforcement “toughness” (except as it affects interpretive clarity and transparency). Broader “quality of regulation” debates unrelated to clarity or coverage.

RCC evaluates the quality and navigability of the rulebook as a rulebook, not the substantive policy stance or outcomes.

Scoring conventions and evidence rule

RCC uses a 0–3 evidence‑based scale:

0 = Opaque / materially unclear: key requirements are hard to find, ambiguous, contradictory, or not operational. No regulation at all.

1 = Partially clear: some guidance exists but significant ambiguity or gaps remain, creating material uncertainty for common models. Advisory / policy statements etc, providing some level of clarification. Role of supervisory processes.

2 = Clear and workable: most relevant rules are findable and understandable; some gaps or fragmentation remain.

3 = Highly clear, coherent, and comprehensive: rules are well‑organised, well‑defined, publicly accessible, consistently explained, and cover the core fintech perimeter with clear compliance pathways.

Across the RCC matrix, a score of 3 should normally require all of the conditions for a 2, plus evidence that the framework is clearly organised and easy to navigate. In practice, this should usually mean that a firm can see how the relevant pieces fit together through a clear official entry point such as a portal, consolidated handbook, licensing map, rulebook structure, or equivalent public navigational tool.

For any score of 3, the evidence log should normally include at least:

a public navigational or mapping tool (for example, portal, handbook, licensing map, or guidance that helps users find obligations), and at least one public binding instrument (law, regulation, rulebook or equivalent) supporting the underlying obligations.

Every score must be supported by public sources (laws / regulations, regulator handbooks, licensing pages, official FAQs / guidance, consultation documents, official portals, policy statements / judicial decisions etc.). “Reputation” or private information cannot be used as evidence.

Conduct of review

The initial review will typically be undertaken as a desk review process. Ideally, it will be followed by direct engagement with participants, similarly to other international standards review processes.

For purposes of FRFI scoring, the RCC Working Group has adopted the following definition of Fintech:

“Fintech businesses use existing or new technology via centralised or decentralised systems to disrupt, to reimagine, to expand a services offering, to create financial instruments, to inhabit a niche, or to offer new ways for people to participate in their financial lives, either directly or through existing financial services providers, from a business, sales, information, analytics, product, regulatory or risk management standpoint.”

This definition is intentionally broad and inclusive. It encompasses new entrants and legacy players, retail and institutional services, and both the provision of financial services directly to end users and the provision of technology that enables others to provide such services. It covers activities conducted on both centralised systems (traditional software, cloud infrastructure) and decentralised systems (blockchain, distributed ledger technology).

A regulatory framework that does not keep pace with new technologies and fintech business models slows the realisation of these potential benefits, by creating uncertainty and friction around licensing, obligations, and compliance

Implication for Scoring: The Regulatory Status Problem

A critical feature of this definition is that it deliberately spans the full spectrum of regulatory status. Fintech businesses as defined above may be:

Category A, Directly Regulated: The firm itself holds a license or registration and is subject to direct regulatory obligations. Forward looking approach. Category B, Unregulated: The firm’s activities do not trigger a licensing or registration requirement and the firm is not subject to direct regulatory obligations. Category C, Unregulated but Indirectly Regulated: The firm is not itself licensed or registered, but provides services to a regulated entity that enable regulated functions, and as a result is subject to regulatory requirements imposed through the regulated entity’s obligations via outsourcing rules, vendor management requirements, or contractual terms imposed by regulatory compulsion.

This three-way distinction creates the following two scoring challenges.

First, for firms in Category B: how does the regulatory framework communicate to an unregulated FinTech firm that it is unregulated, and do so with sufficient clarity that the firm can rely on that determination? A firm that is simply silent in the regulatory framework faces uncertainty, which is itself a form of regulatory unclarity. A well-functioning regulatory environment provides clear negative perimeter guidance, affirmative statements about what is not regulated, not just positive licensing requirements.

Second, for firms in Category C: how does the regulatory framework communicate to an indirectly regulated FinTech firm what obligations flow to it through its regulated clients, and does it do so in a way that is publicly accessible and operationally usable? This category is growing rapidly as regulators extend supervisory reach to critical third-party technology providers, and the clarity, or lack thereof, of those indirect obligations is a material issue for FinTech firms operating as vendors to the regulated sector.

These are addressed through the indicators in the instructions and considerations .

Why this Distinction Matters for RCC

Regulatory regimes differ fundamentally in how they express obligations, and this difference has direct consequences for how RCC indicators should be scored. The RCC pillar measures whether a jurisdiction’s fintech-relevant rules are clear, findable, and complete. But “clear” means something different depending on the regulatory philosophy underlying the framework being assessed. Scorers who fail to account for this distinction will systematically undervalue sophisticated principles-based systems and overvalue prescriptive rules-based systems that may in practice be less navigable.

Rules-Based Regimes

A rules-based regime specifies obligations in precise, detailed terms. It tells regulated firms exactly what they must do, when, how, and in what form. Typical features include numerical thresholds, prescribed reporting formats, mandatory contract terms, defined timelines, enumerated prohibited activities, and specific procedural requirements. The firm’s compliance question is essentially binary: did it follow the specified rule or not?

Rules-based regimes are strong on operational clarity: a firm generally knows exactly what it must file, in what format, and by when. Their limitation is that detailed rules can become outdated quickly as technology and business models evolve, may produce compliance-with-the-letter-but-not-the-spirit behaviour, and can create rigidity that impedes legitimate innovation.

Principles-Based Regimes

A principles-based regime specifies obligations in terms of outcomes or standards of conduct, leaving firms to determine how to achieve them. It tells regulated firms what to achieve, treat customers fairly, maintain adequate capital, manage risk prudently, act with integrity, without dictating the specific means. The firm exercises judgment about how to comply.

Principles-based regimes are strong on outcome clarity: a firm generally knows what standard it is expected to meet and what objective it is expected to achieve. Their limitation is operational ambiguity: a firm may understand perfectly well that it must “treat customers fairly” while remaining genuinely uncertain about whether a specific product feature, disclosure format, or complaint-handling procedure satisfies that obligation. In a principles-based system, that operational content is typically supplied not by the rules themselves but by supplementary interpretive mechanisms, supervisory guidance, published case studies, regulatory speeches, enforcement decisions, and FAQs, which accumulate over time to give the principles practical meaning.

Outcomes-based Regimes

An outcomes-based regime focuses on a particular set of results. The system is then designed to achieve the results which are being targeted.

Such systems - to be effective - must have clear outcomes. Those outcomes must then be clearly tied to the elements of the regulatory system. [add example]

Merit-based Regimes

Merit-based regimes focus on qualitative results: decisions are based on intentions. A merit-based regime may thus be similar in some ways to an outcome based system. However, an outcome based system typically seeks objective results while a merit-based system targets more subjectively. An outcome based system may target “better quality financial products and services” while a merit-based system may target “good financial products and services”.

Merit-based systems often lack clarity of merits being targeted. For clarity, a merits-based regime would need to have clear targets enabled by a regulatory system designed to achieve those targets.

The Spectrum in Practice

Real regulatory systems sit at various points on a spectrum between these categories and most are hybrids. A jurisdiction may use principles for conduct and outcomes while using precise rules for technical requirements such as capital ratios, prescribed reporting taxonomies, and defined timelines for complaint resolution. The UK’s FCA Handbook is a well-known example of a sophisticated hybrid: it contains both high-level principles (the FCA’s Principles for Businesses) and highly detailed prescriptive rules. The EU’s approach under MiCA tends toward greater prescriptiveness. The US operates differently again, with some agencies using a mix of principles and rules while others rely more heavily on supervisory guidance.

How This Affects RCC Scoring

The key analytical point for RCC scoring is this: a principles-based regime can be highly clear on outcomes while being less clear on operations; a rules-based regime tends toward the opposite: clearer on operations but potentially less adaptable and less clear on the underlying purpose of the obligation. To be effective, an outcomes or a merit based regime must have clear outcomes or targets and a system designed to achieve these. No approach is inherently superior from a clarity standpoint, and the FRFI does not take a position on which regulatory philosophy produces better outcomes. What the FRFI measures is how well each jurisdiction achieves clarity within its own chosen approach, and whether the mechanisms it uses to supply operational content are adequate for a regulated firm to determine and implement its obligations.

This has three practical consequences for scoring:

Multiple paths to a high score exist. For indicators where this tension arises, principally RCC-2, RCC-4, RCC-5, RCC-6, and RCC-7, a jurisdiction can reach a score of 3 via a rules-based path, a principles-based path, an outcomes-based path or a merits-based path. The evidence required differs and these paths are specified explicitly in the affected indicators. A principles-based regime should not receive a 3 solely because the underlying principles are well expressed at a high level. A 3 requires that those principles be made operationally usable through a sufficiently mature public interpretive infrastructure, for example through FAQs, speeches, case studies, examples, supervisory statements, enforcement summaries, or equivalent materials that show how the principles are applied in practice. RCC-6 carries greater weight in principles-based systems. In a rules-based system, the rules themselves supply operational content. In a principles-based system, that content is supplied through guidance, FAQs, supervisory statements, and enforcement precedent. For principles-based jurisdictions, RCC-6 is the mechanism by which principles acquire operational clarity. Scorers should read RCC-5 and RCC-6 together for principles-based jurisdictions. Scorers must identify the regulatory philosophy before scoring and note it in the evidence log. This affects both the evidence sought and the rubric path applied. See Section 7 (Evaluator Instructions) for the required procedure.

Sub-dimension: Weight / Indicators A: Accessibility & Usability: 20%: RCC-1, RCC-2 B: Definitions & Perimeter Clarity: 30%: RCC-3, RCC-4, RCC-8, RCC-9 C: Coverage & Completeness: 30%: RCC-4, RCC-5 D: Consistency, Change Management & Interpretive Support: 20%: RCC-6, RCC-7

Working Group decision required on whether to adjust weights following addition of RCC-8 and the elevated importance of RCC-6 in principles-based systems. [Weights are indicative and subject to revision; there is no strict scientific basis for their distribution.]

RCC currently uses eight core indicators. The detailed objective-trigger tables in Section 4 specify how to score 0–3; this overview summarises the purpose of each indicator.

RCC-1 Public accessibility & findability: Whether fintech-relevant rules are freely available online and easy to locate via official sources. RCC-2 Regulatory “map” of obligations: Whether regulators provide an official, usable pathway explaining how a fintech firm, across all three regulatory status categories, determines what license it needs, what licensing conditions apply, what obligations apply, and how to navigate the regulatory framework.. RCC-3 Definitions, Taxonomy & Perimeter Clarity for Common Fintech Activities: Whether key regulatory terms and fintech-relevant activity categories are defined clearly enough that a firm can tell, from public sources, whether it falls within the regulatory perimeter and which regime applies. RCC-4 Coverage across core fintech verticals: Whether the rule corpus covers the major fintech activity verticals without large gaps. RCC-5 Compliance operability: Whether a regulated firm, and where applicable an indirectly regulated vendor, can determine how to implement its obligations in practice RCC-6 Interpretive support & Q&A mechanisms: Whether regulators provide reliable public mechanisms (FAQs, guidance, interpretive processes) to reduce uncertainty. RCC-7 Change management & version control: Whether rule changes, whether to prescriptive rules or to principles and their interpretive elaboration, are made transparently and predictably, with sufficient notice for firms to adapt.. RCC-8: Outsourcing Perimeter & Indirect Supervision Clarity: Whether a regulated FinTech firm, or a regulated entity that uses FinTech vendors, can determine from publicly available sources which of its outsourced or delegated functions remain subject to regulatory oversight, and what it must therefore ensure of the third parties to whom those functions have been delegated.

The Resilience pillar assesses whether a jurisdiction's fintech-relevant regulatory framework is designed to keep digital financial services safe, reliable, and trustworthy. It evaluates operational resilience expectations, cybersecurity governance, third-party and cloud risk controls, incident reporting requirements, and AML/CFT regime quality for digital channels — so that fintech innovation can scale without creating unacceptable systemic, consumer, or crime risks.

Section 0

Overview

This pillar does not measure regulatory strictness. It rewards clarity, coverage, and implementability of resilience and integrity expectations across the range of fintech models in scope: payment service providers (PSPs), e-money institutions, digital banks, digital lenders, and crypto-asset service providers (where applicable).

Section 1

SCOPE AND BOUNDARIES

22

• Operational resilience requirements — business continuity planning, disaster recovery, incident response, critical service mapping, and resilience governance for regulated fintech entities. • Cybersecurity expectations — baseline security controls, governance requirements, and supervisory guidance applicable to regulated entities. • Third-party, outsourcing, and cloud risk — material outsourcing frameworks, cloud-specific guidance, concentration risk rules, and exit/portability planning requirements. • Incident reporting — mandatory reporting obligations for cyber and operational incidents, including triggers, timelines, severity thresholds, and reporting channels. • AML/CFT regime quality for digital channels — clarity of customer due diligence (CDD) and eKYC expectations, suspicious transaction reporting (STR) obligations, and the travel rule where applicable to fintech models. • Crypto-asset integrity controls (where applicable) — custody standards, asset segregation requirements, governance expectations, and market integrity requirements for crypto-asset service providers.

03

Section 2

SCORING CONVENTIONS

Applies the index-wide 0 to 3 scale and four scoring paths specific to this pillar.

0

Absent or unclear

No meaningful requirements exist, or material ambiguity prevents regulated entities from determining their obligations.

1

Emerging

Partial requirements exist. Coverage is limited, applicability to fintech models is uncertain, or guidance is too high-level to be operationally useful.

2

Established

Clear requirements apply across most relevant entity types. Some gaps remain — for example, limited coverage of non-bank fintechs, fragmentation across agencies, or absence of supervisory guidance.

3

Comprehensive & implemented

A robust, coherent framework is in place with clear expectations, documented reporting pathways, and published supervisory guidance. Requirements apply explicitly across core fintech models — not only to banks.

Evidence rule:

Every score must be grounded in publicly available primary sources — laws, regulations, supervisory handbooks, circulars, guidance notes, or official reporting rules. No anecdotal or reputation-based scoring.

Four-scale scoring

Each RI indicator carries a main rubric plus three further 0–3 scales, all recorded for every jurisdiction:

Main rubric

The substance of the requirement itself.

Evidence rating

The legal force of the sources found, graded against four levels: Level 1 primary legislation; Level 2 binding subordinate legislation (regulations, technology-risk standards, licensing conditions); Level 3 binding supervisory requirements (directives, notices, enforceable circulars, binding handbooks); Level 4 non-binding guidance.

Applicability rating

Whether the binding instrument reaches non-bank fintechs specifically and by name or clear functional definition, rather than through ambiguous or uncodified extension of bank rules.

Outcome-based rating

What the framework actually delivers in practice.

Note

Multi-path anchors. RI-1 sets out separate rules-based and outcomes-based (principles) anchors for scores 2 and 3, with scores 0 and 1 shared.

Section 3

Sub-Dimensions

Sub-dimension

Weight / Indicators

RI-1 — Operational Resilience Baseline Requirements

22% — RI-1

RI-2 — Cybersecurity Governance and Minimum Controls

20% — RI-2

RI-3 — Third-Party Risk Management Framework

19% — RI-3

RI-4 — Incident Reporting Requirements and Timelines

5% — RI-4

RI-5 — Resilience Testing and Assurance Expectations

14% — RI-5

RI-6 — AML/CFT Clarity for Digital Onboarding and Fintech Models

20% — RI-6

6

Section 4

Indicator Matrix

06

A

B

C

D

E

F

RI-1

Operational Resilience Baseline Requirements

Sub-dim A

00 sug

RCC-1

Public Accessibility & Findability

Sub-dimension:

What it measures

RI-1 measures whether a jurisdiction's fintech-relevant regulatory framework has established clear, binding, and published expectations ensuring that digital financial service providers can maintain core operations, safeguard financial stability, and recover rapidly when an operational shock or technology breakdown occurs.

Framing Note

Draft international best-practice standard. A jurisdiction meets the RI-1 standard where its financial-sector framework requires regulated entities to maintain: Board- and senior-management accountability for operational resilience and continuity; Documented continuity frameworks integrated with either quantitative Recovery Time Objectives (RTOs) or defined impact tolerances for severe but plausible disruptions; Identification and mapping of critical business functions/important business services, internal sub-processes, and external dependencies; and Mechanisms for supervisory review and challenge, with all of the foregoing applying consistently across entities in scope.

Components

Component A Governance and C-Suite Accountability: The framework assigns explicit responsibility for operational resilience and continuity to the board and senior management. It requires executive-level oversight, dedicated operational risk resourcing, and formal integration of continuity strategies into enterprise risk management.

Component B Business Continuity & Operational Targets

The framework requires a documented approach to business continuity designed to withstand severe operational disruptions. Depending on the regulatory model, this is demonstrated through prescriptive Disaster Recovery (DR) frameworks with fixed Recovery Time Objectives (RTOs) or through the setting of "impact tolerances" that define the maximum tolerable level of disruption to an important business service.

Component C Critical Service & Interdependency Mapping

The framework requires entities to map their end-to-end critical business functions or important business services, identifying internal asset interdependencies (people, technology, processes) and external third-party dependencies. (Boundary Note: Specific vendor contractual terms and cloud exit strategies are evaluated under RI-3.)

Component D Supervisory Review and Enforceability

The requirements sit in a binding or enforceable instrument supported by a supervisory mechanism allowing the regulator to actively challenge, audit, and sign off on an entity's operational resilience parameters. (Boundary Note: Active threat-led penetration testing is evaluated separately under RI-5.)

Component E Cross-Entity Applicability

The requirements apply consistently across entities in scope: Banks, PSPs, e-money institutions, digital banks, digital lenders, and CASPs where permitted. Explicit statutory or binding supervisory applicability to non-bank fintechs forms the primary boundary condition for a score above Level 1.

Scoring Rubric

Score

Proposed Objective Trigger

No operational resilience or continuity requirements directed at financial entities exist in published law, regulation, or binding supervisory instruments; or provisions are so ambiguous that a regulated entity cannot determine its obligations. Entity-coverage test: No instrument references non-bank fintechs.

No evidence found in Levels 1 - 4;

No regulated fintech provider is subject to operational resilience requirements.

No assurance that fintech services can survive operational shocks or system outages.

A binding instrument or Level 4 guidance imposes a general obligation to manage continuity (e.g., "entities must have a BCP"), but core elements are missing: governance accountability is not assigned to the board; explicit recovery metrics/impact tolerances are absent; or requirements are drafted for prudential banks only. Entity-coverage test: Requirements do not clearly reach non-bank fintechs, or reach them only by generic, uncodified reference.

Outcomes-Based (Principles) Path

Binding requirements (Levels 1-3) clear the Resolution Gate by establishing BOTH: (1) Explicit applicability extending directly to non-bank PSPs and e-money institutions; and (2) Binding operational minimums including C-suite/board governance accountability, the identification of important business services, and the setting of defined impact tolerances for severe but plausible disruptions. At least one significant gap remains: end-to-end dependency mapping is absent; scenario testing expectations are uncodified; or there is no verifiable operationalization record.

Evidence only in Level 4, or limited Level 1-3 provisions applying to banks or via generic reference.

Applies directly to several major non-bank fintech categories (PSPs, EMIs), but excludes others without documented rationale.

Regulated fintechs maintain accountable governance and defined recovery targets/impact tolerances, but gaps remain in interdependency mapping and supervisory testing.

Main rubric - Rules-Based Path

Binding requirements (Levels 1-3) establish all of: (i) Explicit board/senior-management accountability; (ii) Binding BCP/DR frameworks with numeric RTOs for core services; (iii) Mandated critical service, business function, and dependency mapping; (iv) Interactive supervisory review and challenge mechanisms; and (v) Explicit, consistent applicability across core non-bank fintech models. Operationalization requirement: A published supervisory examination, thematic review, or enforcement action demonstrating application to fintech operational resilience is required.

Binding requirements in Levels 1-3 exist, but are incomplete in mapping depth, supervisory challenge, or operationalization record.

Requirement applies to several major fintech providers categories but excludes one or more significant categories without a clear risk based justification.

Functional Consumer Protection Outcome Most consumers receive standardised disclosures before purchasing or using digital financial products. Material fees and product features are disclosed, but gaps remain in coverage, digital presentation, ongoing updates, or supervisory monitoring.

Binding requirements (Levels 1-3) establish all of: (i) Explicit board/senior-management accountability; (ii) A mandate to ensure important business services can remain within defined impact tolerances under severe but plausible scenarios; (iii) Mandated resource and dependency mapping for all identified important business services; (iv) Interactive supervisory review and challenge mechanisms; and (v) Explicit, consistent applicability across core non-bank fintech models. Operationalization requirement: A published supervisory thematic review, enforcement action, or public assessment demonstrating application to fintech operational resilience is required.

Comprehensive, enforceable requirements in Levels 1-3, supported by supervisory review and a verifiable operationalization record.

Applies consistently across all relevant fintech categories, with any exclusions explicitly risk-based, documented, and proportionate.

Regulated fintechs maintain fully mapped, executive-backed operational resilience architectures capable of maintaining critical services through major disruptions.

Scoring paths

Two paths: rules-based and outcomes-based (principles). Coders identify the jurisdiction’s dominant regulatory philosophy first, apply the matching path for scores 2 and 3, and note the path used in the evidence log.

Primary evidence sources

Evidence Tiers

Scores are anchored strictly to publicly verifiable primary sources, classified by legal force: Level 1: Primary legislation: Financial services acts, payment systems statutes, or operational resilience acts. Level 2: Binding subordinate legislation: Regulations, technology-risk standards, and licensing conditions. Level 3: Binding supervisory requirements: Directives, notices, enforceable circulars, and binding supervisory handbooks. Level 4: Non-binding guidance: Guidance notes, best-practice papers, supervisory expectations, and FAQs.

Entity-Coverage Test

For each requirement, ask: Does the binding instrument reach non-bank entities (PSPs, e-money institutions, digital lenders, CASPs) specifically and by name or clear functional definition, rather than through ambiguous or uncodified extension of bank rules? Record which provider category forms the binding constraint on the score.

Reference-versus-Mandate Rule

Reference-versus-Mandate Rule: Financial regulators frequently reference soft-law principles without mandating them. A reference alone or a non-binding guidance paper (Level 4) caps the score at 1 (Emerging). Transposition into binding domestic instruments (Levels 1-3) is required for a score of 2 or higher.

Operationalization Requirement for a Score of 3

A score of 3 requires evidence that the framework has been applied in practice to fintech operational resilience via a published supervisory examination report, thematic review, or enforcement action demonstrating active application. A framework that is comprehensive on paper but lacks a verifiable operationalization record is capped at a Score 2.

Aggregation rule

Direct

single integer score 0–3. The same score is also rated on three further 0–3 scales — evidence, applicability and outcome-based. All four sit together in each score cell, each under its own label.

Suggest an edit

Endorse a level

Cite this indicator

RI-2

Cybersecurity Governance and Minimum Controls

Whether regulated entities have clear, published expectations for cybersecurity governance (board/management accountability) and baseline technical and organisational security controls.

Note on the Standard

The standard is written by reference to established international standard-setting bodies. Jurisdictions are used only to validate and improve the standard rather than to rate the jurisdictions themselves at this stage.

Technology-neutral

The standard asks whether a jurisdiction’s financial-sector framework requires sound cyber governance and a defined baseline of controls. It takes no position on any particular technology or architecture, including the question of centralized versus decentralized infrastructure. Where a framework is silent on a novel architecture, that silence is noted as a gap rather than scored as a technology preference.

Proportionality

The standard is applied proportionately to the scale, complexity, and cross-border reach of the fintech activity actually present in a jurisdiction. It rewards a framework that is appropriate to the entities operating in that market, rather than the presence of every element regardless of relevance, and it is not benchmarked to any single jurisdiction or region. A smaller or less-mature market whose framework comprehensively addresses the entity types and risks actually present is not marked down for omitting elements that are not relevant to it, provided the regulator’s rationale is adequately documented.

Terminology

The entity categories used in this indicator (banks, payment service providers, e-money or stored value issuers, digital banks and lenders, and crypto-asset service providers) are functional descriptions, not any single jurisdiction’s licensing labels. Scorers map local entity types to these functions and do not mark a jurisdiction down for using different terminology, or for drafting in a language other than English.

Standard Statement

A jurisdiction meets the RI-2 standard where its financial-sector framework requires regulated entities to maintain (a) board- and senior-management accountability for cyber and information and communications technology (ICT) risk; (b) a documented cyber/ICT risk-management framework integrated into enterprise risk management; (c) a defined baseline of minimum technical and organizational controls; (d) a continuous detection and monitoring capability; and (e) mechanisms for supervisory review and enforcement with all of the foregoing (f) applying consistently across entities and technologies in scope.

Component A: Governance and Accountability

The framework assigns explicit responsibility for cyber and ICT risk to the board and senior management, identifies a designated accountable function (e.g., a Chief Information Security Officer or equivalent), requires board-level oversight and reporting, and calls for adequate resourcing and independence of the security function and for cyber-risk awareness across the organization.

Component B: Cyber/ICT Risk-management Framework

The framework requires a documented approach to identifying, assessing, and managing cyber/ICT risk, including asset and critical-function identification, a defined risk appetite, and integration into enterprise risk management, using a common risk taxonomy.

Component C: Minimum Baseline of Technical and Organizational Controls

The framework specifies a baseline of controls rather than instructions to “manage cyber risk.” At minimum: identity and access management (least privilege, multi-factor authentication, and privileged-access management); asset and configuration management; vulnerability and patch management; data protection and encryption in transit and at rest; secure configuration; and network security.

Component D: Detection and Monitoring Capability

The framework requires the capability to detect cyber events on a timely basis: logging, security monitoring, and use of threat intelligence. Note that the obligation to externally report incidents and the applicable timelines are assessed under RI-4 while RI-2 assesses the internal detection capability.

Component E: Supervisory Review and Enforceability

The requirements are set out in a binding or enforceable instrument and supported by a supervisory mechanism: examination powers, reporting to the supervisor, or an equivalent means by which the authority can assess compliance and take corrective action.

Component F: Cross-entity Applicability

The requirements apply consistently across entities in scope: banks, PSPs, e-money institutions, digital banks and lenders, and CASPs where permitted. Any exclusion of a provider category is explicitly risk-based, proportionate, and documented by the regulator.

No cybersecurity governance or control expectations directed at financial entities exist in published law, regulation, or binding supervisory instruments; or provisions are high-level or ambiguous to a point that a regulated entity cannot determine any governance responsibility or minimum control obligation. Entity-coverage test: no instrument references financial-sector entities, or only aspirational statements exist.

No evidence found in Levels 1 - 4.

No fintech provider is subject to the relevant legal or regulatory requirements.

No assurance that regulated fintechs govern or control cyber risk; no binding obligation exists.

A binding instrument imposes a general obligation to manage cyber/ICT risk, but at least one core element is missing: governance accountability is not assigned (no board/senior-management responsibility); or no minimum controls are specified; or the obligation is drafted for banks/prudential institutions only. Requirements may rest only on non-binding guidance (Level 4). Entity-coverage test: requirements do not clearly reach non-bank fintechs, or reach them only by generic reference.

Evidence only in Level 4, or limited provisions in Levels 1-3 applying to some entity types or as generic references.

Applies only to traditional banks/prudential institutions or a single category, excluding most fintechs.

Some entities are subject to cyber expectations, but coverage is fragmented; users cannot expect consistent cyber governance across digital financial services.

Binding requirements (Levels 1-3) establish both (a) cyber/ICT governance accountability at the board/senior-management level and (b) a defined set of minimum technical and organizational controls, applying to most relevant regulated fintech categories. At least one significant gap remains: e.g., a fintech category excluded without a documented risk-based rationale; fragmentation across the financial regulator, cyber authority, and financial intelligence unit (FIU) that leaves responsibilities unclear; controls are stated only at a high level with no implementation guidance; or an external standard is referenced but not mandated; or there is no verifiable operationalization record. Entity-coverage test: binding requirements reach several major fintech categories but are not applied consistently across all relevant entities.

Binding requirements in Levels 1-3 exist but are incomplete in governance scope, control specificity, or fintech application.

Applies to several major fintech categories but excludes one or more significant categories without a published risk-based justification.

Most regulated fintechs are subject to governance accountability and baseline of controls, but gaps remain in coverage, control specificity, or supervisory monitoring.

Binding requirements (Levels 1-3) establish all of: (i) explicit board/senior-management accountability with a designated responsible function; (ii) a documented cyber/ICT risk-management framework integrated into enterprise risk management, with a defined risk appetite; (iii) a minimum baseline of technical and organizational controls (identity and access management including MFA and privileged-access control; asset and configuration management; vulnerability and patch management; data protection and encryption logging and monitoring/detection); (iv) a supervisory review mechanism with examination or reporting powers; and (v) explicit, consistent applicability across core fintech models, with any exclusions explicitly risk-based and proportionate. A jurisdiction may alternatively reach 3 through a proportionate path: its framework comprehensively covers the entity types and risks actually present in its market, and any element that is absent is documented by the regulator as not relevant to that market. Operationalization requirement: a published supervisory examination or thematic review, enforcement action, or supervisory guidance demonstrating application to fintech cyber governance is required.

Comprehensive, enforceable requirements in Levels 1-3, supported where appropriate by supervisory guidance and a verifiable operationalization record. A Level 4 source alone would not justify a score of 3.

Applies consistently across all relevant regulated fintech categories, with any exclusions explicitly risk-based, documented, and proportionate. An undocumented carve-out would be considered an unexplained gap and would receive a score of 2.

Regulated fintechs consistently maintain accountable cyber governance and a baseline of controls, subject to supervisory oversight and corrective action, producing predictable protection of digital financial services.

One path — the anchors apply to all four approaches.

Primary sources to consult

Cyber or technology risk rules; security standards mandated by the financial regulator; supervisory guidance on cyber governance. The following were utilized in the drafting of these standards.

G7 Cyber Expert Group

Fundamental Elements of Cybersecurity for the Financial Sector; Fundamental Elements for Third-Party Cyber Risk Management.

Basel Committee on Banking Supervision (BCBS)

Principles for Operational Resilience; Principles for the Sound Management of Operational Risk.

CPMI–IOSCO

Guidance on Cyber Resilience for Financial Market Infrastructures; CPMI guidance on endpoint security for wholesale payments.

Financial Stability Board (FSB)

Cyber Lexicon; Effective Practices for Cyber Incident Response and Recovery; incident-reporting convergence work.

IOSCO

Cyber-resilience guidance for securities markets.

NIST

Cybersecurity Framework 2.0 (Govern, Identify, Protect, Detect, Respond, Recover); post-quantum cryptography standards.

ISO/IEC

27001 (ISMS) and 27002 (controls); 27005 (risk management).

EU DORA

Digital Operational Resilience Act, as a leading implemented regime (referenced for governance and ICT-risk-management structure; the standard is drafted to apply beyond DORA jurisdictions).

Score against publicly verifiable primary sources, classified by legal force. A higher tier carries greater weight.

level

Primary legislation: financial services acts; ICT/cybersecurity statutes applicable to financial entities.

Binding subordinate legislation: regulations, prudential and technology-risk standards, licensing conditions, mandatory ICT/cyber rules.

Binding supervisory requirements: directives, notices, enforceable circulars, and codes incorporated by reference into regulation.

4

Non-binding guidance: guidance notes, best-practice papers, supervisory expectations, FAQs.

For each requirement, ask: does the binding instrument reach non-bank entities such as PSPs, e-money institutions, digital lenders, CASPs, and is it drafted to apply to them specifically, rather than by generic extension of bank rules? Record which provider category is the binding constraint on the score.

Reference-versus-mandate Rule

Financial regulators frequently reference external standards (e.g., NIST CSF, ISO/IEC 27001) without mandating them. A reference alone does not raise the score. Where a regulator incorporates or mandates an external standard in a binding or enforceable way, that supports a higher score than one that only encourages it.

A score of 3 requires evidence that the framework has been applied in practice to fintech cyber governance: a published supervisory examination or thematic review, an enforcement action, or supervisory guidance demonstrating application (not just the existence of a rule). For example, a framework that is strong on paper but lacks a verifiable operationalization record would receive a score of 2.

Two-variable Threshold

Consistent with the shared scoring convention used across pillars, each score combines two variables: (i) whether a binding legislative or regulatory basis exists and (ii) whether that basis is operationalized in practice. A score of 2 reflects certainty on one of these variables for the core requirements; a score of 3 requires certainty on both across the full scope of the indicator.

Maturity Cap

Proposals and consultations do not count as implemented and cap the attainable score at 1. Rules enacted but not yet in force, and without accompanying operational guidance, cap the attainable score at 2.

Edge cases & scoring notes

Scoring note

Do not require adoption of a specific external standard (NIST, ISO 27001). Score whether the financial regulator has issued binding or enforceable cybersecurity expectations with clear content. A regulator that mandates compliance with an external standard explicitly scores higher than one that merely references it.

Evidence and Edge-case Conventions

Use only public, citable sources; do not infer a score from reputation. For non-English sources, note the language and whether an official or machine translation was used, and do not penalize a jurisdiction for language alone. Where a score is a close call between two levels, record the specific rubric trigger that was not met. In federal or multi-agency systems, score the regime that actually binds financial entities, document the allocation, and treat unresolved fragmentation that leaves obligations unclear as a scoring factor in its own right.

single integer score 0–3. The same score is also rated on three further 0–3 scales — evidence, applicability and outcome-based. All four sit together in each score cell, each under its own label. Each component (A to F) is scored 0 to 3 and logged at component level; the indicator-level RI-2 score is the simple average of the component scores.

RI-3

Third-Party Risk Management Framework

RI-3 assesses whether (1) regulated fintechs are subject to a proportionate third-party risk management regulatory framework that considers the complexity of regulated entities and criticality of their third-party service relationships, (2) the regulatory framework reinforces sound governance standards over third-party risk management, and (3) regulatory requirements and expectations are aligned with the third-party service relationship lifecycle, ensuring a structured regulatory framework that appropriately addresses the risks relevant to fintechs and their third-party relationships.

A jurisdiction meets the RI-3 standard when its third-party risk management regulatory framework is operationalized (see description of Cap 1 below in the Scoring Notes) and exhibits the following characteristics (each, a Sub-Dimension):

Proportionality is a core regulatory principle across the third-party risk management framework, such that (i) the regulatory framework establishes a structure in which third-party risk (and thereby third-party risk management) may be commensurate with a fintech’s business model, complexity, cross-border operations, risk profile, scale, structure and size; and (ii) regulatory requirements are flexible based on a criticality or materiality basis. Applicability is consistent across core fintech models (including digital lenders and CASPs where permitted), with any exclusion explicitly risk-based and documented. The regulatory framework establishes requirements that assign explicit responsibility for third-party risk management to the board and/or senior management, require a documented third-party risk-management framework, and state that accountability for outsourced functions remains with the regulated entity. Applicability is consistent across core fintech models, with any exclusion explicitly risk-based and documented; and A binding framework covers the full relationship lifecycle on a criticality basis and core risk areas are covered with clear, implementable regulatory guidance; the scope of the regulatory framework extends beyond formal outsourcing to material third-party relationships generally; and applicability is consistent across core fintech models, with any exclusion explicitly risk-based and documented.

RI-3A: Proportionality — Assesses whether proportionality functions as a core regulatory principle across the third-party risk-management framework, indicating the regulator has considered how third-party risk (and therefore third-party risk management) varies with a fintech’s business model, complexity, cross-border operations, risk profile, scale, structure, and size. Regulatory obligations should scale based on the criticality or materiality of the third-party service relationship and the nature of the regulated entity’s business, rather than applying uniformly. RI-3B: Governance — Assesses whether the regulatory framework assigns explicit responsibility for third-party risk management to the board and/or senior management, requires a documented third-party risk-management framework, and makes clear that accountability for outsourced functions remains with the regulated entity. RI-3C: Alignment with and Coverage Across the Third-Party Relationship Lifecycle — Assesses whether the framework aligns with the third-party service relationship full lifecycle (planning and risk assessment, risk-based due diligence, contracting, ongoing monitoring, and termination/exit) and provides guidance on core third-party risk areas, such as: (i) contractual obligations; (ii) third-party supply-chains; (iii) third-party relationship registers; (iv) concentration risk; and (v) business continuity planning.

RI-3A: Proportionality

No third-party or outsourcing risk-management framework exists in published instruments; or a framework exists but applies uniformly with no recognition (in any instrument, at any evidence level) that third-party risk varies with the entity or the criticality of the relationship.

RI-3B: Governance

No third-party or outsourcing risk-management framework exists in published instruments; or no governance requirements for third-party or outsourcing risk are directed at financial entities in published law, regulation, or binding supervisory instruments.

RI-3C: Alignment with and Coverage Across the Third-Party Relationship Lifecycle

No third-party or outsourcing risk-management framework exists in published instruments; or the risk management framework does not align with an articulated third-party relationship lifecycle (or is not otherwise organized under some structural principle).

Proportionality is only referenced in general terms (e.g., a bare “risk-based approach” statement) without articulating the calibration factors or how obligations scale; proportionate treatment appears only in Level 4 guidance; or the framework in which proportionality operates is drafted for banks or prudential institutions and does not clearly reach non-bank fintechs (or reaches them only by generic, uncodified reference).

A general obligation to manage third-party or outsourcing risk exists, but responsibility is not assigned to the board or senior management; no documented third-party risk-management framework is required; and/or retained accountability of the regulated entity for outsourced functions is unstated. Regulatory requirements are drafted for banks or prudential institutions only and do not clearly reach non-bank fintechs.

The third-party risk management framework only addresses isolated lifecycle stages (e.g., due diligence at onboarding, with no ongoing monitoring or exit expectations) or applies only to formal “outsourcing” arrangements. The risk management framework does not provide any guidance across identified risk areas. Finally, the regulatory requirements do not clearly extend to non-bank fintechs (or reach them only by generic reference).

A framework exists at some level across Level 1–4 instruments. The framework is built upon proportionality as a principle: obligations apply based on the complexity (or risk-profile) of a regulated entity and/or the criticality or materiality of the third-party service relationship. At least one of the following gaps remain: The framework is only established in Level 4 instruments; While the regulatory framework identifies entity- and/or relationship-level factors (business model, complexity, risk profile, scale, structure) that impact the applicability of regulatory requirements/guidance, there is no guidance on how obligations scale and apply in practice; or The regulatory framework applies to some major non-bank fintech categories (e.g., PSPs and e-money institutions); however the scope of the regulatory framework is not clearly defined or at least one or more fintech categories is excluded without a documented risk-based rationale.

A framework exists at some level across Level 1–4 instruments. The framework assigns explicit responsibility for third-party risk management to the board and/or senior management, requires a documented third-party risk-management framework, and states that accountability for outsourced functions remains with the regulated entity, applying directly to the major non-bank fintech categories (at minimum PSPs and e-money institutions). At least one of the following gaps remain: The framework is only established in Level 4 instruments; or One or more fintech categories is excluded without a documented risk-based rationale.

A framework exists at some level across Level 1–4 instruments. The framework aligns with the full relationship lifecycle — planning and risk assessment, risk-based due diligence, contracting, ongoing monitoring, and termination/exit – and identifies core risk areas for regulated entities. The third-party risk management regulatory framework establishes clear expectations, applies to major non-bank fintech categories (e.g., PSPs and e-money institutions). At least one of the following gaps remain: The framework is only established in Level 4 instruments; The regulatory framework only covers core risk areas at a high level; The regulatory framework centers around outsourcing only, excluding material non-outsourcing third-party services without rationale; or One or more fintech categories is excluded without a documented risk-based rationale.

Core obligations are established in Level 1–3 instruments, as applied to in-scope fintechs. Proportionality is a core regulatory principle across the third-party risk management framework, such that (i) regulatory requirements are flexible based on a criticality or materiality basis; and (ii) the regulatory framework establishes a structure in which third-party risk (and thereby third-party risk management) may be commensurate with a fintech’s business model, complexity, cross-border operations, risk profile, scale, structure and size. Applicability is consistent across core fintech models (including digital lenders and CASPs where permitted), with any exclusion explicitly risk-based and documented.

Core obligations are established in Level 1–3 instruments, as applied to in-scope fintechs. The regulatory framework establishes all of the Score 2 elements and applicability is consistent across core fintech models, with any exclusion explicitly risk-based and documented.

Core obligations are established in Level 1–3 instruments, as applied to in-scope fintechs. The regulatory framework covers the full relationship lifecycle on a criticality basis and core risk areas are articulated with clear, implementable regulatory guidance; the scope of the regulatory framework extends beyond formal outsourcing to material third-party relationships generally; and applicability is consistent across core fintech models, with any exclusion explicitly risk-based and documented.

Score using publicly verifiable primary sources, classified by legal force and effect (i.e., does a failure to comply result in liability).

Primary legislation: laws related to financial services and payment services; laws and/or regulations that impose outsourcing or third-party requirements on financial entities (e.g., DORA as directly applicable EU regulation).

Binding subordinate legislation: outsourcing regulations, technology-risk standards, licensing conditions, mandatory notices (e.g., MAS Notice 658), regulatory technical standards on contractual and sub-outsourcing requirements.

Binding supervisory requirements: directives, notices, enforceable circulars (including cloud circulars), and codes or guidelines incorporated by reference into regulation.

Non-binding guidance: guidance notes, best-practice papers, supervisory expectations, FAQs, and discussion papers.

Scoring Notes

The RI-3 indicator score is the highest band whose conditions are met, subject to the cap below. Add the score from all sub-dimensions and assign the jurisdiction a Band.

Band 3: The combined score between the sub-dimensions is greater than or equal to 8 and a verifiable operationalization record exists (see Cap 1 below). For example, a jurisdiction with the following sub-dimension scores (and a verifiable operationalization record) should be scored at Band 3: RI-3A = 3; RI-3B = 3; RI-3C = 2 or above. Band 2: The combined score between the sub-dimensions is between 5 - 7 or the combined score is 8 or higher but a verifiable operationalization record does not exist (see Cap 1 below). For example, a jurisdiction with the following sub-dimension scores should be scored at a Band 2: RI-3A = 2; RI-3B = 2; and RI-3C = 1 or above. Band 1: The combined score between the sub-dimensions is between 1-4. In effect, third-party or outsourcing requirements exist in a published instrument, but the Band 2 conditions are not met (including because regulatory requirements apply to fintechs only by generic reference). Band 0: Absent — all three sub-dimensions score 0.

Sub-dimension scores should not be averaged. If a jurisdiction scores below Band 3, record why: the specific trigger not met, the binding sub-dimension, and/or the cap (if any) that applied. The three sub-dimensions should be scored independently and were designed to complement each other. For example, a criticality threshold cited as evidence of proportionality under RI-3A may also be the basis on which obligations apply throughout the third-party service lifecycle under RI-3C.

Cap 1: Evidence of Operationalization for a 3

A score of 3 requires evidence that the regulatory framework has been applied in practice to fintech’s third-party arrangements. Examples of an operationalized supervisory framework include evidence suggesting the relevant regulatory body actively administers the regulatory framework, such as the issuance of supervisory guidance; physical or digital offices / forums through which regulated entities can engage the regulator; evidence of supervisory actions; enforcement actions; online forums through which regulated entities may submit filing applications, reports, or complaints; and/or published inspection findings.

Core Risk Areas (RI-3C)

Historically, outsourcing and third-party risk management frameworks are designed to mitigate risks across a range of areas. Instead of mandating the risk areas that a regulatory framework should address, scorers should evaluate whether the regulator establishes clear expectations in Level 1–3 sources regarding risk areas that are relevant for the regulatory regime. Examples of core risk areas and controls include:

Contractual Obligations: Third-party and outsourcing risk management frameworks often include a minimum set of required contractual provisions for critical or material relationships, such as service descriptions and measurable service levels; security, confidentiality, and data-protection obligations, including data location and processing; provider business-continuity and incident obligations; conditions on sub-outsourcing (notification or consent, and flow-down of obligations); enforceable audit, access, and information rights for the regulated entity, its auditors, and its regulator; termination rights; and cooperation with the entity’s exit plan. Third-Party Supply Chains : Third-party risk management regulatory frameworks often provide guidance (and/or impose requirements) related to maintaining visibility into material supply chains (fourth- and n-th-party dependencies) supporting critical functions; conditions under which sub-contracting is permitted; downstream security, audit, and continuity obligations; and intra-group arrangements expressly within scope of the framework. Third-Party Relationship Registers: Some regulatory frameworks may, in certain circumstances, require regulated entities to maintain a register of third-party relationships (at minimum, critical ones), producible to the regulator on request. Concentration risk : Increasingly, third-party risk management frameworks include mechanisms by which concentration risk is identified and managed by regulated entities, including through entity-level assessment and reporting to regulators. Business Continuity Planning: Third-party risk management frameworks often require regulated entities to maintain documented exit strategies for critical service relationships, addressing both stressed and non-stressed exits, linked to the entity’s business continuity planning. Note, RI-3C only scores continuity for critical third-party service relationships.

Regulatory Structure and Scope

Note, regulatory requirements may not be clearly labeled as “third-party risk management” and/or otherwise be imposed through a complex series of regulatory requirements and expectations. For example, third-party risk management may be established in an outsourcing regime, an ICT third-party risk regime, a technology risk management framework, and/or general vendor-management guidance. A regulatory framework comprising various instruments (e.g., an outsourcing notice plus a cloud circular) should be scored on the consolidated regulatory framework, with any lack of clarity documented when uncertainty arises.

Entity Coverage

Entity coverage has been considered across each sub-dimension in the scoring rubric. For each sub-dimension, ask whether the instrument reaches in-scope entities (PSPs, e-money institutions, digital banks, digital lenders, and CASPs where permitted) specifically and by name or clear functional definition, rather than by generic extension of bank rules, and record which provider category is the binding constraint. Note, digital banks are adequately covered if/when the banking regime applies to them by charter or license.

Federal / Multi-Regulator Convention

For federal or multi-regulator systems, assess the dominant applicable regulatory framework for the entity category being tested and document which regime was scored. Where different regulators impose materially different outsourcing regimes on comparable entities, treat any unexplained fragmentation as a gap under the rubric.

single integer score 0–3. Three further 0–3 scales (evidence, applicability, outcome-based) are recorded alongside it, each under its own label.

RI-4

Incident Reporting Requirements and Timelines

Sub-dim C

Whether firms that are authorised, regulated or supervised in the financial services sector are required to report material ICT-related, cyber, security and operational incidents to the relevant authority under a clear, binding and proportionate framework. The indicator assesses whether the framework tells firms what must be reported, when it must be reported, to whom it must be reported, and what follow-up is required.

This standard is informed by established international frameworks and implemented supervisory models, including the FSB’s work on cyber incident reporting convergence and the Format for Incident Reporting Exchange (FIRE), the FSB Cyber Lexicon, BCBS Principles for Operational Resilience, CPMI-IOSCO cyber resilience guidance for financial market infrastructures, EU DORA, the EBA Guidelines on major incident reporting under PSD2, UK payment services and operational resilience materials, and MAS technology risk and incident reporting materials. It also reflects regulatory frameworks under the EU Markets in Crypto-Assets Regulation (MiCA), the UK FCA Payment Services and Electronic Money regimes, Hong Kong's virtual asset service provider licensing regime, and the broader EU payment services framework (PSD3 and the Payment Services Regulation (PSR))

The RI-4 standard considers whether firms that are authorised, regulated or supervised in the financial services sector are subject to a clear, binding and proportionate framework for reporting material ICT-related, cyber, security and operational incidents to the relevant authority, so that the regulator receives early, useful and sufficiently precise information about material incidents, without unduly burdening the firm’s operational processes for monitoring and identifying such incidents. The key difficulty is designing a system that is clear and stringent enough to be followed, but flexible enough to apply proportionately depending on the size, complexity, business model and risk profile of the firm.

Scores should be assigned holistically by reference to the criteria for each component. The criteria are not a numerical checklist and should not be averaged mechanically. A strong performance on one element should not compensate for the absence of a fundamental feature of an incident reporting regime.

Core Criteria. A framework should contain the following core criteria:

Scope of the framework: the framework applies to a broad set of firms that are authorised, regulated or supervised in the financial services sector, and captures a broad and non-exhaustive set of material ICT-related, cyber, security and operational incidents affecting the firm, its customers, its regulated services, or the wider financial system. This should include incidents involving outsourced, cloud, technology, infrastructure or other third-party services where they materially affect, or are reasonably likely to materially affect, the firm, its customers, its regulated services, or the wider financial system. The definition of reportable incident must be functional and non-exhaustive. Materiality and impact assessment: the framework contains proportionate materiality thresholds that assess both the nature of the reporting firm and the impact of the incident. This assessment must take account of the size, complexity, business model and risk profile of the firm, the criticality of the affected service, and the possible impact on customers, counterparties, market confidence or the wider financial infrastructure. Reporting process and content: the framework requires staged reporting with defined timelines. It must identify when the reporting clock starts, what information must be provided at each stage, and the reporting channel or authority to which the report must be submitted. Post incident review: Firms must review the incident, identify root causes and weaknesses, implement corrective and preventive measures, keep the relevant authority updated where required, and use lessons learned to strengthen their wider resilience arrangements. This should include appropriate senior management accountability and, where relevant, incidents involving outsourced, cloud, technology, infrastructure or other third-party services. The framework gives the competent authority power to request further information, challenge classification decisions, require or supervise remediation, and take appropriate supervisory or enforcement action where reporting obligations are breached or incidents reveal material weaknesses in the firm's risk management or operational resilience. It should also be supported by implementation materials or supervisory practice, such as templates, portal guidance, FAQs, supervisory guidance, statistics, thematic reviews or enforcement evidence.

The minimum content requirement should be proportionate to the reporting stage. Initial notifications may be based on information known or reasonably estimable at the time, while follow-up updates and final reports should provide more complete information as it becomes available.

Component A: Scope of the Framework

The framework must define both who is required to report and what must be reported.

The reporting obligation must apply to a broad set of firms that are authorised, regulated or supervised in the financial services sector. The standard should not depend on local labels or terms of art. It should not distinguish between traditional and digital firms where both provide technology-dependent financial services.

The framework must use a non-exhaustive, functional definition of reportable incidents. Reportability should be determined by reference to the effect of the incident, not by a closed list of event types.

A reportable incident is an ICT-related, cyber, security or operational event that has, or is reasonably likely to have, a material adverse effect on one or more of the following, in respect of the firm or the wider financial system:

availability of regulated financial services; continuity of critical or important business services; integrity of transactions, records, systems or data; confidentiality of customer, transaction or authentication data; safety of customer funds, assets or balances; ability of the firm or another relevant market participant to meet legal, regulatory, settlement or payment obligations; market confidence, consumer protection or financial stability.

Incidents involving outsourced, cloud, technology, infrastructure or other third-party services must be covered where they materially affect, or are reasonably likely to materially affect, regulated services, customers, transactions, data, funds, assets or the wider financial system. The reporting obligation should not depend on whether the incident began inside the firm or inside a third-party provider.

Component B:

Materiality and Impact Assessment. The framework must contain thresholds that allow firms to determine whether an incident is reportable. The thresholds must be clear enough to apply, but flexible enough to avoid over-reporting and to capture incidents whose significance comes from the role of the affected service in the wider financial system.

The framework must cover assessment of both:

the nature of the reporting firm, including its size, complexity, business model and risk profile; and the impact of the incident, including the importance of the affected service to the firm, its customers, counterparties, other market participants and the wider financial infrastructure.

The framework should require firms to assess the impact of an incident in a way that captures the following categories in substance:

Customer and user impact: the number or proportion of customers, clients or users affected, including the nature and severity of harm caused or likely to be caused. Service disruption and duration: the duration of the disruption or degradation, and the impact on the availability or continuity of critical or important services, functions or systems. Transaction and financial impact: the value or volume of transactions affected, including failed, delayed, erroneous or unauthorised transactions. Security, data and asset impact: unauthorised access to systems or networks; loss, compromise, corruption or unavailability of data; or compromise or suspected compromise of customer funds, assets, balances or credentials. Third-party and operational dependency impact: involvement of outsourced, cloud, technology, infrastructure or other third-party services, where that involvement materially affects the firm, its customers, regulated services or the wider financial system. Wider financial-system impact: geographic or cross-border impact, consumer protection impact, market confidence, financial stability, reputational impact, or impact on another relevant market participant.

An incident should be reportable where it has, or is reasonably likely to have, a material adverse effect in relation to one or more of the impact categories listed above.

Materiality should be assessed by reference to proportionate thresholds that combine, as appropriate:t

relative measures, such as the proportion of customers affected, proportion of transaction volume or value affected, proportion of critical services disrupted, severity ratings, criticality ratings or other measures assessing impact relative to the firm, the affected service or the wider financial system; absolute measures, such as the number of customers affected, duration of outage or service degradation, value or volume of transactions affected, number of failed or delayed transactions, or number of accounts, balances or systems affected; and qualitative factors, such as the sensitivity of data affected, compromise of customer funds, assets, balances or credentials, unauthorised access to systems, inability to meet regulatory, settlement or payment obligations, impact on a critical or important service, cross-border impact, market confidence, consumer protection or financial stability.

Those thresholds should be calibrated to the size, complexity, business model and risk profile of the firm, the criticality of the affected service, and the size, structure and complexity of the local financial system.

The mere engagement of one impact category should not automatically make an incident reportable. The question is whether the effect is material, assessed in context. However, an incident may still be material and reportable even if its impact appears limited when assessed by one measure, where the affected customer, data, service, asset or dependency is critical, or where the incident reveals a wider vulnerability. The framework must require the firm to document its classification decision, including the facts considered and the reason why the incident was or was not reportable.

Note:

Where a jurisdiction has separate incident reporting frameworks for different categories of regulated financial institutions, each applicable framework should be assessed in its own context, while the overall scoring should reflect the coherence, consistency, and completeness of the jurisdiction's incident reporting regime as a whole. Material gaps or inconsistencies between sectoral frameworks should reduce the overall assessment and should not be offset by stronger requirements in another sector.

Component C:

Reporting Process, Timelines, Content and Channels. The reporting process must include:

Initial notification: required when the firm has reasonable grounds to believe that a reportable incident has occurred or may be occurring. The initial notification must be made within a defined period and should contain the information reasonably available at the time. Follow-up update: required where there is a material change in the facts, impact, severity, affected services, third-party involvement, containment status or expected resolution. Final report: required after the incident is resolved or stabilised. It must contain root cause, actual impact, remediation, corrective and preventive measures, and lessons learned.

The framework must specify when the reporting clock starts. Acceptable triggers include awareness of the incident, reasonable grounds to believe the incident may be reportable, or formal classification as reportable. The trigger must be clear enough for firms to apply.

The framework must designate the reporting authority or channel in advance. This may be a supervisory portal, secure email address, incident reporting form, hotline or other specified mechanism.

Where more than one authority may have an interest in an incident, the framework should clarify the reporting route or interaction between obligations. This may include identifying the primary financial-sector reporting authority, explaining whether notification to one authority satisfies or is separate from notification to another, clarifying which timeline applies where obligations overlap, or providing for inter-authority coordination or information sharing.

The framework should prescribe the minimum content of incident reports. This means the core information that a firm must provide to the authority at each reporting stage, so far as known or reasonably estimable at the time, to allow the authority to understand the nature, severity, impact and status of the incident.

Minimum content should cover, in substance:

Firm and contact details: the reporting firm, responsible contact point and relevant internal reference details. Timing and status: when the incident was detected, classified and reported, and whether it is ongoing, contained, resolved or under investigation. Incident description: the nature of the incident, affected services, systems or business functions, and known or suspected cause where available. Impact assessment: known or estimated impact on customers, transactions, data, funds, assets, services, third parties or the wider financial system. Response and remediation: containment steps, remediation measures, communications made or planned, root cause where known, corrective measures and lessons learned.

Indicator-level anchor

No mandatory incident reporting framework exists for firms authorised, regulated or supervised in the financial services sector.

Component A

Scope of the Framework: no incident reporting framework exists.

Component B

Materiality and Impact Assessment: no incident reporting framework exists, or the framework contains no materiality threshold or impact assessment.

Component C

Reporting Process, Timelines, Content and Channels: no incident reporting framework exists, or the framework contains no defined reporting process.

An incident reporting framework exists, but it is not workable. It applies only to a narrow set of firms or incidents, reportable incidents are undefined or described only as “significant”, “material” or “serious”, timelines are absent or expressed only as “promptly” or “without delay”, or no reporting channel is identified.

Scope of the Framework: the framework applies only to a narrow set of firms or a narrow set of incidents, or uses undefined terms such as “significant incident” or “serious incident” without further criteria.

Materiality and Impact Assessment: the framework uses only undefined terms such as “material”, “significant” or “serious”, or uses a narrow or mechanical threshold that does not allow firms to assess the nature of the firm, the affected service or the impact of the incident.

Reporting Process, Timelines, Content and Channels: reporting is required only in general terms, such as “promptly”, “immediately” or “without undue delay”, with no defined deadline, clock-start point, reporting authority or minimum content requirement.

Binding incident reporting rules apply to a broad set of firms authorised, regulated or supervised in the financial services sector and include defined reportable-event triggers, a stated initial notification timeline, an identifiable reporting authority or channel, and some materiality or severity guidance. However, one or more important elements remains incomplete, such as proportional thresholds, staged reporting, third-party incident treatment, multi-authority coordination, supervisory follow-up powers or operational evidence.

Scope of the Framework: the framework covers a broad set of firms and a broad set of incidents, and includes defined criteria for reportability, but the criteria are not clearly proportionate to the firm’s size, complexity, business model, risk profile or role in the wider financial system.

Materiality and Impact Assessment: the framework includes defined materiality thresholds or impact criteria, but the assessment is incomplete, overly mechanical, insufficiently calibrated to the firm or local financial system, or does not adequately capture the potential impact on customers, regulated services, other market participants or the wider financial system.

Reporting Process, Timelines, Content and Channels: the framework includes a defined initial notification deadline and identifies a reporting authority or channel, but the process is incomplete. For example, it lacks staged reporting, does not specify when the reporting clock starts, gives limited guidance on report content, does not clearly require updates or final reporting, or does not address overlapping reporting obligations where these are likely to arise.

A comprehensive and operational incident reporting regime is in place. Binding requirements meet the RI-4 core criteria: broad incident and entity scope, proportional materiality thresholds calibrated to the firm and to the local financial system, mandatory impact-factor assessment, staged reporting, defined timelines, designated reporting channels, third-party incident treatment, supervisory follow-up powers and evidence of operational implementation.

Scope of the Framework: the framework applies broadly to relevant firms authorised, regulated or supervised in the financial services sector across all firms, covers a broad and non-exhaustive list of incidents, and applies reportability criteria proportionately by reference to the firm, the affected service and the potential impact on the wider financial system.

Materiality and Impact Assessment: the framework contains proportionate materiality thresholds and an impact assessment that captures the relevant impact categories in substance; assesses materiality by reference to the firm, the affected service and the wider financial system; uses, or is capable of taking into account, relative measures, absolute measures and qualitative factors; calibrates thresholds to the local financial system; avoids automatic reportability based on the mere engagement of a category.

Reporting Process, Timelines, Content and Channels: the framework provides a clear staged reporting process, including initial notification and follow-up updates or final reporting; specifies defined timelines and a clear clock-start point; designates the reporting authority or channel; prescribes minimum report content sufficient for the authority to assess the nature, severity, impact and status of the incident; clarifies the reporting route or interaction between obligations where more than one authority may be relevant; and allows information to be supplemented as it becomes available.

Primary sources to consult. Incident reporting regulations or circulars; financial services rules; banking, payments, lending, investment, market infrastructure, crypto-asset or other sectoral financial services rules; operational resilience rules; cyber or ICT risk-management rules; technology risk guidelines; official incident classification guidance; reporting forms, portals, templates or FAQs. The review should not be limited to bank-sector regulations and rules but should cover those designed specifically for non-bank and digital financial service providers, where applicable.

Scoring note. Score clarity, proportionality and usability. Do not score based on the shortest reporting deadline. A 72-hour timeline with clear thresholds and reporting mechanics is better than a 24-hour rule that leaves firms uncertain about whether an incident is reportable.

Component-based

Scores should be assigned holistically by reference to the criteria for each component. The criteria are not a numerical checklist and should not be averaged mechanically. A strong performance on one element should not compensate for the absence of a fundamental feature.

RI-5

Resilience Testing and Assurance Expectations

RI-5 assesses whether a jurisdiction's fintech-relevant regulatory framework requires regulated entities to validate their resilience and security arrangements through testing, and whether the results of that testing are subject to independent assurance and supervisory use.

The distinction from RI-1 is one of design versus proof. RI-1 assesses whether a jurisdiction requires entities to have resilience arrangements (governance, continuity plans, recovery objectives, dependency maps). RI-5 assesses whether a jurisdiction requires anyone to demonstrate that those arrangements actually work, and whether the resulting evidence reaches the board and the supervisor. A jurisdiction can score well on RI-1 with a framework that has never been exercised. RI-5 is the indicator that detects this.

As described further below, RI-5 is comprised of three sub-dimensions:

Testing Obligation and Coverage. A binding obligation to test exists, spans the distinct testing types needed to validate resilience, extends to third-party-supported services, and reaches non-bank fintechs (RI-5A); Proportionality and Calibration. The depth, type and frequency of testing scale with the entity's size, complexity and criticality, with a defined floor for smaller entities and a documented rationale where advanced testing is not required (RI-5B); and Assurance, Independence and Supervisory Use. Test results are independently validated, escalated to the board, tracked to remediation, and available to and used by the supervisor (RI-5C).

The goal of RI-5 is to evaluate whether testing happens, whether it is calibrated sensibly, and whether anyone acts on the results.

Written to international standard-setters, not to leading jurisdictions. The standard is drafted by reference to the international frameworks listed below. Named national testing regimes are used only as illustrations of how a requirement can be met, never as the requirement itself.

Terminology-neutral. Testing regimes are labelled differently across markets — threat-led penetration testing, intelligence-led red teaming, adversarial attack simulation, scenario testing, cyber drills, disaster recovery exercises. Scorers assess the function performed, not the label used, and do not mark a jurisdiction down for using different terminology or for drafting in a language other than English. Technology- and method-neutral. The standard takes no position on testing methodology, tooling, or whether testing is performed internally, by industry-coordinated exercise, or by external providers, provided the independence condition in RI-5C is satisfied. Proportionality is scored, not assumed. A smaller or less-mature market whose testing regime is appropriate to the entities actually operating in it is not marked down for omitting requirements that are not relevant to it, provided the regulator's rationale is documented. Absence of a requirement is not the same as a proportionate decision not to impose one. See the Proportionality Evidence Rule below.

A jurisdiction meets the RI-5 standard where its financial-sector framework requires regulated entities to maintain:

a binding, periodic testing programme covering recovery and continuity capability, technical security controls, and end-to-end scenario response; testing that extends to critical services delivered through or dependent on third parties, irrespective of whether the entity owns the underlying infrastructure; calibration of testing type, depth and frequency to the entity's size, complexity, business model, risk profile and the criticality of the service tested, with any exemption from advanced testing documented and risk-based; an independence condition ensuring that those who validate or assess results are functionally separate from those who own the systems and controls tested; escalation of results to the board or senior management, with identified weaknesses tracked to documented remediation and re-testing; and supervisory visibility and challenge, the supervisor can obtain, review and act on testing outcomes,

With the foregoing applying consistently across core fintech models (at minimum PSPs and e-money institutions, and including digital lenders and CASPs where permitted) and with any exclusion explicitly risk-based and documented.

RI-5A: Testing Obligation and Coverage — Assesses whether a binding obligation to test exists; whether it spans the three functionally distinct testing types (recovery/continuity validation, technical security and vulnerability testing, and end-to-end scenario or simulation exercises); whether it reaches critical services delivered through third parties; and whether it applies to non-bank fintechs rather than prudential institutions alone. RI-5B: Proportionality and Calibration — Assesses whether testing type, depth and frequency scale with entity size, complexity, business model, risk profile and service criticality; whether a defined baseline applies to smaller entities rather than exempting them entirely; and whether any exemption from advanced testing rests on documented, risk-based criteria rather than silence. RI-5C: Assurance, Independence and Supervisory Use — Assesses whether results are subject to independent validation; whether they are escalated to the board or senior management; whether findings are tracked to documented remediation and re-testing; and whether the supervisor can obtain, review and challenge testing outcomes, with evidence that it does.

Testing Types. (RI-5A)

Frameworks label these differently, and scorers assess function rather than nomenclature. A framework need not use three separate instruments, but it must address three functionally distinct questions:

Recovery and continuity validation — can the entity actually restore service within its stated objectives? Exercises of continuity and disaster recovery plans, failover testing, restoration testing against declared RTOs/RPOs. Technical security and vulnerability testing — do the controls hold? Vulnerability assessment, penetration testing, control effectiveness testing. End-to-end scenario or simulation exercise — does the organisation respond? Severe-but-plausible scenario testing, tabletop and live simulation, adversarial or threat-informed exercises, industry-coordinated drills. This is the type most frequently absent; a framework requiring only (1) and (2) is testing components, not resilience.

Forward-Looking Statement on AI-Assisted Operations and Post-Quantum Readiness Testing

The following are recorded as items for observation and future index development, rather than scored directly in the current version, as most domestic frameworks have not yet codified specific testing rules for these emerging risks:

Testing of AI and agentic system failure modes: Framework tracking evaluates whether testing programmes extend to autonomous or AI-assisted operational processes, including whether scenario exercises are required to cover model failure, agentic execution loops, degraded-mode operation on fallback to manual processes, and validation of human-override and circuit-breaker controls. A framework may require testing of AI-supported services under existing critical-service definitions without addressing AI-specific failure modes; this should be recorded as a coverage observation rather than scored. Post-quantum migration and cryptographic-agility testing: Framework tracking evaluates whether resilience testing expectations require entities to validate the accuracy of their cryptographic inventory and to exercise migration and rollback pathways for core clearing, messaging and authentication architectures, rather than treating post-quantum transition solely as a planning exercise.

No testing or assurance expectations directed at financial entities exist in published law, regulation, or binding supervisory instruments; or provisions are so ambiguous that a regulated entity cannot determine whether, what, or how often it must test. Entity-coverage test: No instrument references non-bank fintechs.

RI-5A

Testing Obligation and Coverage: No testing or assurance expectations directed at financial entities exist in published instruments; or a requirement is stated so ambiguously (e.g. that plans should be "kept up to date") that an entity cannot determine whether, what, or how often it must test.

RI-5B

Proportionality and Calibration: No framework exists; or testing obligations apply uniformly with no recognition, at any evidence level, that testing needs differ by entity or by service criticality.

RI-5C

Assurance, Independence and Supervisory Use: No requirements address what happens to test results; testing is required (if at all) with no stated consequence, reporting line, or follow-up.

No evidence found in Levels 1–4.

No regulated fintech provider is subject to resilience testing requirements.

No assurance that continuity, recovery or security arrangements have ever been validated.

Testing is encouraged or voluntary, appears only in Level 4 guidance, or rests on an industry-association framework the regulator has not mandated; or a binding obligation exists but covers only one testing type, typically continuity plan review. Assurance requirements are absent or limited to documentation and retention. Entity-coverage test: Requirements do not clearly reach non-bank fintechs, or reach them only by generic, uncodified reference.

Testing Obligation and Coverage: Testing is encouraged, voluntary, or addressed only in Level 4 guidance or an industry-association framework the regulator has not mandated; or a binding obligation exists but covers only one testing type (typically continuity plan review); or the obligation is drafted for prudential institutions and reaches non-bank fintechs only by generic or uncodified extension.

Proportionality and Calibration: Proportionality is referenced only in general terms (a bare "risk-based approach" statement) without articulating calibration factors or how obligations scale; or calibration appears only in Level 4 guidance; or proportionality operates in practice as a blanket exemption: smaller entities are carved out with no baseline obligation at all.

Assurance, Independence and Supervisory Use: Results must be "documented" or "retained" with no independence condition, no escalation route, and no remediation obligation; or assurance expectations appear only in Level 4 guidance; or the supervisor has no stated route to obtain or review testing outcomes.

Evidence only in Level 4, in an unmandated industry framework, or limited Level 1–3 provisions applying to banks or via generic reference.

Applies only to traditional banks and prudential institutions, excluding most non-bank fintechs.

Some entities test voluntarily, but coverage is fragmented, testing types are narrow, and results carry no consequence.

Binding requirements (Levels 1–3) impose periodic testing reaching at minimum PSPs and e-money institutions by name or clear functional definition, identify calibration factors, and establish board escalation and an obligation to remediate identified weaknesses. At least one significant gap remains: one of the three testing types is absent, most commonly end-to-end scenario or simulation exercise; testing of third-party-supported critical services is unaddressed; no independence condition attaches to validation; supervisory access to results is uncodified; or there is no verifiable operationalization record.

Testing Obligation and Coverage: A binding obligation (Levels 1–3) requires periodic testing and reaches at minimum PSPs and e-money institutions by name or clear functional definition. At least one of the following gaps remains: one of the three testing types is absent (most commonly end-to-end scenario or simulation exercise); testing of third-party-supported critical services is unaddressed; or one or more fintech categories is excluded without a documented risk-based rationale.

The framework identifies calibration factors (size, complexity, business model, risk profile, service criticality) and scales at least one dimension of testing (type, depth, or frequency) accordingly. A defined baseline applies to smaller entities. At least one of the following gaps remains: calibration factors are identified but no guidance is given on how obligations scale in practice; calibration exists only for frequency and not for testing type or depth; or exemptions from advanced testing are available without documented criteria.

Binding requirements establish an escalation route to the board or senior management and an obligation to remediate identified weaknesses. At least one of the following gaps remains: no independence condition attaches to validation or testing; re-testing of remediated weaknesses is not required; the supervisor's access to results is not codified; or no operationalization record exists (see Cap 2).

Binding requirements in Levels 1–3 exist, but are incomplete in testing coverage, calibration, independence, supervisory access, or operationalization record.

Regulated fintechs test periodically and escalate findings, but gaps remain in scenario response, third-party dependency testing, or independent challenge of results.

Binding requirements (Levels 1–3) establish all of: (i) periodic testing across all three testing types; (ii) express extension to critical services delivered through or dependent on third parties; (iii) calibration of testing type, depth and frequency to articulated entity- and service-level factors, with a baseline obligation retained for smaller entities; (iv) an independence condition separating validators from system and control owners; (v) board or senior-management escalation with remediation tracked to closure and re-testing; and (vi) codified supervisory access, review and challenge.

Operationalization requirement

A published thematic review, supervisory finding, coordinated sector exercise, or enforcement action demonstrating application to fintech resilience testing is required.

Testing Obligation and Coverage: Binding obligations (Levels 1–3) address all three testing types, expressly extend to critical services delivered through or dependent on third parties, and apply consistently across core fintech models, with any exclusion explicitly risk-based and documented.

Proportionality and Calibration: Calibration operates as a core principle across the testing framework: type, depth and frequency all scale by reference to articulated entity- and service-level factors; a baseline obligation applies to all in-scope entities regardless of size; and any exemption from advanced testing rests on published, risk-based criteria.

Assurance, Independence and Supervisory Use: Binding requirements establish all of: an independence condition separating validators from system and control owners; board or senior-management escalation; documented remediation tracked to closure with re-testing; and codified supervisory access, review and challenge powers. Supported by a verifiable operationalization record (see Cap 2).

Comprehensive, enforceable requirements in Levels 1–3, supported by an independence condition, codified supervisory access, and a verifiable operationalization record.

Regulated fintechs routinely validate resilience across recovery, security and scenario response, with independently assured results driving tracked remediation and supervisory challenge.

Evidence Tiers. Score using publicly verifiable primary sources, classified by legal force and effect (i.e., does a failure to comply result in liability).

Primary legislation: financial services acts, payment systems statutes, operational resilience legislation.

Binding subordinate legislation: regulations, technology risk standards, licensing conditions, mandatory notices.

Binding supervisory requirements: directives, enforceable circulars, binding supervisory handbooks, and codes incorporated by reference into regulation.

Non-binding guidance: guidance notes, best-practice papers, supervisory expectations, FAQs, and industry-association testing frameworks not mandated by the regulator.

Primary Sources to Consult. Supervisory handbooks; technology and ICT risk management guidelines; business continuity and operational resilience rulebooks; cyber resilience circulars; testing and assurance frameworks issued or mandated by the financial regulator; internal audit requirements; licensing conditions; published thematic reviews of testing outcomes.

The following international frameworks were utilised in drafting this standard:

Basel Committee on Banking Supervision (BCBS): Principles for Operational Resilience (March 2021), particularly on scenario testing of severe-but-plausible disruptions; Principles for the Sound Management of Operational Risk. Financial Stability Board (FSB): Effective Practices for Cyber Incident Response and Recovery, on testing and exercising response capability; Cyber Lexicon. CPMI–IOSCO: Guidance on Cyber Resilience for Financial Market Infrastructures, on testing programmes and the role of independent assurance. G7 Cyber Expert Group: Fundamental Elements for Threat-Led Penetration Testing; Fundamental Elements of Cybersecurity for the Financial Sector. European Union: Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, Chapter IV (Articles 24–27), covering testing programme requirements, testing of ICT tools and systems, advanced testing based on threat-led penetration testing, and requirements for testers. Referenced for structure; the standard is drafted to apply beyond DORA jurisdictions. NIST: Cybersecurity Framework 2.0 (Identify, Protect and Detect functions as they bear on control validation).

Illustrative national and industry testing frameworks, for calibration reference only and not as scoring benchmarks: TIBER-EU; UK CBEST; Singapore's adversarial attack simulation exercise guidelines; Hong Kong's iCAST; Saudi Arabia's FEER. Several of these are voluntary or industry-issued and would engage Cap 1 where not mandated by the regulator — the presence of a well-known testing framework in a jurisdiction is not by itself evidence of a binding obligation.

Scoring note. Do not require all three at maximum intensity for every entity. Require that the framework addresses all three and calibrates them under RI-5B. A framework silent on scenario response caps at 2 on RI-5A regardless of how detailed its penetration testing requirements are. Scoring notes. The RI-5 indicator score is the highest band whose conditions are met, subject to the caps below. Add the score from all sub-dimensions and assign the jurisdiction a Band.

Band 3: The combined score is greater than or equal to 8 and a verifiable operationalization record exists (see Cap 2 below). For example: RI-5A = 3; RI-5B = 3; RI-5C = 2 or above. Band 2: The combined score is between 5 and 7, or the combined score is 8 or higher but no verifiable operationalization record exists. For example: RI-5A = 2; RI-5B = 2; RI-5C = 1 or above. Band 1: The combined score is between 1 and 4. Testing requirements exist in a published instrument, but the Band 2 conditions are not met (including because requirements apply to fintechs only by generic reference). Band 0: Absent — all three sub-dimensions score 0.

Sub-dimension scores should not be averaged. Where a jurisdiction scores below Band 3, record the specific rubric trigger not met, the binding sub-dimension, and any cap that applied. Consistent with the RI-4 approach, strong performance on one sub-dimension does not compensate for the absence of a fundamental feature of a testing regime: a framework with sophisticated penetration testing requirements but no assurance or supervisory loop is not a mature testing regime.

Component-Cap 1: Binding Instrument Requirementbased

Testing expectations resting solely on Level 4 guidance, or on an industry-association testing framework that the regulator has referenced but not mandated, cap the relevant sub-dimension at 1 (Emerging). This mirrors the Reference-versus-Mandate Rule under RI-1 and is particularly consequential for RI-5, because several major markets locate their most sophisticated testing methodologies in voluntary or industry-led frameworks. The sophistication of a methodology is irrelevant where compliance with it is optional.

Cap 2: Operationalization Requirement for a 3

A score of 3 on RI-5C requires evidence that the assurance loop has been used in practice: a published thematic review of testing outcomes, supervisory findings on testing quality, a coordinated sector-wide exercise the supervisor convened or reported on, or enforcement action arising from testing failures. Actions directed solely at traditional banking organisations do not count; actions or reviews covering digital banks or other in-scope fintech categories do. A framework that is comprehensive on paper with no verifiable record of use should receive a score of 2.

Proportionality Evidence Rule

A jurisdiction that has deliberately calibrated its testing regime to the entities present in its market, and can point to a published rationale, scores as a proportionate framework. A jurisdiction that has simply not addressed advanced testing scores as a gap. The two are indistinguishable from the absence of a requirement alone; they are distinguishable by the presence of a documented regulatory rationale — a consultation response, policy statement, explanatory memorandum, licensing framework, or supervisory publication explaining the calibration decision.

Where a jurisdiction has no entities of the scale or criticality that would warrant advanced adversarial testing, and says so in a published instrument, RI-5B is scored on the calibration logic rather than on the presence of the omitted requirement. Where the record is silent, score the gap and document that no rationale was located.

Note for Working Group discussion: this rule may be worth generalising across the pillar. It addresses the same difficulty raised in relation to emergent regulatory frameworks under RI-3, and gives scorers an evidentiary test rather than a judgement call.

For each sub-dimension, ask whether the binding instrument reaches in-scope entities (PSPs, e-money institutions, digital banks, digital lenders, and CASPs where permitted) specifically and by name or clear functional definition, rather than by generic extension of bank rules, and record which provider category forms the binding constraint on the score. Digital banks are adequately covered where the banking regime applies to them by charter or licence.

Scoring note specific to RI-5: testing obligations are unusually prone to entity-coverage failure, because advanced testing regimes are frequently scoped by systemic-importance thresholds calibrated to bank balance sheets. A threshold that no domestic fintech could realistically cross should be recorded as an effective exclusion of the fintech sector, and the rationale (or its absence) assessed under RI-5B.

Multi-Regulator Convention

Testing obligations are frequently split between a financial regulator and a national cyber authority, and in some markets the operative methodology sits with an industry association. Assess the dominant applicable framework for the entity category being tested and document which regime was scored. Where a national cyber authority imposes testing obligations on financial entities that the financial regulator does not, score the consolidated framework and note the coordination gap. Unexplained fragmentation is a gap under the rubric.

Cross-pillar boundary note

Boundary Notes

RI-5 is drafted to sit alongside the adjacent indicators, and scorers should not double-count:

RI-1 (Operational Resilience Baseline). The existence of BCP/DR frameworks, RTOs/RPOs, critical service mapping and governance accountability is scored under RI-1. The requirement to exercise, validate and evidence those arrangements is scored here. RI-1 Component E carries a reciprocal boundary note offloading threat-led testing, vulnerability scanning and live simulation to RI-5. RI-2 (Cybersecurity Governance and Controls). The specification of a minimum control baseline is scored under RI-2. The requirement to test whether those controls hold under adversarial conditions is scored here. RI-3 (Third-Party Risk). Contractual audit and access rights, exit planning and concentration risk sit under RI-3. Whether the testing regime reaches into third-party-supported critical services; including the entity's right and obligation to test dependencies it does not own is scored here. RI-4 (Incident Reporting). Reporting of actual incidents sits under RI-4. Testing against simulated incidents sits here. Where a framework requires post-incident lessons learned to feed the testing programme, score the reporting obligation under RI-4 and the testing feedback loop under RI-5C.

Sub-dimension anchors

The indicator also carries anchors written per sub-dimension; each score cell holds one labelled block for each.

The same score is also rated on three further 0–3 scales — evidence, applicability and outcome-based. All sit together in each score cell, each under its own label.

RI-5 assesses whether a jurisdiction's fintech-relevant regulatory framework requires regulated entities to validate their resilience and security arrangements through testing, and whether the results of that testing are subject to independent assurance and supervisory use. The distinction from RI-1 is one of design versus proof. RI-1 assesses whether a jurisdiction requires entities to have resilience arrangements (governance, continuity plans, recovery objectives, dependency maps). RI-5 assesses whether a jurisdiction requires anyone to demonstrate that those arrangements actually work, and whether the resulting evidence reaches the board and the supervisor. A jurisdiction can score well on RI-1 with a framework that has never been exercised. RI-5 is the indicator that detects this. As described further below, RI-5 is comprised of three sub-dimensions: - Testing Obligation and Coverage. A binding obligation to test exists, spans the distinct testing types needed to validate resilience, extends to third-party-supported services, and reaches non-bank fintechs (RI-5A); - Proportionality and Calibration. The depth, type and frequency of testing scale with the entity's size, complexity and criticality, with a defined floor for smaller entities and a documented rationale where advanced testing is not required (RI-5B); and - Assurance, Independence and Supervisory Use. Test results are independently validated, escalated to the board, tracked to remediation, and available to and used by the supervisor (RI-5C). The goal of RI-5 is to evaluate whether testing happens, whether it is calibrated sensibly, and whether anyone acts on the results.

RI-6

AML/CFT Clarity for Digital Onboarding and Fintech Models

Whether an AML/CFT compliance framework clearly addresses the obligations of fintech entities for remote and digital customer onboarding (including CDD, eKYC, and digital identity acceptance), ongoing monitoring, suspicious transaction reporting, and the travel rule where applicable; whether supervisory guidance addresses fintech business model typologies; and whether law enforcement participates in real-time information-sharing and interdiction mechanisms alongside regulated entities.

The standard is written by reference to FATF as the primary international AML/CFT standard-setter, supplemented by IOSCO, BIS/CPMI, and FSB material where they address payment-system or market-infrastructure dimensions of digital finance. Jurisdictions are used only to validate and refine the standard at this stage rather than to score jurisdictions directly.

Technology-neutral and business-model-neutral

The standard asks whether a jurisdiction's AML/CFT framework gives fintech entities a clear, usable answer to their obligations for digital onboarding, ongoing monitoring, suspicious transaction reporting, and travel rule compliance. It takes no position on any specific onboarding technology, digital ID architecture, or messaging standard. Where a framework is silent on a novel onboarding method or asset class, that silence is a coverage gap, not a defect in the underlying policy stance.

A jurisdiction meets the RI-6 standard where its AML/CFT framework requires regulated fintech entities to maintain: (a) clear, risk-based rules for remote and digital customer identification and verification, including the conditions under which digital ID systems may be relied upon; (b) defined expectations for ongoing monitoring of digital-channel transactions; (c) suspicious transaction reporting obligations that are explicitly workable for digital and remote business models; (d) travel rule / payment-transparency obligations that clearly extend to virtual asset transfers and fintech payment chains, consistent with the revised FATF Recommendation 16; (e) supervisory guidance addressing fintech and VASP business-model typologies rather than only traditional bank models; (f) consistent applicability of the foregoing across core fintech models, with any exclusions explicitly risk-based and documented; and (g) participation by law enforcement in a real-time or near-real-time public-private partnership capable of interdicting illicit funds, alongside — not in place of — traditional STR-based reporting channels.

Component A: Digital and Remote CDD / eKYC Framework

The framework specifies when non-face-to-face identification and verification may be treated as standard or lower risk, rather than defaulting to enhanced due diligence for all remote onboarding. FATF's dedicated guidance in this space sets out that authorities and regulated entities should apply a risk-based approach to using digital ID systems for customer identification and verification, and clarifies that remote onboarding relying on reliable, independent digital ID systems with appropriate safeguards can present standard, or even lower, risk rather than automatically triggering enhanced scrutiny. The guidance is explicitly framed as supplementing Recommendation 10 on customer due diligence and Recommendation 17 on reliance on third parties, and covers both identity proofing at onboarding and the use of authentication for ongoing due diligence on the business relationship. A regulated entity that authenticates an existing customer through a digital ID system is encouraged to use the data generated by that authentication to support ongoing due diligence and transaction monitoring, not only fraud prevention. A jurisdiction scores well here where its own rules or guidance translate this FATF approach into binding or clearly enforceable expectations for PSPs, e-money institutions, and digital lenders — not only banks.

Component B: Ongoing Monitoring and STR Obligations for Digital Channels

The framework requires ongoing transaction monitoring calibrated to digital-channel risk indicators (device/IP data, behavioral anomalies, velocity patterns) and gives regulated fintechs a clear, workable trigger and process for filing suspicious transaction reports arising from digital or remote transactions. This component tracks FATF Recommendations 20 and 21 as applied to non-bank payment and virtual asset businesses. Because STR quality depends heavily on typology guidance, this component also asks whether the supervisor or FIU has published fintech- or VASP-specific red flags and case typologies, rather than leaving digital-channel STR filing to generic bank-oriented guidance.

Component C: Travel Rule / Payment Transparency Obligations

The framework requires the transmission of originator and beneficiary information with qualifying transfers, consistent with FATF Recommendation 16, and clearly states how this obligation applies to virtual asset transfers and VASPs.

FATF substantially revised Recommendation 16 at its June 2025 Plenary, with an October 2025 update publishing Annex IV to FATF's assessment methodology setting out how compliance with the revised standard will be assessed in mutual evaluations. Key substantive changes clarify which institution in a payment chain bears the initial data-collection responsibility: under the revised standard, the payment chain is treated as starting with the financial institution that receives the transfer instruction directly from the customer, with standardized information requirements applying from that point. The revisions are not self-executing — the revised requirements take effect by the end of 2030 and must still be adopted by individual jurisdictions.

On the virtual asset side specifically, implementation is real but uneven. In FATF's 2025 survey, 73% of responding jurisdictions — excluding those that prohibit or plan to prohibit VASP activity — reported having passed travel rule legislation. FATF has also clarified how the revised Recommendation 16 interacts with the VASP-specific framework: FATF has indicated it is not applying the travel rule directly to VASPs, but instead applying it to them indirectly through the tailored VASP framework, and has committed to publish further implementation guidance. A jurisdiction with published national guidance addressing the sunrise issue, messaging-standard interoperability, and threshold treatment should score above one that has legislated the rule but left these questions to individual firms.

Component D: Fintech and VASP Business-Model Typology Guidance

The framework — through the AML/CFT regulator, the FIU, or both — publishes guidance addressing fintech-specific business models (e-money issuance, payment initiation, digital lending, stablecoin issuance, VASP custody and exchange services) rather than treating all obligations as bank-rule extensions. This reflects FATF's continuing supervisory work tracking VASP and virtual-asset implementation globally, including its recurring targeted updates on Recommendation 15 compliance.

The requirements under Components A through D must sit in a binding or enforceable instrument, supported by a supervisory mechanism — examination, reporting, or an equivalent means of assessing compliance and taking corrective action. Non-binding FIU advisories alone do not satisfy this component.

Component F: Cross-Entity Applicability

Requirements apply consistently across PSPs, e-money institutions, digital lenders, and CASPs where permitted. Any exclusion of a provider category — including a full prohibition on VASP activity — is explicitly documented and risk-based, and the regulatory perimeter itself is clearly stated so that a firm can determine whether it is inside or outside scope.

Component G: Public-Private Partnership Membership and Real-Time Interdiction Capability

The framework supports, or the jurisdiction's law enforcement and financial intelligence authorities participate in, a public-private partnership capable of real-time or near-real-time information sharing between regulated fintechs/VASPs and law enforcement — not solely retrospective STR-based exchange through an FIU.

FATF has moved decisively toward endorsing this model. Its November 2025 guidance on virtual asset recovery promotes emerging public-private partnership models built for real-time crypto crime response, noting that these partnerships enable rapid information sharing between law enforcement and industry and accelerate the shift from detecting financial crime to disrupting it. In that same guidance, FATF pointed to specific operational examples of this model, citing the T3 Financial Crime Unit and TRM's Beacon Network as concrete illustrations of how public-private collaboration can function at operational speed, including T3's freeze of nearly USD 6 million connected to a pig-butchering scheme carried out with law enforcement across five continents. FATF has separately described T3 as a joint initiative among TRON, Tether, and TRM Labs that FATF recognized for its role in combating illicit activity across blockchain networks.

At its June 2026 Plenary, FATF approved a new global overview of public-private partnership models, finding at least 84 such partnerships operating worldwide, with more than 50 surveyed jurisdictions reporting at least one domestic PPP, and concluding that PPPs function as durable, effective tools against money laundering, terrorist financing, and proliferation financing when backed by a solid legal basis, clear governance, and real technological capability. FATF carried this work forward under the incoming UK Presidency, alongside a public consultation on new implementation guidance for the revised Recommendation 16.

A comparable government-anchored model exists in the US: the Illicit Virtual Asset Notification (IVAN) partnership brings together the FBI, US Secret Service, DEA, IRS Criminal Investigation, Army Criminal Investigation Division, US Postal Inspection Service, and the UK's National Crime Agency, alongside private-sector members, to share information on virtual-asset-enabled illicit activity and to identify and mitigate related threats. IVAN is described by its own board members as a global public-private partnership built specifically to let governments, law enforcement, and industry counter emerging criminal threats in real time.

No binding AML/CFT provisions address digital/remote onboarding, digital-channel STR, or the travel rule for fintech or virtual asset models; or provisions are too ambiguous for a regulated entity to determine its obligations. Entity-coverage test: no instrument reaches non-bank fintechs or VASPs.

No evidence in Levels 1–4 addressing digital onboarding or virtual asset travel rule.

No regulated fintech or VASP is subject to a stated obligation.

Firms cannot determine their digital-channel AML/CFT obligations; no assurance of consistent CDD, STR, or travel rule practice.

Partial rules exist — e.g., a general CDD obligation or a travel rule provision limited to traditional wire transfers — but at least one core element is missing: digital ID reliance conditions are unaddressed; VASP application of the travel rule is unaddressed or unclear; or fintech typology guidance does not exist. Requirements may rest only on Level 4 guidance.

Evidence only in Level 4, or limited Level 1–3 provisions applying to some entity types or via generic reference.

Applies only to banks or a single fintech category, excluding VASPs or most non-bank fintechs.

Some entities are covered, but fintech and virtual-asset business models operate with material uncertainty about digital onboarding and travel rule obligations.

Binding requirements (Levels 1–3) establish clear digital/remote CDD rules and a travel rule obligation that reaches VASPs, applying to most relevant fintech categories. At least one significant gap remains: e.g., no published fintech/VASP typology guidance; the jurisdiction has not begun transposing the 2025 Recommendation 16 revisions; sunrise-issue or messaging-interoperability treatment is unaddressed; or there is no verifiable operationalization record.

Binding requirements exist but are incomplete in digital ID reliance conditions, VASP travel rule specificity, or typology guidance.

Applies to several major fintech categories but excludes one or more significant categories (e.g., digital lenders, stablecoin issuers) without documented rationale.

Most regulated fintechs have workable digital CDD and travel rule obligations, but gaps in typology guidance or transition-readiness for the 2025 revisions create residual uncertainty.

Binding requirements establish all of: (i) risk-based digital ID / remote CDD rules consistent with FATF's digital identity guidance; (ii) ongoing monitoring and STR obligations explicitly workable for digital channels; (iii) a travel rule regime that clearly reaches VASPs and fintech payment chains, with a stated position on the 2025 Recommendation 16 revisions and the sunrise issue; (iv) published fintech/VASP typology guidance; (v) a supervisory review mechanism; and (vi) consistent, documented applicability across core fintech models, with any prohibition or exclusion clearly stated as a perimeter decision. A score of 3 also reflects Component G credit where a qualifying real-time PPP exists. Operationalization requirement: a published thematic review, typology report, or enforcement action addressing fintech/VASP AML/CFT compliance is required.

Comprehensive, binding requirements across CDD, STR, and travel rule, supported by published typology guidance and a verifiable operationalization record.

Applies consistently across PSPs, e-money institutions, digital lenders, and VASPs, with any prohibition or exclusion explicitly stated as a documented perimeter decision.

Regulated fintechs and VASPs can determine and meet their digital onboarding, STR, and travel rule obligations with confidence, subject to active supervisory oversight and (where applicable) law enforcement participation in real-time interdiction networks, producing predictable AML/CFT outcomes for digital financial services.

Primary Sources to Consult. AML/CFT legislation and regulations; FIU circulars and guidance; financial regulator AML guidance specific to fintech or digital channels; FATF Recommendations, Interpretive Notes, and Guidance documents.

Primary AML/CFT legislation.

Binding subordinate regulation — CDD rules, travel rule implementing regulations, VASP licensing conditions.

Binding supervisory instruments — FIU directives, enforceable circulars, mandatory typology reporting requirements.

Non-binding guidance — FIU advisories, supervisory FAQs, red-flag indicator papers. Entity-Coverage Test: For each requirement, ask whether the binding instrument reaches PSPs, e-money institutions, digital lenders, and VASPs by name or clear functional definition, rather than through generic extension of bank-oriented CDD rules. Record which provider category is the binding constraint on the score. Reference-versus-mandate Rule: Many jurisdictions reference FATF Recommendations or FATF guidance documents without transposing them into binding domestic obligations. A reference alone does not raise the score. Domestic transposition into binding CDD, STR, or travel rule rules is required for a score above 1. Travel Rule Currency Test: Given the active 2025–2030 transition period, scorers should record whether a jurisdiction's travel rule regime reflects the pre-2025 Recommendation 16 framework, has begun transposing the 2025 revisions, or remains silent on virtual assets entirely. A jurisdiction actively transposing the revised standard ahead of the 2030 deadline should not be penalized relative to one that has done nothing, even though both may currently be "compliant" with the un-revised text. Operationalization Requirement for a Score of 3: A top score requires evidence the framework has been applied in practice — a published FIU typology report addressing fintech/VASP models, a supervisory thematic review of digital onboarding or travel rule compliance, or an enforcement action — not merely the existence of the rule.

Scoring note. This indicator measures the clarity and coverage of obligations — not whether the AML/CFT regime is "strict" or produces good outcomes. A jurisdiction with proportionate, well-explained digital AML obligations scores as well as one with extensive but unclear requirements. Scoring criteria. To score under this component (Component G), a qualifying partnership should demonstrate: standing law enforcement membership — a defined seat and defined access rights for a police, cybercrime, or financial-crime authority, not an ad hoc liaison arrangement; real-time or near-real-time operating tempo — architected to move from a shared alert to a freeze, hold, or interdiction request while funds are still traceable and recoverable, not only after the fact; a documented legal basis for the sharing — data protection and tipping-off constraints addressed by statute, MOU, or regulatory gateway rather than informal practice; fintech and VASP inclusion, not banks alone. Scoring treatment: This is a modifier within RI-6 rather than a standalone weighted indicator. A jurisdiction otherwise scoring 2 elsewhere in RI-6 that also has law enforcement in a qualifying real-time PPP moves to 3. A jurisdiction otherwise scoring 3 without one does not move down — this is additive credit for a documented practice, not a penalty for its absence, since only a minority of surveyed jurisdictions currently report even one domestic PPP.

single integer score 0–3 on the main rubric.

RI-6 and RI-7 share a single 20% weighting in the source document. RI-6 and RI-7 share a combined 20% weight (RI module, Section 4).

The Resilience & Integrity pillar assesses whether a jurisdiction's fintech-relevant regulatory framework is designed to keep digital financial services safe, reliable, and trustworthy. It evaluates operational resilience expectations, cybersecurity governance, third-party and cloud risk controls, incident reporting requirements, and AML/CFT regime quality for digital channels — so that fintech innovation can scale without creating unacceptable systemic, consumer, or crime risks.

Draft international best-practice standard. A jurisdiction meets the RI-1 standard where its financial-sector framework requires regulated entities to maintain: - Board- and senior-management accountability for operational resilience and continuity; - Documented continuity frameworks integrated with either quantitative Recovery Time Objectives (RTOs) or defined impact tolerances for severe but plausible disruptions; - Identification and mapping of critical business functions/important business services, internal sub-processes, and external dependencies; and - Mechanisms for supervisory review and challenge, with all of the foregoing applying consistently across entities in scope.

Applies only to traditional banks/prudential institutions, excluding most non-bank fintechs.

Binding requirements (Levels 1-3) clear the Resolution Gate by establishing BOTH: 1. Explicit applicability extending directly to non-bank PSPs and e-money institutions; and 2. Binding operational minimums including C-suite/board governance accountability, mandatory BCP/DR frameworks, and defined numeric RTOs. At least one significant gap remains: critical service mapping is absent; supervisory review mechanisms are uncodified; or there is no verifiable operationalization record.

Binding requirements (Levels 1-3) clear the Resolution Gate by establishing BOTH: 1. Explicit applicability extending directly to non-bank PSPs and e-money institutions; and 2. Binding operational minimums including C-suite/board governance accountability, the identification of important business services, and the setting of defined impact tolerances for severe but plausible disruptions. At least one significant gap remains: end-to-end dependency mapping is absent; scenario testing expectations are uncodified; or there is no verifiable operationalization record.

Binding requirements (Levels 1-3) establish all of: (i) Explicit board/senior-management accountability; (ii) A mandate to ensure important business services can remain within defined impact tolerances under severe but plausible scenarios; (iii) Mandated resource and dependency mapping for all identified important business services; (iv) Interactive supervisory review and challenge mechanisms;< and (v) Explicit, consistent applicability across core non-bank fintech models. Operationalization requirement: A published supervisory thematic review, enforcement action, or public assessment demonstrating application to fintech operational resilience is required.

Two paths: rules-based and outcomes-based (principles)

Financial regulators frequently reference soft-law principles without mandating them. A reference alone or a non-binding guidance paper (Level 4) caps the score at 1 (Emerging). Transposition into binding domestic instruments (Levels 1-3) is required for a score of 2 or higher.

Direct — single integer score 0–3. The same score is also rated on three further 0–3 scales — evidence, applicability and outcome-based. All four sit together in each score cell, each under its own label.

Sub-dim B

Sub-dim D

Sub-dim E

AML/CFT and Integrity Controls for Digital Finance

Sub-dim F

RI-6 — AML/CFT and Integrity Controls for Digital Finance

Whether an AML/CFT compliance framework clearly addresses the obligations of fintech entities for remote and digital customer onboarding (including CDD, eKYC, and digital identity acceptance), ongoing monitoring, suspicious transaction reporting, and the travel rule where applicable; whether supervisory guidance addresses fintech business model typologies; and whether law enforcement participates in real-time information-sharing and interdiction mechanisms alongside regulated entities. Where crypto-asset service providers (CASPs) are permitted to operate, RI-6 also assesses whether the jurisdiction has a clear, binding, and implementable CASP integrity framework covering the regulatory perimeter, custody and safeguarding, client-asset segregation and insolvency protection, governance and conflicts of interest, and market-integrity requirements. CASP-specific cybersecurity and operational-resilience requirements are assessed only for scope/applicability here; their substantive content remains assessed under the relevant RI resilience and cybersecurity indicators.

No binding legal, regulatory, or supervisory framework meaningfully governs fintech or CASP/VASP activity. This includes the absence of clear AML/CFT requirements for digital or remote onboarding, digital-channel STR obligations, payment-transparency/travel-rule requirements, or a defined CASP regulatory perimeter. The framework is absent, materially incomplete, or so ambiguous that regulated entities cannot determine whether they are covered, what obligations apply, or whether the activity is permitted, prohibited, or left in an unaddressed gap. Ad hoc, informal, or unenforceable measures do not qualify as a sufficient framework. Entity-coverage test: No binding instrument clearly reaches non-bank fintechs, VASPs, or CASPs, or defines their regulatory status and applicable obligations.

No evidence in Levels 1–4 of binding provisions addressing digital onboarding, digital-channel AML/CFT obligations, virtual-asset travel-rule requirements, or a regulatory framework applicable to CASPs.

No regulated fintech, VASP, or CASP is subject to a clearly stated and enforceable set of obligations; the regulatory perimeter is absent, undefined, or materially ambiguous.

Firms cannot reliably determine their digital-channel AML/CFT obligations, creating no assurance of consistent CDD, STR, payment-transparency, or travel-rule practices. Users of crypto-asset services likewise lack predictable protection against custody failures, asset misappropriation, market manipulation, or insolvency-related loss, including assurance that client assets are segregated and recoverable.

Partial legal, regulatory, or supervisory requirements exist, but material gaps, uncertainty, or fragmented coverage remain. For fintech AML/CFT, this may include a general CDD obligation or payment-transparency/travel-rule provision that does not clearly address digital or remote onboarding, digital-ID reliance conditions, digital-channel STR obligations, VASP/CASP application of the travel rule, or fintech-specific typologies. Requirements may depend principally on Level 4 guidance rather than binding Levels 1–3 instruments. For CASPs, a licensing or registration regime may exist, but the regulatory perimeter or integrity framework remains materially incomplete, unclear, or unusable. At least three of the six core CASP components are missing, materially deficient, or present only at Level 4—for example, custody requirements do not extend beyond a general safekeeping obligation, no client-asset segregation rule is in force, or market-integrity requirements do not extend to CASPs. Proposals or consultations not yet in force do not raise the score above Level 1. Cap — Where CASP activity is permitted, an absent, materially unclear, or unusable CASP regulatory perimeter, or the absence of a meaningful CASP integrity framework, caps RI-6 at 1. Entity-coverage test: Binding requirements reach only some relevant entities or activities—for example, banks or a single fintech category while excluding VASPs or most non-bank fintechs, or only certain CASP activity types or asset classes without a documented risk-based rationale for the exclusions.

Evidence exists only at Level 4, or Levels 1–3 contain limited or generic provisions covering only some fintech entities, AML/CFT obligations, CASP activities, or components of a CASP regulatory framework.

Some fintechs, VASPs, or CASPs are subject to defined requirements, but significant entity types, activity categories, asset classes, or digital-channel obligations remain outside the framework or are subject to materially unclear rules.

Some entities are covered, but material uncertainty remains about digital onboarding, CDD, STR, or travel-rule obligations. Where CASPs are permitted, firms cannot reliably determine applicable CASP integrity obligations, or users lack a meaningful and predictable baseline of protections relating to custody, client-asset segregation, market integrity, or insolvency.

Binding legal, regulatory, or supervisory requirements in Levels 1–3 establish clear digital/remote CDD, monitoring/STR, and payment-transparency/travel-rule obligations for most relevant fintech and VASP/CASP categories, supported by supervisory mechanisms. For CASPs, a clear authorization or licensing perimeter exists and several core integrity components are addressed, including governance/fit-and-proper requirements and custody or safeguarding obligations. However, one or more significant gaps remain in entity coverage, digital-ID reliance conditions, fintech/VASP typology guidance, transition treatment for the 2025 Recommendation 16 revisions, sunrise or messaging-interoperability issues, operationalization, client-asset segregation and insolvency treatment, market integrity, cybersecurity/operational resilience, or supervisory enforcement. Cap — Where CASPs are permitted and the perimeter is clear but one or more significant gaps remain in custody/safeguarding, segregation/insolvency, governance/conflicts, market integrity, cybersecurity/operational resilience, or demonstrated implementation, the CASP sub-dimension caps RI-6 at 2. Entity-coverage test: Binding requirements apply to most major fintech and CASP activity types, but one or more significant categories—such as digital lenders, stablecoin issuers, or particular CASP services—remain excluded without a documented risk-based justification.

Binding Levels 1–3 requirements establish workable digital CDD, monitoring/STR, travel-rule, and CASP authorization frameworks, but documented gaps remain in one or more areas such as digital-ID reliance, VASP travel-rule specificity, typology guidance, asset segregation, market integrity, cyber coverage, or operationalization.

Most relevant fintechs, VASPs, and licensed CASPs are subject to defined and enforceable obligations, but coverage is not yet comprehensive across all significant entity types, activities, or operational scenarios.

Most regulated fintechs have workable digital CDD, STR, and travel-rule obligations. Where CASPs are permitted, users receive several core integrity protections, but remaining gaps in custody, client-asset segregation and insolvency treatment, governance, market integrity, cyber resilience, or implementation leave firms or users exposed in specific failure scenarios.

Binding legal, regulatory, and supervisory requirements in Levels 1–3 establish a comprehensive, risk-based framework for fintech and CASP/VASP activity. For fintech AML/CFT, this includes: (i) clear digital-ID and remote CDD/eKYC requirements consistent with FATF digital-identity principles; (ii) ongoing monitoring and STR obligations that are explicitly workable for digital channels; (iii) payment-transparency/travel-rule requirements that clearly reach VASPs and relevant fintech payment chains, including a stated position on the 2025 Recommendation 16 revisions and sunrise/interoperability issues; (iv) published fintech/VASP typology guidance; (v) supervisory review mechanisms; and (vi) consistent, documented applicability across core fintech models, with any prohibition or exclusion clearly stated as a perimeter decision. For CASPs, the framework must also establish a clear regulatory perimeter and binding, usable requirements for custody/safeguarding, client-asset segregation and insolvency protection, governance/fit-and-proper standards and conflicts management, cybersecurity and operational resilience, incident reporting, and market-integrity controls covering conduct such as manipulation, wash trading, insider dealing, and front-running. A score of 3 requires a verifiable operationalization record, such as a published thematic review, supervisory examination, typology report, or enforcement action demonstrating application of the framework in practice. Component G may provide additive credit only where no Component H cap applies. Cap — A score of 3 is not available where a material Component H deficiency remains. An undocumented or unjustified CASP carve-out, incomplete regulatory perimeter, material gap in custody/safeguarding, segregation/insolvency protection, governance/conflicts, cybersecurity/resilience, market integrity, or absence of verifiable operationalization caps RI-6 at 2. Level 4 evidence alone cannot support a score of 3. Entity-coverage test: For each requirement, ask whether the binding instrument reaches PSPs, e-money institutions, digital lenders, CASPs, VASPs by name or clear functional definition, rather than through generic extension of bank-oriented CDD rules. and other permitted digital-finance models. Record which provider category is the binding constraint on the score.

Comprehensive binding requirements are established in Levels 1–3 across digital CDD, monitoring/STR, travel-rule, CASP authorization, custody, segregation, governance, cyber/resilience, and market integrity, supported by published supervisory or typology guidance and a verifiable record of implementation or enforcement. Level 4 evidence may supplement but cannot independently justify this score.

Requirements apply consistently and with sufficient legal certainty across permitted fintech and CASP activity types. Firms can identify whether they are in scope, which obligations apply, and how those obligations operate in practice. Any prohibition, exclusion, or carve-out is explicitly documented, risk-based, and proportionate.

Regulated fintechs can determine and meet their digital onboarding, monitoring, STR, and travel-rule obligations with confidence. Where CASPs are permitted, users benefit from predictable custody, client-asset segregation and insolvency protections, governance safeguards, cyber-resilient operations, and enforceable market-integrity protections under active supervisory oversight.