With much fanfare SWIFT announced an ISO 20022 Harmonization Charter at Sibos 2015 in Singapore. Driven by the rapid proliferation of adoption of ISO 20022 across the industry, whether in payments, securities or other asset classes, a number of payments associations, central banks, securities and payments processors have signed up to a framework for sharing usage information and more. There are currently more than 200 initiatives round the world where ISO 20022 has been chosen as the basis for new services or as the desired syntax to migrate to for legacy services.
So this laudable intention on the face of it seems like a good thing but as with everything in the standards world, the devil is in the detail.
For many years, myself and many others have been writing articles and participating on panel sessions that pondered or lamented the glacial adoption of ISO 20022 compliant messages by the financial industry. Then suddenly within the space of a couple of years the main issue seems to be that it is being widely adopted. Is this a case of “be careful of what you wish for”?
Is this a case of “be careful of what you wish for”?
The answer to that question very much depends on what you thought ISO 20022 was going to bring to the table. If you thought that ISO 20022 was a set of messages that would cover every financial transaction from “cradle to grave” with all contents codified, then you plainly didn’t read the small print! ISO 20022 is a methodology based on modelling the concepts behind transactions, such as what an account is or what a currency is. From these concepts you can then base more specific usages such as a Cash Account from which in turn you can derive message components and elements which will then end up in the message artefact, which is usually an XML schema that defines the structure and content of an XML instance document (message). It should be noted that the message structure does not have to be XML but in practice this is the case with most implementations.
So far so good. It is great that when you see something that is based on the concept of an account, regardless of what it is called, you can know its general structure and what it means. The deviations, however, start at that message derivation stage and that largely is where the proliferation of differing implementations and usage comes in. It is important, however, to understand that this was always part of the overall design of the standards. In fact it is actually one of its strengths. Built into the naming conventions of the message schemas derived from the business data dictionary are the concepts of versions and variants. The ISO 20022 methodology is highly influenced by Unified Modelling Language (UML) and more generally in practices associated with “agile” development. As such the aims are to facilitate rapid development of solutions highly tailored to the end user/system requirements.
If you thought that ISO 20022 was a set of messages that would cover every financial transaction from “cradle to grave” with all contents codified, then you plainly didn’t read the small print!
So if I wish to create a variant of a published message schema which restricts usage, I am perfectly at liberty to do so. Likewise if I don’t find a published message that fits the bill I can also create my own schema that constructs a message structure that does. As long as I base it on the underlying components in the business data dictionary and inherit those properties of length, type, etc. then my message will still be ISO 20022 compliant – it just won’t be based on a published message. This being the approach that infrastructure such as T2S has taken.
So, given that inherent flexibility it is hardly surprising that the number of variations encountered across the world is multiplying rapidly. It’s not an accident; it is built into the standard! The ISO 20022 standard embraces commercial and context specific reality. You should be in a position to create messages which best allow you to communicate the information specific to your service whilst still retaining a basic commonality of understanding with other implementations based on the fact that the underlying business components are the same. Indeed, although SWIFT are driving the charter they too have for years been implementing their own MX messages which are often different than the published ISO 20022 messages, not to mention that in some cases some of the Swift Solution sets use implementations that are neither published ISO versions nor the versions that are published as MX. Therein lies the reality.
The ISO 20022 methodology is highly influenced by Unified Modelling Language (UML) and more generally in practices associated with “agile” development.
SWIFT have been doing a sterling job at creating and maintaining message standards for decades but even they have embraced the fact that ISO 20022 allows you to work at your own speed and to implement innovative services without waiting for the leviathan which is the ISO process itself to catch up. Of course you can submit your new versions to ISO but there is no guarantee that they will be accepted given the broad base of agreement, not to mention time and effort that is needed for acceptance.
So with regards to the tenets of the charter it is certainly a good idea to share non-IP related usage information and, where commonality exists, to adopt them as a standard usage pattern and publish those guidelines in the public domain. This certainly goes some way to facilitating interoperability. This is especially useful where you have many parties at similar stages in adoption within a fairly narrow spectrum of usage, as demonstrated by the ISO 20022 Real Time Payments Group or CGI-MP in the Corporate to Bank Payments and Cash Management space. So long as interested parties come together at an appropriately early stage then very often you can arrive at some sort of Pareto’s Law (80/20 rule) based consensus pretty quickly, and indeed just the act of talking with peers can be very beneficial. What you do need is strong chairing of these groups to stop the process getting bogged down into specifics of implementation. It is at that stage that you simply have to agree that you will be implementing the messages differently in some ways. So what you end up with is three tiered. Firstly agreement on which base version you are basing the commonly agreed content, secondly the publicly available usage guidelines for those common usages and lastly IP related usage guidelines which are not publically available and are retained by the party in question.
In short, agree what can quickly be agreed, write it up and publish it and then get on with the job in hand. Don’t spend years trying to come up with a panacea that works for all; it simply won’t happen. Indeed even the first of those three tiers is likely to only hold for a short time as commercial imperative to take advantage of newer versions to facilitate additional services or improvements to existing ones will always trump the desire to be the same a everyone else.
That reality is that the standards are there to facilitate effective transfer of information but they are also there to support innovation in services and the commercial imperative to get those services to market as quickly as possible to realize revenue.
This point does, however, seem at odds with another tenet of the charter which states “FMIs (Financial Market Infrastructures) align publication of advance information and standards cutover dates to SWIFT’s MT/FIN maintenance cycle which is already entrenched in industry practice and aligned with budget and software development cycles”. It may surprise some but the whole of Financial Services does not revolve around SWIFT. Of course for those involved in supporting SWIFT within their organizations, life often does revolve around that Feb – Nov cycle but it’s certainly not how the FIX, FpML, EDI, etc. world is aligned. These standards facilitate multiple concurrent versions and variations and are often different depending on bi-lateral agreement or network provider. I would argue that given ISO 20022’s inherent multi version capabilities and the fact that it is not dependant on a single network provider like MT FIN, it is much closer in modus operandi to those other standards than MT FIN. To be honest, I haven’t met many banks that have said to me “what I love is being forced to spend money on an annual immovable migration to new versions of messages from which I gain no business benefit whatsoever”.
Those of us deeply rooted within the standards world do have a tendency to be somewhat pedantic; however, we must also be realists. That reality is that the standards are there to facilitate effective transfer of information but they are also there to support innovation in services and the commercial imperative to get those services to market as quickly as possible to realize revenue. To suggest that we would all benefit from saving up all of our changes and new services to one golden date in the year seems utterly nonsensical to me. ISO 20022 is not network dependant; whilst it obviously makes sense for a value added network to impose tight version control, that cannot and should not be extrapolated to the entire ISO 20022 based ecosystem.
Perhaps we should all take a step back and look at how other standards manage to have this flexibility of versions and variants without all the hand wringing and cries of woe. For me this flexibility is actually a strength, and provided FMIs document in as open a way as possible how they use the standard and provide real examples, then the technology is there to handle multi-version end points. Don’t stifle the innovation, embrace it. By all means share information but set a time limit for it and then get on with implementing – aiming for total agreement is a classic case of the law of diminishing returns.
Harmony doesn’t require total agreement on everything after all.