Messages Can Travel Fast and Still Arrive Incomplete

A cross-border payment can have a working connection and a fast domestic rail yet still be delayed because the information traveling through the path is incomplete or interpreted differently. The focus here is the data layer: the difference between adopting a message standard and using it consistently, the role of APIs in exchanging information, and the checks that should happen before money moves. Understanding those distinctions helps readers diagnose whether a failed payment has a transport problem, a meaning problem or a preventable data-entry problem.

Speed makes data mistakes more consequential. If a payment is processed slowly, a provider may have time to investigate a missing field before the transaction reaches the next institution. A fast system can move a wrong account detail or an unusable instruction toward settlement just as efficiently as a correct one. The aim is not to slow the rail down. It is to make the information sufficiently complete, shared and checked that rapid processing does not create rapid failure.

A common format is not yet common meaning

Imagine that a payment moves from one domestic system to another and the receiving side cannot use a required address, identifier or payment detail in the form it receives. The problem may appear at the end of the path as a rejection or manual repair, but its cause lies earlier: different systems may have required different fields, used different labels or converted the information between formats. The visible delay is a symptom. The underlying cause is a break in meaning across the chain.

ISO 20022 is intended to reduce this kind of friction. It is a global, open standard for financial information and can carry richer, more structured data than many proprietary formats. Structured information can support more efficient compliance screening and fraud-prevention work. But adopting ISO 20022 does not mean that every participant sends the same fields, interprets them the same way or preserves them through every conversion. A common container is useful only when the participants agree on what to put in it and how to read it.

The 2025 survey shows substantial adoption alongside a less complete picture of harmonisation. Payment systems reported that 77% of FPS and 53% of RTGS systems were processing ISO 20022. For cross-border payments, 69% of FPS and 67% of RTGS systems had adopted or planned to adopt it. Those numbers describe movement toward a common standard, but they combine systems at different stages and do not prove that every message is processed exclusively in that format.

The more demanding question is whether participants use harmonised data requirements. Only 19% of FPS and 13% of RTGS systems reported alignment with the CPMI’s harmonised ISO 20022 data requirements in 2025. Around 43% of each type were considering alignment, and 22% were not planning or considering it. The gap matters because translation can preserve a message’s outer structure while losing information needed for the next decision. A payment can therefore be “ISO 20022” and still require repair or interpretation at a border.

This distinction became especially important after the end of the coexistence period for legacy SWIFT MT and ISO 20022 formats in November 2025. The BIS brief describes the transition as a milestone, but it also says the next frontier is consistent use of the richer data. Where a payment system still uses a proprietary or legacy format, essential data must be carried forward without delay or truncation. Converting a message is not the same as preserving every fact that the receiving participant needs.