Request demo

External value repositories: complementing the building blocks of ISO 20022

Not all definitions applicable to payment XML messages are available from one place. With the standard permitting market actors to define their own lists of valid values for specific transactions, the complexity of the specifications involved lead to a sometimes complicated jigsaw puzzle of guidelines distributed over various locations.

To work efficiently with ISO 20022 XML, and for its validation and all forms of process simulation in particular, platforms aggregating information from distributed sources promise valuable performance benefits.

While the ISO 20022 message schemas, centrally managed by SWIFT as the Registration Authority, define the base grammar of the message files, these do not define every detail of what is or is not a valid transaction message; so called External Code Lists document the possible values certain content fields within the message schema may have and how they are to be formatted. Examples are transaction purpose codes and certain error or status codes.

Figure 1: ISO 20022 XML consists of elements defined on various levels for flexibility. Official “external code lists” and stakeholders’ own “value repositories” define the allowed values within the semantic structure of the XML schema.

Yet, there is a range of other specifications not part of the ISO 20022 standard, such as bank-specific status codes, lists of BIC codes or lists of available invoices – external value repositories maintained and made available by the corresponding market actors. The distribution of these lists is not standardized regarding their location or format, but they form important building blocks for XML messages.

Figure 2: While the XML schema and External Code Lists are standardized by ISO 20022, additional value repositories further specify the valid values of XML attributes.

The reason the lists of permitted values were not included in the ISO definitions is flexibility. Since payment-specific values of message fields are defined by single actors in the industry (e.g. banks or invoice operators) and they may change often – even daily in some cases – the maintenance of the lists as a whole would become an impossible task. By introducing Data Source Schemes (DSS) to the standard, it was made possible for organizations and institutions in the market to further specify the semantics of ISO 20022 messages with content rules serving their needs.

In consequence, the definitions of what is a valid XML message are distributed over a variety of instances; it is not the easiest task for developers to stay up-to-date with the latest versions of all applicable specifications. While the official “external code lists” are available from the ISO 20022 website (a spreadsheet with 48 External Code Sets and a matrix of permitted Bank Transaction Codes), the bank- or application-specific value repositories are not available from one common interface, but may have to be collected from a variety of sources.

Running around between warehouses

With external value repositories stored in numerous places, a developer may have to access several systems in order to collect the specifications needed for a task at hand. For example, every bank maintains their own lists of acceptable attribute content, e-invoicing operators maintain specifications of valid invoice numbers etc. These lists can be very long and may be documented in divergent formats as they are managed by a range of independent organizations, further adding to the overhead.

Figure 3: The developer needs to assemble the various value repositories from a range of sources, often in varying formats and under consideration of their differing versions.

An aggregator for a modular standard

What the developer is ultimately concerned with is that XML messages comply with all specifications. To eliminate the need to shop around for applicable definitions, a centralized testing and validation tool should automatically provide information on all fields of the schema. At the same time, it should take into account the latest version of any external code lists and value repositories, without adding effort for the user.

Figure 4: In order to improve productivity, the task of managing external sources defining permitted field values should be channeled through a suitable software tool, enabling the developer to focus on their work rather than on code list management.

As described above, it is one of the core features of ISO 20022 that market organizations can easily specify the semantics of certain fields in the schema. Without this flexibility, maintaining a global standard for payment XML that serves the needs of every stakeholder would not be possible. At the same time, this modularity of content definitions creates a need for developer tools that merge distributed definitions into one place, making them easily accessible for reference and validation.

Merging the pieces of the standard into one

Organizations wanting to speed up the implementation of payment XML need to consider ways to eliminate the requirement for the individual developer to pull versions of spreadsheets from distributed sources and – in the worst case – decipher inconsistent forms of documentation. It is recommendable to use an XML management and testing platform that always has the latest code lists to test again. Ultimately, the ISO 20022 standard is at its best when, despite flexible and distributed Data Source Schemes, implementation tools merge the pieces together and present them as one holistic format entity.

With its cloud-based management of specifications, XMLdation’s XML management platform myXML provides a one-stop shop for the developer to access all definitions related to the creation of a transaction message. The service combines standard schemas and external code lists from various sources and allows validating against them without further concern about where they are maintained and in what format.

About XMLdation

XMLdation is a world leader in testing for payments messaging and APIs, covering ISO 20022, SWIFT MT along with national and proprietary payments formats.

Our solutions Request a demo today



Stay up to date

Subscribe to our newsletter