Background
ISO20022 is a system for sending messages in XML format used by financial institutions around the world. It was invented by SWIFT and published as an ISO standard in 2004. It was initially intended for cross border communication but, over time, has been adopted for domestic financial communication as well.
The most common usage for ISO20022 is probably sending and receiving payments. However, the standard supports exchanging messages in relation to securities, trades and investments funds. Its definition allows for the complete transaction sequence, initiating a payment, advising on status changes, and either final settlement or rejection.
Most of us using ISO20022 know it for its XML syntax, but today it is available to be used with ASN.1 schemas as well. ASN.1 is a standard interface description language.
The good
For us as a developers, the best part is of course that it is a standard. We are allowed to reuse existing code and infrastructure to quickly launch new functionality within our software.
Whenever an integration that needs to be done involves ISO20022 then we know that we have a head start and can use much of existing implementation and infrastructure to complete the task – usually fairly quickly. But, I want to emphasise “usually fairly quickly”, because as you will see below, it is not that simple.
The bad
The ISO20022 standard is huge and it is implemented by thousands of organisation worldwide. Even though everyone tries to follow the standard, there is still a lot of slight variation in actual usage.
This becomes especially obvious when you look inside a file and examine what is actually stored within each property. The definition allows for storing practically the same thing in many different places, so what is the correct place for storing something?
Another problem with its usage is that well-defined codes that are supposed to be used mean different things when the receiving party acts on them. In one piece of documentation that I read (don’t remember from which bank) it clearly said in the beginning in bold letters “Our interpretation of ISO20022” which is being very honestly communicated by the bank in question!
So, to sum it up with an example, let’s say, sending a payment, we need to make sure that it works in every single country and with every single bank… That is a lot of work for something that should be “standard”.
The ugly
Let’s look at something that is actually not a part of the ISO20022 standard, but at the same time, not something you can avoid, communication…
Every ISO20022 file created has to be sent to a third party for processing and usually you will receive response files to be processed in turn. And here is where the work expands because every financial institution has its own infrastructure and security requirements.
From establishing a connection to figuring out how to encrypt/decrypt the files there is a lot of work and testing involving many parties all of whom have their own schedule. Takes time and that is something that someone has to pay for in the end.
Conclusion
I like it when things are simple, and when you add it all up, ISO 20022 is not. Things must be easy to understand and have clear definitions that can’t be misunderstood or misinterpreted. But as with all large standards which are trying to be the perfect Swiss army knife, it ends badly.
Keep it simple stupid is one of my favourite expressions. It usually allows for getting things done fairly quickly and effectively without having to figure out what actually is important within all of the bits and pieces of the standard before you even begin.
With that being said, I am still happy that ISO20022 exists. It makes life a little bit easier working with payments and at least we have a known starting point for each new integration.
Until next time…
Founder and President of Megasol Technologies