AI on Guidance on Cyber Resilience for Financial Market Infrastructures for Operations teams at Payment Institutions firms in international jurisdictions

Executive Summary

The CPMI-IOSCO Cyber Resilience Guidance for Financial Market Infrastructures is a foundational reference for Operations teams at Payment Institutions firms building and validating their cyber resilience frameworks — particularly the Response and Recovery phase. When those teams turn to AI tools to map the 2016 guidance's requirements against their internal incident response and recovery playbooks, the AI consistently overstates the operational detail the document actually contains.

Across the finding examined here, AI assistants answered confidently that the 2016 guidance provides detailed, specific operational expectations for incident response and recovery — and did not flag the four-year gap until the FSB's 2020 guidance filled it. A team acting on that answer would scope their controls mapping, BCP alignment work, or regulatory gap assessment against an incomplete source, while unknowingly omitting the more operationally specific FSB 2020 document entirely.

How AI gets this regulation wrong

The failure pattern on this regulation centres on AI tools confidently overstating the operational depth of the 2016 CPMI-IOSCO guidance — presenting it as a self-contained, detailed operational specification when it is in fact a high-level framework with significant operational detail deferred to a later document. When challenged, the AI acknowledges the gap, but by then the damage to a deliverable is already done. The table below breaks down the specific failure mode and how it presented in testing.

What that means for your team

The operational risk for Payment Institutions here is a wrong deliverable — a gap analysis, controls mapping, or incident response framework scoped against the wrong version of the regulatory picture. For an Operations function accountable for BCP, RTO compliance, and third-party incident response, anchoring on an incomplete source translates directly into controls that satisfy an older, higher-level standard while missing the more granular operational expectations regulators and counterparties now apply. The table below maps that exposure to your team's specific workflow touchpoints.

When this affects your department

Operations teams at Payment Institutions reach for AI on this regulation most often during three types of work: scoping an internal cyber resilience programme against the CPMI-IOSCO framework, preparing or validating incident response and recovery documentation ahead of a regulatory review or audit, and benchmarking the firm's current RTO/RPO commitments and secondary-site arrangements against what the guidance requires.

In each case, a junior analyst or contractor is likely to frame the initial query as a straight question about what the 2016 guidance specifies — without necessarily knowing that operational detail for the Response and Recovery phase was elaborated in a later document.

The gap matters because the 2016 guidance and the FSB 2020 document are not interchangeable. The 2016 CPMI-IOSCO text sets out the framework; the FSB 2020 guidance operationalises the Response and Recovery phase in considerably more granular terms. A gap analysis that treats the 2016 document as the complete picture will identify fewer control gaps, produce a shorter remediation list, and miss obligations that regulators and their supervisory counterparts increasingly reference from the 2020 document.

If the firm's incident response playbook, BCP annexes, or third-party resilience requirements are written or reviewed against the AI's characterisation of the 2016 guidance as "detailed", those documents will be calibrated to a lower standard than the full regulatory picture supports.

The reputational and regulatory exposure is not abstract. Payment Institutions operating internationally face scrutiny from multiple competent authorities, many of which now reference the FSB 2020 practices either directly or through local supervisory expectations. Presenting an incident response framework in a supervisory engagement — or to a correspondent bank, settlement agent, or scheme operator running their own third-party resilience programme — that is visibly anchored only to the 2016 document will invite questions. And if the gap surfaces during a live incident response or post-incident review, the firm loses the opportunity to correct it on its own terms.

The findings at a glance

The finding below captures the specific question an Operations team would ask, what the AI said, and what the regulation actually requires — illustrating precisely where the overstatement occurs and what correct answer looks like.

Aggregate impact

The single finding from this regulation tells a consistent story: AI tools treat the 2016 CPMI-IOSCO Cyber Guidance as a complete, operationally detailed specification for incident response and recovery, when the document is better characterised as a high-level framework that a later, separate publication — the FSB's 2020 guidance on effective practices for cyber incident response and recovery — fills in with operational specificity. The AI's failure is not a misread of a single clause; it is a systematic miscalibration about the document's position within the broader cyber resilience regulatory architecture.

For Operations teams at Payment Institutions, that miscalibration clusters precisely on the area they care about most: the Response and Recovery phase. The 2hRTO expectation, secondary site requirements, communication protocols, and recovery planning are the operational anchors that BCP owners, incident response leads, and third-party resilience managers build their frameworks around. The AI confirms those elements as "detailed" in the 2016 document and does not surface the FSB 2020 gap-filling role — meaning the team ends up with a false sense of coverage and an incomplete source set.

The systemic risk is that this is a hard error to catch in review. A reviewer checking the AI-assisted output against the 2016 document will find the listed elements are present in that text — because they are. The error is the omission of the FSB 2020 layer, which a reviewer who is not already familiar with the full regulatory stack may not think to verify independently. The gap therefore has a real probability of surviving internal quality control and reaching the final deliverable.

What your team should do

The default position on this regulation: do not use AI-generated output as the sole basis for mapping the firm's cyber incident response and recovery framework against the regulatory requirements. The 2016 CPMI-IOSCO guidance and the FSB 2020 document need to be read together, and the AI will not reliably tell you that — it will present the 2016 text as sufficient. Any regulatory mapping exercise, gap analysis, or controls assessment that relies on AI assistance must explicitly verify that the source set includes both documents before the output is used.

In practice, the safeguard is structural rather than per-query. The Operations team's standard source list for cyber resilience work should include the FSB 2020 guidance as a named item alongside the 2016 CPMI-IOSCO text. If that list is codified in your regulatory mapping framework, taxonomy, or programme methodology document, AI-assisted work done by a junior analyst will at least be checked against a predefined source inventory — reducing the probability that the FSB 2020 gap survives into a final deliverable without a human spotting the omission.

AI tools are safe to use on this regulation for lower-stakes tasks: summarising the CPMI-IOSCO framework's five components, generating a first-draft table of contents for an incident response policy, or explaining the relationship between cyber resilience and operational resilience at a conceptual level. The risk zone is any output that makes an assertion about the operational completeness or sufficiency of the 2016 document — that is precisely where the AI overreaches, and where a peer review against the actual document set is not optional.

How RLB Can Help

RegLeg's published Hallucination Research gives your team a concrete pre-flight check before trusting AI output on regulatory questions. If your Operations function is already using AI assistants to interpret settlement finality rules, cross-border transfer restrictions, or safeguarding obligations under multiple licensing regimes, the research tells you exactly where those tools have demonstrably failed on comparable material — wrong thresholds, inverted obligations, fabricated regulatory references — so you can calibrate which outputs warrant a primary-source check before they feed into a procedure or a control narrative.

For firms carrying higher AI exposure — multi-jurisdiction licensing stacks, complex correspondent arrangements, or frequent regime changes from post-implementation guidance — we run bespoke deep-dives scoped specifically to your Operations workflows. That means mapping your AI-assisted processes against the failure modes most relevant to payment institutions: misread e-money versus payment institution treatment distinctions, hallucinated capital or safeguarding figures, compressed or conflated notice periods across regulators. The output is a prioritised risk register your Head of Operations and compliance function can act on directly, not a generic AI risk framework.

We also work with Operations teams on two practical follow-ons: a confidential review of your existing AI-use policy against our failure-mode catalogue — identifying gaps in your escalation logic, human-review triggers, and record-keeping for AI-assisted regulatory interpretation — and CPD-aligned training material your team can use internally to build calibrated judgement on AI output quality in high-stakes regulatory contexts. Both are designed to be integrated into your existing governance structure rather than run as standalone programmes.