ISO 20022 defines a catalog of messages to standardize data exchange in the finance industry, and it is gaining popularity in Payments.
Here in Canada, Interac updated their APIs to support ISO 20022 several years ago. FedWire in the US will be rolling out ISO 20022 support in summer 2025, and Zelle is following suit with its integration to The Clearing House’s Real-Time Payments network.
But it’s not a standard despite what the name implies.
ISO 20022 Compliance
The ISO 20022 governing body has published a document outlining what ISO compliance means.
Here’s the TL;DR
| Quote | Implication |
|---|---|
| There is no official certification authority for ISO 20022 | Compliance is subjective and unregulated |
| The XML messages (.xml) must, among others, be valid against the corresponding XML schema (.xsd) | Any non-XML messages cannot be ISO-compliant |
| actual ISO 20022 compliance is however always checked against the original ISO 20022 schemas published on the iso20022.org website | Changing the field names results in non-compliance |
| Message instances must be valid against the Constraints that are registered for the Message Definition | Changes to the constraints (mandatory -> optional) is non-compliant |
| Messages must use registered code values | Modifications to enumerated values is non-compliant |
In short, if an organization publishes their own message schema then it by definition cannot be ISO 20022 compliant. JSON is not compliant. Changing fieldnames from DlvryMtd to DeliveryMethod is not compliant.
None of the major vendors in Payments are ISO 20022 compliant based on that definition. None of them.
Why does compliance matter?
ISO compliance promotes interoperability. One insititution’s PAIN.013.001.07 message would be identical to another’s.
The lack of compliance and certification leads to invalid assumptions.
Executives are jumping on the ISO 20022 bandwagon because they believe it’ll simplify integration and interoperability. This is simply not true because each payment processor has their own flavour of ISO 20022.
One cannot craft a generic ISO 20022 message route the same message to any processor. It has to be transformed into the particular processor’s ISO dialect, and adhere to their snowflake validation rules.
It also complicates enterprise reporting. A centralized payments data warehouse containing payments messages from multiple external FIs would contain multiple different message structures and formats. Aggregating data across FIs would require additional ETL.
It doesn’t “just work”. It requires work.
What should you do?
I’ll post a followup piece on how I believe organizations should approach ISO 20022.