Payments Canada published an opinion piece outlining how they think ISO fits into the payments ecosystem.
| Quote | Implication |
|---|---|
| That message is received by the creditor and immediately dissolved and dispersed into the internal data models | ISO should be used at the system boundaries; not as your internal data model |
| The messages defined in ISO 20022 are meant to […] complete a specific operation between two financial systems or two different entities within a financial ecosystem | ISO is intended for communication between FIs |
| these messages are purely transient. All of the systems in the financial industry have been designed to store data - not messages. While the data persists for decades, the messages only persist for seconds | Store normalized transaction data |
| ASN.1 and XML-based messages are useless for delivering a high-volume real-time payments rail | Don’t use ISO for latency-sensitive systems |
The ISO 20022 standard provides a common language for Financial Institutions to use when communicating with each other. It brings consistency and well-considered data structures to interfaces that previously had none.
But it belongs at the boundaries. As I discussed earlier, ISO 20022 is not as standardized as its name implies. Do not use ISO 20022 for internal communications within your payments business. Keep it at the periphery.
Payments businesses should absolutely use ISO 20022 to communicate to external FIs, and maybe even with other lines-of-business because having a common nomenclature is beneficial for both verbal and digital communication. But don’t forget that it’s a wire format designed to facilitate inter-FI communication.
Systems that interact with ISO 20022 messages should have a layer to transform the ISO message into the system’s internal data model. Do not allow the ISO message beyond the gates - take its data, map it to your internal model, and process it.
This isolates the system from the vendor-specific ISO quirks and limits the blast radius when the message structure or data semantics change. You should have a system or service dedicated to each vendor you interact with, and its goal is to insulate the rest of the business from that vendor.
Store the ISO 20022 messages in a document store for audit purposes if you like but remember that you don’t control the message schema so you need to treat it as an unstructured blob that can change at any time. That PACS-008 message from last year might not be compatible with a PACS-008 message from the same vendor or FI this year.
You don’t control its schema so you should minmize how much of your code relies on it.
Extract the necessary fields into your internal data model when you ingest the messages, store it in a structure that makes sense, and query that data with any APIs or data extracts that you need. Link your data model to the ISO message for traceability but otherwise pretend it’s not there.
Don’t let those ISO messages leak out because then other systems will rely on the message schema that is outside of your control. Don’t put an API on top of them. Don’t produce reports from them. Don’t write code that relies on the message structure. Respect Hyrum’s Law.
The ISO schema changes regularly and those changes often break backwards-compatibility so any code or system that relies on those data structures will either break when it reads older messages or it will require constant maintenance to handle all the ISO variants.
It’s better to just avoid that entirely by not letting anyone read those stored messages. They’re only there for audit purposes.