By Fiona Hamilton of Volante Technologies.
The ISO 20022 catalogue of messages, as at Jan 2012, consists of 299 XML Schemas that cover a range of business domains. Over the past seven years since the first ISO 20022 compliant XML message definitions were registered and published the subject of ISO 20022 itself has taken up thousands of pages of printed and web based media. Some of the coverage has been positive in nature, some negative, often superficial and occasionally misleading. The sheer volume of information available however, has counter intuitively made it harder for the potential consumer to access the facts they need to make competent business and technical decisions.
Whilst it is important to know what ISO 20022 is and where it can help a Financial Services business, it is equally important to understand what it is not and why therefore. It is not a “cure all” for every message based information exchange.
This short paper attempts to extract the salient points from the ocean of content and provide the reader with the basic information that will provide them with the background to be able to navigate effectively the more detailed information that they may require. It is not meant to replace book sized documents like the ISO 20022 for Dummies publication available from the ISO 20022 web site, which can facilitate very in depth understanding nor is it meant to be a detailed introduction to XML of which there are many W3C based documents and tutorials on the web.
The document assumes no prior knowledge of the ISO 20022 subject matter but does presuppose a basic understanding of message standards based data integration in the Financial Services industry. To that end, the initial section of the paper will briefly cover the history, operation, architecture and typical syntax related to the Standard. The middle section will approach the subject of what the standard is “fit for purpose” for, by addressing some of the misconceptions that frequently abound. The final section will address considerations when implementing an ISO 20022 based integration solution.
First a Few Terms to Explain
Whilst the aim of this paper is to as far as possible avoid technical jargon and acronyms, it is unavoidable that some are required in order to fully understand the standard and the implications of implementing it. So whilst many readers will know these, it is briefly worth explaining them for those new to the subject matter.
Firstly, the term ISO 20022 (generally pronounced “Twenty-oh-Two-Two”) itself is constructed from two parts, the first stands for the name of the body that owns the standard. Because “International Organization for Standardization” would have different acronyms in different languages (“IOS” in English, “OIN” in French for Organisation internationale de normalisation), its founders decided to give it also a short, all-purpose name. They chose “ISO”, derived from the Greek isos, meaning, “equal”. Whatever the country, whatever the language, the short form of the organization’s name is always ISO. It is the International body for standards and its members are largely the domestic standards organizations such as the British Standards Institute (BSI) or American National Standards Institute (ANSI). The standards which they publish cover everything from quality standards such as ISO 9001, currency codes ISO 4217 through to engineering, electronics, manufacturing and pretty much everything we come across in our daily lives. The ISO 20022 standard defines a methodology for the development of financial message standards. It relies on UML (Unified Modelling Language) models representing financial business processes, flows and transactions in a neutral notation. These business transaction models are then subsequently converted into physical messages in the desired syntax, like XML (eXtensible Mark-up Language).
The ISO number simply indicates a unique identifier for the standard itself. Indeed the latest 20022 standard is a logical evolution of ISO 15022 which itself was a successor to ISO 7775. These standards and how they relate to each other will be addressed in more detail later in the document. Two words that are vitally important in the context of any message standard are “Syntax” and “Semantic”.
Syntax means the physical structure of the message in terms of what the fields or elements in a message are, in what order they are, their structure (length/possible values/allowable characters, format) and the cardinality (mandatory, optional or multiplicity). Semantic pertains to the meaning of the information being conveyed by the content formatted according to the Syntax. So for example two Date fields may have their syntax defined as being bounded by a start and element because they are XML compliant. The syntax also imposes that they are both compliant to ISO 8601 (the date format standard). The following shows a very simple syntax that supports this.
The structure above is syntactically correct, each Element has a start and end; e.g. Date1 and Date2 and the dates are formatted according to ISO 8601, Syntax validation would check this and highlight errors. Semantics on the other hand relates to what the data mean and how one piece of information relates to another. Rules, which then impose restrictions on data, are therefore referred to as semantic validation rules. An example of this would be where Date1 is a Creation Date of a transaction, and Date 2 is the Settlement Date, and a semantic rule would check that the latter cannot be before the former.
For most XML based standards, the syntactical definition of what a compliant message must look like is provided by a “Schema” file which can be differentiated from the “Instance Document” by the fact that it has a “.XSD” file extension and not a “.XML” one. For the purposes of this paper an “Instance Document” will be referred to as a “Message”. The schema itself is in fact an XML file that simply uses a predefined set of elements to describe the syntax of another file. An XML message can therefore be “well-formed” which means that it complies to the grammatical rules of what XML has to be constructed by; for example, start and end element tags in the correct nested order where the end tag is the same as the start tag but with a preceding “/” after the “
The schema that describes the message above which is a Financial Institution to Financial Institution Credit Transfer Instruction is named pacs.008.001.02.xsd and an excerpt can be seen below:
A major concept in schema definitions is that of “Types” which can be “Simple”; i.e. defining a single atomic piece of information such as the above, which in this case is based on the underlying “ISODate” “built in type”, where the term built in just means that it is a definition and understood throughout any XML schema. Simple types can also be defined just for the purposes of a single schema or group of schemas that another project or organization would either have another definition of, or would not be relevant. A base type is common to anyone writing schema. In this example one can also see the definition of the “Cardinality” of the element in this context; in this case the convention of “maxOccurs=”1”minOccurs=”0””means that it is optional.
Another important concept in Schema is that of the “Enumeration” which is a way of restricting the values that a simple type can have. In non-XML message standards these are often referred to as “Valid Values” lists. In the example above the “CreditDebitCode” simple type is being restricted so that it can only have the values of “CRDT” or “DBIT”.
The other type is “Complex” which simply means that it is made up of other types that could be a mixture of simple and complex ones. In the example above a complex type called “CreditTransferTransactionInformation11” is being defined. It is in this case a “Sequence” which means that the following elements must appear in the order specified and according to the cardinality. Another type is a “Choice” where for example one element or another must be present but not both. Elsewhere in the Schema this “CreditTransferTransactionInformation11” complex type is then used as the base type for the element which is mandatory as can be seen from the cardinality declarations but can repeat an unlimited amount of times.
The ISO20022 Standard
The previous section has introduced the basic concepts of XML and XML Schemas and used ISO 20022 messages as the examples. It is however, important to understand how these messages are arrived at, maintained, extended and restricted to fully understand the usage and potential impact on general Financial Services Data Integration. ISO 20022 is the ISO Standard for Financial Services Messaging. It describes a “Metadata” (Data that describes Data) Repository containing descriptions of messages and business processes, and a maintenance process for the Repository Content. The process is driven by The Unified Modelling Language (UML) which is used to specify, visualize, modify, construct and document the artefacts of an object-oriented software-intensive system under development. UML offers a standard way to visualize a system’s architectural blueprints, including elements such as:
§ Business processes
§ Database schemas
§ (Logical) components
§ Programming language statements
§ Reusable software components
In simple terms this means taking a business process such as a Payment Instruction between banks and breaking it down in to the flow of information between the parties and/or systems (the Actors) involved in the Business Process. For example an Instruction sent (an Activity), followed by an acknowledgement of receipt, then status updates and a final advice of debit and end of day statement. Next this is broken down in to the components that define the information required, for example what is a currency, what is an account, etc. This leads to the definition of the Logical Components, which can then be used as the basis of Physical Components. So for example you only need one logical component called Currency, which you can define as being based on ISO 4217 codes. This can then be used as the base of let’s say, Credit and Debit Currency components. In a similar fashion Account can perhaps be defined as either a standard IBAN 2007 format (ISO 13616) or a Proprietary format of a maximum of up to 34 alphanumeric characters. That underlying account definition can then be used for example, as the basis for the Beneficiary and Charges account numbers respectively.
The result of the exercise is that you end up with a “Repository” of base business definitions that underpin ALL compliant messages that adhere to the standard. The advantage being that anyone who wants to create a compliant message is at liberty to call the elements what they like but by linking them to the base types in the repository you can be sure that all parties involved in the processing of the message will have a common understanding of what a currency or account is and what its format is. This represents a major building block for effective inter-organization STP (Straight Through Processing) of information.
There is a standard process defined by ISO 20022 for submitting proposals for adoption and these are generally as the result of work by other standards bodies such as SWIFT/FPL/IFX or industry utilities such as Euroclear/CLS. The ISO 20022 Registration Authority (RA) is the guardian of the ISO 20022 Financial Repository and the www.iso20022.org website.
The RA mission is to ensure compliance of developed Repository items with the approved technical specifications and to publish the Financial Repository on www.iso20022.org, on behalf of ISO. In the case of ISO 20022, SWIFT act as the RA and as in so many cases they are the Registration Authority and the submitter.
The Registration Management Group (RMG) is made of senior industry experts and is the highest ISO 20022 registration body: it monitors the overall registration process and reports directly to ISO TC68 which is the Technical Committee within ISO that looks after Financial Services.
The RMG defines the scope of necessary Standards Evaluation Groups (SEGs), approves business justifications for new messages and allocates them to one or more SEGs.
The ISO 20022 Standards Evaluation Groups (SEGs) are made up of industry experts in specific business domains of the financial industry as defined by the ISO 20022 Registration Management Group (RMG). ISO TC68 member countries and liaison organisations nominate SEG members.
The role of a SEG is threefold:
1. To ensure that the right industry groups are informed of proposed developments to ensure all business requirements will be addressed.
2. To validate the newly developed message definitions from a business perspective as representative of future users. This is to ensure that what will be posted in the ISO 20022 repository by the RA really addresses the needs of future communities of users as described in the business justification accepted by the RMG in the first place.
3. To approve changes to existing message definitions.
The RMG has to date defined the scope of five SEGs covering distinct business areas:
FX (Foreign Exchange) [2,13]
Trade Services [14,15]
Cards and Related Retail Financial Services. [3,5]
These SEGs have then validated and approved messages in the following categories:
acmt  – Account Management
admi  – Administration
caaa  – Acceptor to Acquirer Card Transactions
camt  – Cash Management
catm  – Terminal Management
pacs  – Payments Clearing & Settlement
pain  – Payments Initiation
reda  – Reference Data
seev  – Securities Events
semt  – Securities Management
sese  – Securities Settlement
setr  – Securities Trade
trea  – Treasury
tsmt  – Trade Services Management
tsin  – Trade Services Initiation
Within each category there are then the individual messages which are named with the following convention:
1st set of 4 characters represent the category as per the list above, in this case Payments Clearing & Settlement
1st set of 3 digits are the message number which indicates function, in this case Financial Institution To Financial Institution Credit Transfer
2nd set of 3 digits indicates the variant number, in this case 001 indicates it is the base definition
3rd set of 2 digits indicates the version number which in this case is the second version of the message
The purpose of the first two sections and the last are pretty self-evident however, the “Variant” requires some explanation. As described by the ISO 20022 web site:
“ISO 20022 messages aim at being global and catering for the business needs of all communities. In general, a particular community of users will not need all of the features defined in the global message. A ‘variant’ is a restricted version of a global message that fits the needs of a particular community.”
These variants can then be submitted and approved/published by the RA. There is a standard mechanism for defining and submitting these variant requests. The ISO 20022 website has a “Catalogue of Messages” from where the following items can be downloaded for each category or message:
XML Schema for the message
The “Message Definition Report” which gives a written description of the message formats, items and “Semantic Validation Rules” which are in effect cross element validations that cannot be defined in an XML schema but are added to give semantic consistency of the data across elements. For example, the following are some of the rules applied to the pacs.008.001.02 message:
UML models in Machine Process able format and diagrams representing the business process
A “Master Message Template” which is an Excel spread sheet that lists the various items of an ISO 20022 Message Definition and allows communities of users to indicate whether and how they use these items. This is the starting point for the definition of an ISO 20022 variant message.
More on ISO20022 Variants
It is worth dealing in more depth with the concepts of ISO 20022 variant messages as they potentially have a major impact on the implementation of ISO 20022 as a standard for message based data integration. The Master Message Template that can be downloaded from the Catalogue of Messages by clicking on the P/T column against the message in question has the following format
The template allows an organization to implement the following changes to the base definition of the ISO 20022 message.
Supress a message item (element) that should not be used
Restrict the number of times a repetitive item (element) can repeat
Make an optional item (element) mandatory
Restrict a choice to one or fewer options
Restrict an Internal Code list to fewer values
Reduce the size and/or restrict the pattern of a text item
Define substitute Data Types to represent some of the above changes
A full description of how to make changes and their allowable scope can be found by downloading the document “How to customize a master message template document”.
A further concept that can alter the semantics of an ISO 20022 message is the concept of a “Data Source Scheme”. The ISO 20022 Data Source Scheme (DSS) is a mechanism that allows an institution or market organization to specify and use a proprietary code list that is not owned nor managed by ISO 20022, and that replaces a standard code list (either a specific ISO 20022 managed code list or another ISO standard code list, e.g. BICs or ISINs) in specific Message Components where the use of DSSs has been approved.
For example in the following example the Data Type “GenericIdentification13” which is used as the basis for the unique identification of a Party has been restricted to a set of values maintained by Deutsche Börse Clearing AG.
These Data Source Schemes are managed by the external organizations themselves but must be submitted for approval to the ISO 20022 RA.
ISO 20022 publishes a document that lists the approved DSSs by allowable Data Type for which they are eligible. The subsequent extract below shows that these DSSs can be related to Industry Utilities, Payments Systems, Clearing Houses, Government Agencies and individual banks.
In addition to the variations from the standard mentioned above. ISO 20022 messages also support the concept of extensions. A Supplementary Data XML extension mechanism can be used in some ISO 20022 messages; to date some securities messages make use of the “Extension1” or “Extension2” XML elements.
ISO20022 Messages vs. SWIFT MX Messages
A subject that often causes confusion in the market and which expands upon the concept of variation is that of SWIFT’s implementation of ISO 20022 compliant messages. Earlier in this paper it was pointed out that SWIFT act both as the Registration Authority for ISO 20022 messages and as a submitter of standards to themselves in that role. They are however not the only submitter of messages. For example the “pacs” Payments category of messages was submitted by SWIFT but the Card services “caaa” category messages were submitted by EPASOrg. So there are ISO 20022 standard messages that are not supported/transmitted via the SWIFT network. Likewise SWIFT operate commercial services such as Clearing which contain ISO 20022 compliant messages; i.e. they have been constructed according to the methodology and dictionary but which have not as yet been approved or submitted to the ISO 20022 RA. The Clearing solution for example utilizes messages in the categories “colr” (Collateral) and “secl” (Securities Clearing). Additionally “SWIFT Solutions” which are SWIFT’s bundled sets of MX messages targeted at specific business processes may also implement newer versions of the ISO 20022 messages before they are accepted by ISO. So in short, sometimes SWIFT implement standard ISO 20022 messages and sometimes they do not.
In addition ISO 20022 defines the business message schema often referred to as the “Payload” and also defines a “Business Application Header” that defines information such as the sender and receiver amongst other things. There are however other pieces of information that may be required depending on the underlying method of transporting the message. ISO 20022 itself, does not define or mandate any type of transport. However if an organization wishes to transport a message across SWIFTNet they will also have to add other wrapping information that is specific to that network. For example SWIFTNet Headers and a Request Payload that as well as containing the ISO 20022 message also contains either the ISO 20022 Business Application Header or the SWIFT specific InterAct Header. In addition the user will also have to conform to the additional wrapping information specific to the SWIFTNet gateway which will differ depending on the vendor in question.
So mapping application data to the ISO 20022 message payload is only part of the task. To assist in mapping to ISO 20022 messages SWIFT publish mapping specifications from the older ISO 7775 (mostly non Securities messages) and ISO 15022 (mostly Securities) MT messages. Many applications already output the legacy MT message types and these specifications can be invaluable for organizations wishing to either re-engineer their applications or to transform the old messages to the new ones without invasive programming via the implementation of external transformation software. It is however, important to understand that these specifications only define the mapping to the ISO 20022 compliant messages that a) SWIFT support and transport across their network, b) have a functionally equivalent “old style” MT message and c) are the version that SWIFT implement which may not necessarily be the same as the ISO 20022 published one.
Considerations for Implementing ISO 20022
Without question the introduction and development of ISO 20022 has introduced a coherent and standardized approach to financial messaging. Although the uptake has been quicker in some areas than others, whether geographically or by asset class, the pace of adoption does appear to be increasing. This is especially true in the Payments world where many of the world’s payments infrastructures such as domestic ACHs, commercial utilities and other initiatives such as SEPA either have or intend to migrate to an ISO 20022 based messaging solution. The standard is also being adopted by many banks as the standard approach for on boarding clients’ Payment Initiation instructions and cash management requirements.
So the future for solving the messaging problems that the financial services industry has had with disparate, inadequate and proprietary standards is very bright, providing that financial services firms take the initiative to implement data transformation and integration strategies that simplify adoption of data standards and enable STP efficiencies across retail and wholesale markets. Indeed this type of strategy offers the potential to further compliance and would reduce costs and risks for each firm as well as those systemic in the industry. In fact, a more strategic approach to integration can deliver additional business benefits related to better data management, such as improved investor and asset servicing.
However, as has hopefully been highlighted in this paper ISO 20022 in itself is the basis for solutions and not the solution in its entirety. When making a decision to implement ISO 20022 an organization must ask “what type of ISO 20022 messaging are we talking about?” For example some high level questions should be addressed up front.
- Will all clients/trading partners communicate with the organization via standard ISO 20022 messages?
- What variants of ISO 20022 messages are going to be used?
- Are Data Source Schemes going to have to be supported?
- Are External code lists going to have to be supported?
- What cross field validations need to be implemented and are these likely to be at the client/trading
- partner level?
- What transport mechanism is going to be used and does that entail additional header information being added to the base ISO 20022 message?
- If SWIFTNet is going to be the transport mechanism what are the header requirements of the interface gateway?
- Are all the messages standard ISO 20022 or are they actually SWIFT MX messages or a mixture of both?
- If variants/extensions are going to be used how do you support their growth as the number of clients/trading partners increases over time?
- How does the organization cope with the annual maintenance changes to the ISO 20022 messages or the variants/additional messages that utilities such as SWIFT implement?
- Are internal applications going to be re-engineered to natively create and/or consume the ISO 20022 compliant messages and if so what are the on-going maintenance implications of invasively changing them?
- If standardized message translation specifications exist for message pairs; e.g. SWIFT MT to SWIFT MX ISO 20022 compliant messages, is that a more prudent approach than invasive application changes?
- If message transformation is implemented does the logic exist as specifications for all messages given that they may only exist for ISO 20022 messages supported by SWIFT?
- For message transformation what is the best approach for supporting the inevitable client/trading partner specific information/formats within the constraints of the standard itself?
So whilst it is easy to phrase the sweeping statement that an organization is going to migrate to ISO 20022 messaging, it is rarely as straightforward as it seems and as ever in data integration the devil is in the detail. As an example, one payments operator in Europe has already indicated that they have had to support more than 200 variations on the base ISO 20022 messages. Indeed one only needs to review the SEPA standards which not only restrict the usage of ISO 20022 messages and support variants of even those with the concept of AOS (Additional Optional Services) or the usage guidelines for using the same messages for Worker’s Remittances to see that variation is the norm.
Standardization of messaging will, at a stroke, cut enormous costs and risk across the whole market via enabling a consistent approach to structuring information which in itself enables greater STP and agility in on boarding clients, trading partners and clearing & settlement venues. It will not, however, achieve these high objectives unless the organizations are able to integrate the data internally and pass it through to the next processing recipient in real-time. Fortunately, with available technology to automate ISO 20022 based integration in a maintainable fashion that reduces cost of implementation and on-going ownership, this goal is achievable for any type of firm.
Since 2001, Volante Technologies has been optimizing data efficiency for the financial services industry, while slashing development time and cost of ownership. Volante provide integration solutions with built-in expertise in financial data formats. Support is provided for the entire base ISO 20022 messages, SEPA and SWIFT MX variants, and domestic ACH implementations, not to mention “out of the box” implementations of the published SWIFT MT/MX transformations. The Design Environment provides a unified environment for business analysts to define transformations and validations and for technical staff to implement them graphically and subsequently test and generate code based on the definitions. All data models and mappings are then extensible in a managed environment to support the myriad variations that are likely to be encountered. Volante also maintain these standards in line with the published standards and provide powerful automated tools for migrating existing transformations and validations to the newer versions. Volante integration technology is used in by many of the world’s leading universal/investment banks, payments utilities, ACHs, standards organizations, buy side institutions, clearing houses and exchanges.
For more information about how Volante can increase accuracy, efficiency and speed in your ISO 20022 based message processing, please call us at the numbers below or email us at [email protected].