ISO XML Messaging is the Answer - the Question is which Version?

Part I. In the beginning

While the industry collaboration around the need for open messaging standards commenced back in June 2003, it took a further three years for the first full set of International Organisation for Standardisation (ISO) approved extensible markup language (XML) cash management messages to be agreed by the payments standards evaluation group (SEG) in June 2006. The resulting messages were published by ISO fourth months later in October 2006 and this included the pain.001.001.02 customer credit transfer initiation message – or credit transfer for short – and was commonly referred to as ‘version 2’.

At this stage, XML messaging was a very new concept in the cash management space and it was only in May 2008 that SWIFT published a rulebook with the help of 11 early adopting banks and 10 major corporates. Citi and GE Capital were part of the initiative; both Mark Sutton and Susan Boeri were an active part of this initial attempt to create an implementation guideline with, as the rulebook stated, the “purpose of setting an industry standard for initiating customer credit transfers and reporting back on the status of these transfers, using the ISO 20022 Customer Credit Transfer Initiation and ISO 20022 Payment Status Report”.

These guidelines represented a collaborative attempt to assist corporates, banks and vendors with the adoption of XML messaging, given the original vision was to remove the complexity that existed in the corporate to bank space through the need to support multiple file formats or even bank proprietary interpretations.

The Initial Challenges

The introduction of ISO 20022 XML messaging effectively changed the competitive boundaries as the table below clearly shows. The corporate community had made it crystal clear where they believed the banks should complete and that open standards would enable greater portability, which was a critical component of this new world.

Table 1: Agreed Boundaries of ISO 20022 XML

However, despite the above vision, there were several challenges that both the early adopting banks and corporates encountered. These could be categorised into the following three core headings:

• Bank interpretation: While SWIFT had supported the industry collaboration to produce a rulebook, this only covered a number of key areas within the core part of the message and did not include the local country rules element-effectively essential supplementary data such as Tax ID and purpose codes that is required to make a valid payment in particular country. While each bank’s interpretation followed the XML schema logic, from a corporate perspective, it represented bank specific logic within their enterprise resource planning (ERP) system.

• Message Structure: This area focused on the multiple choices that existed within the credit transfer message and contributed to the initial divergence in interpretation. For example, a payment could be identified as urgent using either a service level code or a separate clearing channel code, with some banks electing to use the instruction priority option as a further alternative. From a corporate perspective, this message structure translated into multiple ways of defining the same underlying payment method.

• Message Design: This final area focused on limitations within the actual message design – for example the lack of available XML fields to support withholding tax requirements in Thailand and the Philippines, which resulted in a series of bank proprietary workarounds.

It was evident from the above challenges and also the feedback from the corporate community, that XML messaging – and indeed the alignment between banks – needed improvement. The next stage in the evolution cycle was essential, if ISO 20022 XML messaging was going to deliver on the original vision and encompassed two key steps. Firstly, the ISO maintenance process was observed to support a number of key enhancements to the October 2006 messages and secondly, the Common Global Implementation (CGI) group was formed following publication of the April 2009 message release.

The ISO Maintenance Process and the Importance of CGI

The ISO process provides a strong foundation for the ultimate longevity of XML messaging in the financial sector, through a combination of its global appeal and highly structured approach. While ISO operates an annual maintenance release cycle, the financial industry wanted time to take on board the feedback from early adopters of the version 2 messages. Table 2 below provides an overview of the ISO process, but it is important to note that it was almost three years before the publication of the updated and new XML messages in April 2009, which were also commonly referred to as ‘version 3’.

Table 2: ISO 20022 Annual Maintenance Process

Source: ISO

So what were the key differences between the original version 2 message and the updated version 3 message? The key stakeholders had listened, understood and delivered what was believed to be a ‘simpler’ XML message that removed some of the confusion and conflict that existed in the version 2 message – for example whether the instruction priority, service level code or clearing channel code should be used to indicate an urgent payment. It also addressed limitations, such as enhancing the tax block to support the withholding tax requirements in both Thailand and the Philippines.

However, improving the message design was only part of the solution and it was the formation of the CGI group in October 2009 that effectively took industry collaboration to the next level. Considered by some as ‘son of’ the original Corporate Straight Through Processing (CSTP) bank group, it is underpinned by a formal governance model and supported through four working groups that have a mandate to deliver and maintain implementation guidelines that provide guidance and assist in achieving a more harmonised implementation. As an industry collaboration, membership continues to grow with over 90 members at the time of writing across banks, vendors, standards bodies, consultants and corporates, as more people recognise the value of this important group.

From a payments and collections perspective, the core objective was to establish a level of alignment to address both the core message and the associated local in-country rules. Discussions focused on understanding and validating what the specific data requirements were in a list of phase 1 (core) countries. The individual requirements of each country’s payment methods were discussed in detail and agreement reached on which field (XML tag) should be used to support any ‘local’ specific information. This level of discussion was required in order to achieve the required data ‘harmonisation’, which effectively built on the original mandate of supporting data overpopulation -a concept that allows a customer to reduce/remove the level of bank specific data filtering as the business rules now reside at the banking side.

The payments and collections group also considered what level of harmonisation was physically possible with the associated payment status report (file and payment acknowledgement), bearing in mind the differences between each bank’s back-office systems. These discussions allowed the introduction of a new common error code list, which will enable corporate customers to develop a bank-agnostic master error code schedule, thereby removing one of the complexities associated with a multi-banking corporate. These discussions were captured in an implementation guide and series of supporting appendices.

Table 3: CGI Implementation Guidelines

Source: CGI Group and reproduced with permission

Table 3 provides context around where the CGI implementation guidelines fit within the context of the underlying XML message, the local clearing system guidelines and your partner bank file specifications.

The CGI implementation guidelines support the concept of data over-population; simply meaning that more data can be provided than is actually required for a specific in-country payment method. However, it should be noted that whilst the guidelines provide an excellent foundation for a multi-banking implementation, they typically do not provide a plug and play option, due to the number of fields that have been listed as bi-laterally determined. For example, some banks will identify the sender of the message using a <Name> field, whereas other banks may require an identification code, like a <BIC>. Both options are valid, but without some form of harmonisation exercise, there is still a risk that a corporate customer will be forced to develop bank specific XML templates as opposed to a more generic core template with supporting local country rules. This is something to be aware of, as the devil is always in the detail.

Practical Considerations

The final part of this opening section considers some of the practical considerations around which version to adopt. While the above has provided context around the evolution of XML messaging, it is important to highlight that version 2 messages have no formal sunset date and are still considered ‘fit for purpose’ in the cash management world. Indeed, Citi recognises the importance of choice and continues to actively support both version 2 and version 3 messages across its global coverage.

However, from a corporate perspective, here are questions to be addressed in order to determine the most suitable version for those embarking on the XML journey. 

• Which banks do you plan to work with as part of this strategic project? This is an important consideration as some local banks may never support version 2 messages>

• What are your project timeframes? The relevance here is that while version 3 was published in April 2009, some banks may not have finalised their own XML service proposition, so this may have a bearing on the overall project timeframes.
    
• Are you willing to be a pilot customer? This is an important final consideration as the version 3 messages are still in the infancy phase in terms of global market adoption.
• Finally, what is the capability and status of my strategic ERP vendor(s) in terms of supporting XML messages?

Hopefully the above offers additional guidance in terms of some pertinent questions to consider as part of the decision-making process. Part II take a closer look at GE Capital’s experience as both an early adopter and integral part of the evolution of XML messaging.

Part II. The GE Experience

GE was among the early adopters of the version 2 customer credit transfer initiation message and associated payment status report. The primary objective was to simplify and standardise the cash management architecture, with the original intention of sending the same core message to its core banking partners. However, GE encountered challenges due to slightly different interpretations and implementations within each banking partner, which ultimately resulted in a series of proprietary implementations of the XML messages. This represented a design sub-optimal that offered limited portability with the associated higher maintenance costs.

Given the complexity, inefficiency and cost that still existed, GE decided to migrate to the version 3 messages, following the work of the CGI working group. The CGI implementation guidelines provided a good foundation. Through initial consultative discussions with Citi, GE was able to build a more generic core messaging template covering the customer credit transfer initiation message (pain.001.001.03). This core template design, leveraging the CGI principle of data over-population, was initially piloted across nine countries in Africa and Latin America. The design phase commenced in May 2012, and all countries went live by the following December and covered a number of different payment instruments. This significantly reduced the need for proprietary implementations, reducing the overall duration for a particular PAIN001 implementation by 60%. Maintenance costs have been reduced too, as training support resources can be done much faster.

The base design also provided the foundation to support a timelier single euro payments area (SEPA) migration, with the core template requiring minor modification to support the initiation of SEPA payment transactions. It is evident to GE that this approach has helped it simplify the design, development and testing phases in addition to providing a more portable and low cost maintenance environment. GE has continued to leverage the initial core template to roll-out version 3 messages across its core banking partners, with minor modifications required to primarily support any local in-country rules – such as central bank reporting and tax IDs.

While a high degree of simplification and standardisation has been possible with the customer credit transfer initiation message, this has not been possible with the associated payment status report (pain.002.001.03). Due to bank capabilities, typically linked to the SEPA and non-SEPA banking partners, GE has been forced to build two payment status report maps, as opposed to maintaining a single core template. Although not ideal, the migration to version 3 has provided a cash management architecture that is more resilient, scalable and low-cost than could ever have been achieved using either the version 2 messages or indeed any other industry standard file format.

Summary

ISO XML continues to emerge as the dominant messaging solution in the corporate to bank integration space. While there are clearly considerations around which version represents the optimum solution for you, both still provide a workable solution and, more importantly, Citi and its have no plans to sunset the original version 2 message. Clearly the version 3 message provides greater opportunity to achieve a more bank-agnostic implementation because of the work of the CGI group and should always be considered for new initiatives. However, there are still perfectly valid reasons to move forward with a version 2 implementation as this offers the opportunity to achieve the same, with a little more project discipline.

In terms of a migration from version 2 to 3, this is not something the authors would actively encourage, given the associated costs and the underlying assumption that the solution is working. However, we also appreciate that there may be strong commercial reasons why a migration is required, as justified by GE Capital.

Comments are closed.