AI on Promoting the Harmonisation of Application Programming Interfaces to Enhance Cross-Border Payments: Recommendations and Toolkit for Technology & Data teams at Retail Banking firms in international jurisdictions

Executive Summary

Technology & Data teams at retail banks across international jurisdictions are actively engaging with the CPMI October 2024 API harmonisation report as the primary reference for scoping cross-border payment API programmes — both in designing internal readiness assessments and in planning ISO 20022 technical implementations tied to the updated data requirements. Across two distinct questions put to AI tools on this regulation, both produced substantively wrong answers that would have fed directly into technical deliverables.

One AI fabricated the internal structure of the CPMI self-assessment toolkit — inventing a four-area assessment framework complete with named coverage areas, assessment dimensions, and a step-by-step usage process, none of which correspond to any publicly accessible source describing toolkit contents. A second AI misattributed the publication date of the updated ISO 20022 harmonised data requirements document and fabricated specific data entity breakdowns for its technical annex, sourcing the error to a third-party aggregator article rather than the primary BIS publication.

In both cases, the AI produced confident, structured output that read as authoritative — exactly the format a technology team would carry forward into API architecture decisions, gap analyses, or regulatory reporting without checking the primary source.

How AI gets this regulation wrong

The failures AI tools produced on this regulation split between two patterns: inventing regulatory content outright when the source document is inaccessible, and pulling from secondary aggregator articles that contain errors — then presenting both with equal confidence. What makes these particularly difficult to catch is that in one case the AI only acknowledged its uncertainty after being challenged, while in the other it falsely attributed its fabricated content to confirmed public summaries of the very document it couldn't access.

What that means for your team

Both failures in this cell land in the same place operationally: a wrong deliverable that carries the error forward into downstream technical work. For a technology and data function, that means API readiness assessments scored against non-existent criteria, implementation roadmaps anchored to a wrong document version date, and data model designs built on fabricated technical annex content — all before the error surfaces through a source check or a counterparty challenge.

When this affects your department

A technology and data team in an internationally-operating retail bank touches this regulation at two distinct pressure points. The first is API programme scoping: as correspondent banking relationships and cross-border payment rails evolve toward CPMI-aligned API standards, the technology team is typically the function tasked with translating CPMI recommendations into an internal readiness picture — which APIs need to be rebuilt, which need to be extended, what standards the vendor stack needs to meet.

The CPMI self-assessment toolkit is exactly the kind of structured framework a technology team would hand to a payments architect or a vendor manager as an evaluation checklist, and it is the most natural object to summarise via an AI assistant during the scoping phase.

The second pressure point is ISO 20022 technical implementation. The February 2026 update to the CPMI-PMPG harmonised data requirements is a live technical reference for any bank implementing or updating ISO 20022 message flows — the updated data model and expanded technical annex directly shape decisions about data entity mapping, field population, and system-to-system validation logic. Technology architects pulling AI-generated summaries of what changed between the 2023 original and the updated document are making architecture decisions based on that summary, often before they have had time to read the primary source in full.

In both situations, the consequence of an AI error is not an abstract compliance risk — it is a concrete wrong output that circulates inside the team before anyone verifies it. A wrongly-scoped API readiness assessment built on a fabricated toolkit structure will consume sprint capacity and vendor evaluation time before the gap is discovered. A data model specification built on fabricated technical annex content may need to be unwound at the integration testing stage, when remediation costs are at their highest.

For an internationally-operating retail bank, where cross-border payment infrastructure changes touch correspondent relationships, treasury operations, and trade finance simultaneously, the blast radius of a technical design error sourced from AI extends well beyond the Technology & Data function.

The findings at a glance

The two findings below cover the AI failures our testing surfaced on this regulation, both of which produced wrong deliverable risk for technology and data teams at retail banks.

Aggregate impact

Both findings cluster on the same underlying problem: the CPMI October 2024 API harmonisation report's core technical outputs — the self-assessment toolkit and the updated ISO 20022 data requirements annex — are not accessible to AI tools in any reliable form. The report landing page confirms a toolkit exists; the actual toolkit content is not publicly described in any source AI can read. The ISO 20022 updated document exists on the BIS site, but secondary aggregator articles — which AI tools do access — contain errors including a wrong publication date.

The result is a regulation where AI appears fluent precisely because it can see enough of the scaffolding to generate confident-sounding structure, but cannot see the substance, and fills the gap with fabrication.

For technology and data functions, this is the worst-case AI failure profile. A vague non-answer is easy to catch and easy to escalate. A detailed, structured answer — a named four-area framework, a step-by-step usage process, a specific data entity list for the technical annex — lands in a team's working documents and gets built upon. Both findings here produced exactly that: structured output with internal consistency that read as authoritative. In one case the AI even falsely claimed its fabricated structure was confirmed by public summaries of the document.

A junior architect or a payments analyst working under time pressure has no obvious reason to doubt it.

The systemic risk for an internationally-operating retail bank is that this regulation sits at the junction of several concurrent programmes — ISO 20022 migration, cross-border payment rail modernisation, correspondent banking API upgrades — and teams from multiple functions (technology, treasury, trade finance, operations) may all be consulting AI on overlapping questions from the same inaccessible source. Errors do not stay contained to one workstream. A fabricated toolkit structure used to scope an API readiness assessment will appear in steering committee reporting, vendor RFPs, and potentially in correspondence with regulators or industry bodies — each step increasing the cost of correction.

What your team should do

The default position for this regulation is straightforward: treat any AI-generated description of toolkit contents or technical annex specifics as unverified until you have the primary document open in front of you. The BIS publications page is the authoritative source; the toolkit is part of the October 2024 package and the updated ISO 20022 data requirements are a February 2026 document. Any AI answer that gives you structured breakdown of either — named areas, assessment dimensions, data entity lists, six-step processes — should be treated as a draft hypothesis, not a summary.

For the ISO 20022 updated requirements specifically, the practical safeguard is date-first verification. Before using any AI-generated description of what changed between the 2023 original and the updated document, verify the publication date from the primary BIS page. If the date the AI gives you does not match what you see on bis.org, treat the rest of the AI's answer as suspect. AI tools sourcing from secondary aggregators will carry errors from those sources transparently, and publication date is the cheapest single check to perform.

For the technical annex content — data entity breakdowns, field-level mapping changes — go to the source document directly; do not rely on AI summaries for content that has direct implementation consequences.

AI tools remain genuinely useful for this regulation in areas where the content is reliably accessible: the CPMI's seven headline recommendations are described in the report's executive summary and referenced across multiple BIS communications, and AI can accurately summarise the broad intent and scope of each. Using AI to orient a team to the recommendation landscape — which recommendations address governance, which address data standards, which address developer experience — is reasonable. Using it to populate assessment criteria, define scoring dimensions, or specify data model changes is not, until the team has verified those specifics against the primary source.

How RLB Can Help

RegLeg's published Hallucination Research gives Technology & Data teams at retail banking firms a ready-made pre-flight check before relying on AI-generated output for regulatory questions. The research catalogues, by regulation, the specific failure modes AI tools have exhibited — including where they have misread rule text, fabricated cross-references, or confidently stated requirements that do not exist — so your team can calibrate which query types warrant human review rather than discovering the gaps in production.

Beyond the public research, RegLeg offers bespoke regulator deep-dives scoped to the Technology & Data function specifically. These map the AI-supported workflows your team is most likely running — from data governance gap assessments to regulatory change screening and systems-documentation review — against the hallucination exposure patterns observed for the regulators and regulations that govern your firm. The output is a prioritised exposure register your team can use when setting AI-use guardrails or briefing risk and compliance stakeholders.

For firms that already have an AI-use policy in place, RegLeg can conduct a confidential review of that policy against its accumulated failure-mode catalogue, identifying provisions that may be under-specified for the risks Technology & Data teams actually face and returning a prioritised remediation note. RegLeg also produces training material and CPD-aligned content that Technology & Data professionals can use internally — building working literacy around AI hallucination risk in a regulatory context, without requiring staff to engage with raw research outputs directly.