Mastering the complexity of ISO 20022 extensions
The rise of ISO 20022
At Trace Financial we’ve spent many years working on financial messaging projects with our clients. One of the mega-trends of the last decade has been the rise and rise of ISO 20022. Today it is almost unheard of for a payments or market infrastructure project to select any other messaging standard.
According to SWIFT (which acts as the Registration Authority for the standard) ‘almost 200 market infrastructure driven initiatives are either already implementing ISO 20022 or are considering adopting the standard’. Some recent examples include Australia’s New Payment Platform (NPP), SEPA, TARGET2 and TARGET2-Securities (T2S).
Extending the message definition
As with most other standards, the ISO 20022 standard allows for the addition of new fields and other changes as part of its normal maintenance cycle. In some cases however a restricted group of message users needs to add one or more fields that are not likely to be generally applicable or useful globally, and which therefore cannot be incorporated into the main standard.
The ISO 20022 standard provides for this eventuality by including an empty placeholder – the Supplementary Data component – within the standard message definition, and then allowing user groups to submit Extension Schemas to define its content.
The DTCC’s extensions to its ISO 20022 based corporate action messages are examples of this but there is an upward trend of other initiatives or FI’s using this section to add additional information to the payload.
Supplementary Data can be appended once at the end of a message, or it can be added to every instance of a repeating block, for example in a statement message.
While this provides a great deal of flexibility, allowing user communities to customise the global standard, it creates an extra challenge for those trying to consume, transform and produce the resulting messages.
Working with complex standards
Our mission at Trace Financial is to deliver technology that enables analysts to construct and maintain business rules, validations and mappings themselves, i.e. with no coding stage. This means moving as far away as possible from the risky and time-consuming process of writing a specification (usually in a spreadsheet), passing it to a team of developers, and then hoping they will code it correctly by hand.
The ability to present technically complex message standards in a business-meaningful way, for direct use by a business-facing analyst, is, therefore, a key feature of our Transformer solution. Using the Transformer Design Time GUI, the analyst can navigate around very ‘long’ (many fields) and ‘deep’ (highly nested) message structures rapidly and confidently, knowing where they are at any time. The presentation of fields and other components focuses on their business meaning (semantics), and is the same across all underlying syntaxes.
Mastering message definitions that include extensions
The analyst working with a Transformer ISO 20022 library can simply import an Extension Schema and use it to give a detailed data structure to each Supplementary Data component in the standard. It then appears visually just as if it was part of the main message definition. From this point onwards the analyst can create a validation or mapping using all of the available fields, exactly as if this was a normal ‘unextended’ message definition.
The general point here is that there are qualitatively better and worse ways to model complex data structures. A well-designed message definition library will enable huge productivity gains. In cases like ISO 20022 however, it must also be able to support the additional complexity presented by ‘soft’ components modelled by extensions. Ensuring that all of the message is clearly readable helps to ensure that the resulting mappings and validations stay maintainable in the longer term. In this way the enterprise can rapidly develop durable, quality solutions that comply with changing, complex standards.