ISO 20022 is changing the way financial data is exchanged between corporates and financial institutions. In this Section, we look back at what spurred the development of the messaging standard in the beginning and why, both in terms of geography and function, it is about much more than the Single Euro Payment Area (SEPA) initiative.

In today’s increasingly complex global financial markets, few matters are of greater importance to companies and institutions than the ability to exchange financial data in a standard and efficient manner. But until very recently, a financial system characterised by proprietary, country or regional messaging formats meant such efficiencies were all but impossible to attain.

Improved interoperability was required, but integrating such systems was difficult and costly. It often required specific interfaces to be built for each system combination in order for data to be mapped and translated between various applications. A solution to this thorny issue only began to emerge (adoption is still gaining traction) when, in 2003, the International Standards Organisation (ISO) developed a new messaging standard specifically designed for the financial services industry, ISO 20022.

ISO 20022 uses extensible markup language (XML), an open standard in which rules are defined that allow for messages and documents to be encoded in a consistent manner.

That, perhaps, is the most ingenious aspect of the ISO 20022 design. It was not created to replace any existing incumbent messaging standards and syntaxes, as such. Rather it was intended to be used as a method for developing standards, and a framework by which different messaging syntaxes could be made to co-exist. With its arrival the financial world finally had a cost-effective and efficient way of developing and implementing interoperable message standards: a way to make different standards co-exist with one another, whilst preparing the way for migration to a single standard.

Chart 1 illustrates how the interfacing between co-existing standards is simplified when ISO 20022 modelling is used, showing how only two data translation interfaces are required for each standard, eg into and out of the one model.

Chart 1: The complexity of messaging formats

Source: Treasury Today magazine

The SEPA factor

If the ISO 20022 messaging standard is associated with one thing, above all else, it is the Single European Payments Area (SEPA). When SEPA instruments were first introduced back in 2008 and 2009, the European Commission (EC) required a uniform messaging format to be used for payments across all the SEPA zone markets.

It was deemed important by the Commission that data formats used for SEPA were more than a mere European standard. On that basis, the EC decided that the Single Euro Payments Area (SEPA) credit transfer (SCT) and direct debit (SDD) schemes use a subset of the ISO 20022 messages. It was an endorsement which has since proved a key driver for adoption for SEPA in Europe.

ISO 20022 alongside the XML-based messaging format in the two SEPA schemes meant that, for the first time in payment processing history, the entire end-to-end transaction flow could be executed using the same standard for payment initiation, clearing and reporting. “This ensures that the business needs of parties involved earlier or later in the process can supported as well,” says Frank Van Damme, Bolero, who was involved in development of the standard. “If you were to create a standard between the banks and only look at the information the banks need it will be difficult to support the needs of the corporates that are the basis of the transaction between the banks. The need for remittance information is not, for example, a need from a pure bank point of view.”

It also means that if one corporate works with a specific bank and enterprise resource planning (ERP) system, and another corporate works with a different bank and ERP system, they now both use the same XML format (instead of going through a tedious migration exercise and customising XML for each of these relationships). For corporates, the increased homogenisation of payments around direct debit and credit transfers has become real prospect for corporates in Europe now, facilitated by the across-the-board adoption of ISO 20022 XML payments standards.

Around the world

Although it may be easy, because of all the hype around SEPA, to mistake ISO 20022 XML as a Europe-only set of message standards, it is available beyond the borders of SEPA and, in fact, its adoption has been on the agenda for a number of corporates and banks worldwide in recent years.

A number of major banks, corporates and technology vendors have been working together to ensure the success of the standard at the global level. The Common Global Implementation (CGI) Working Group, established in 2009, is perhaps the most notable example of such industry-wide collaboration. The overriding objective of the CGI Working Group’s work is to simplify implementation for corporate users and, thereby, to promote wider acceptance of ISO 20022 as the common XML standard used between corporates and banks. It is a mission which will be achieved, the group says, “through consultation and agreement on common implementation templates for relevant ISO 20022 financial messages, leading to their subsequent publication and promotion in order to obtain widespread recognition and adoption.”

Through the CGI initiative, over 30 banks and a handful of technology providers have collaborated to approve a suite of ISO 20022 XML standards that can be used for many different payment types (see Table 1), and so replacing the need for corporates to support bespoke, domestic formats.

Source: www.iso20022.org/payments_messages.page

More than SEPA

Having already overcome the challenge of introducing XML as part of their SEPA migration, European corporates are now looking at some of the other ISO 20022 XML-based solutions offered by banking partners and technology vendors. As Van Damme explains, “Although SEPA was the main and most visible – and influential – early adopter of the standard, ISO 20022 was intended to be used in every domain of the financial world.”

One of these is Electronic Bank Account Management (eBAM). For many years now, corporate treasuries have been demanding technology that will allow them to automate the process of opening, closing and managing their many global bank accounts. One can easily understand why. With a typical corporate working with on average 15 – 20 different banks, each likely to be governed by different local regulations, even making simple amendments to an account using traditional manual, paper-based methods can often become a very time consuming process.

But SWIFT had an idea. Collaborating with a select group of banks, solutions providers, and corporates, SWIFT established and piloted 15 standard eBAM ISO 20022 XML messages each of which is designed to cope with a range of different business scenarios including:

• Account opening after KYC.
• Account closing.
• Signatory and mandate management.
• Reporting.

After some corporates expressed frustration regarding omissions to the original standards, ISO proposed some changes and a new version of the eBAM standards was certified by the group in 2013. Unlike the initial versions, the new standards allow, for example, a group of signatories to be defined, as well as electronic mandates. Together with another initiative to replace wet signatures, 3SKey, these latest XML messages would, in theory at least, now allow corporates to perform the majority of bank account management functions electronically.

Although corporate uptake of eBAM solutions to date remains minimal (as of May 2015, SWIFT counted 32 corporates and 18 banks), there is reason to believe that with region-wide adoption of ISO 20022 now near fully complete, Europe may be about to witness a spike in adoption. Once it does, the consolidated and accurate cross-border bank account information workflows it will establish will bring a host of different benefits to treasury teams, including greater automation, improved risk management and security and a much simplified compliance processes.

E-invoicing

One final noteworthy innovation set to receive a huge boost from ISO 20022 is electronic invoicing. Efficient e-invoicing and processing has been on the corporate treasurer’s wish-list practically since the birth of the internet age in the 1990s.

Although adoption of such solutions offers a great means for companies to improve working capital and supply chain finance processes, uptake to date has been hampered by a combination of legal uncertainty and the absence of common pan-European standards. According to figures published by the European Commission in June 2013, e-invoicing accounted for only 4-15% of all invoices exchanged in Europe. But a lack of common standards is less of an issue now that the industry has defined an XML format for e-invoicing, based on exactly the same data elements as SEPA XML. Consequently, industry experts believe companies will make a big push towards implementing e-invoicing in the years ahead.

If e-invoicing and SDD with an XML theme does finally begin to take off now it would represent a big step towards the ultimate goal of automation across the value chain. In fact, it may well be the final piece of the jigsaw in terms of XML integration.

Migrating to XML

As we have explained in this Section, moving to XML is now widely considered to be best practice. Even if you are not mandated to migrate, like European companies in the run-up to February 2014 were, moving to these standard XML formats is a need which treasurers today can ill afford to ignore. With that in mind, what does the migration process ISO 20022 XML typically involve?

Before anything else can be done, the treasurer first needs to ensure that their systems – internal and external – support XML formats. For those who are already using SWIFT or a modern electronic proprietary banking system this is not likely to be a problem, but any systems provided by smaller, local banks or running older software versions will almost certainly need to be replaced or upgraded. In the case of internal systems, most ERP and TMS vendors modified their systems in the run-up to the SEPA deadline in order to support XML. However, for those not using fully up-to-date versions the upgrade process can be complex, lengthy and expensive, particularly for companies that have multiple ERP systems in operation. This perhaps explains why third-party conversion services proved a popular way to ensure compliance ahead of the SEPA deadline.

For those that decide not to use a third party, there a number of simple steps can be taken to ensure that an ISO 20022 migration project is a smooth one:

• Establish centralised governance and management structures.

  One of the biggest challenges, given that every company has its own sets of competing priorities, is securing sufficient IT resources for the project. In such cases, setting up a centralised team can help facilitate buy-in from the top decision-makers within an organisation thereby ameliorating the issue somewhat. This central unit will also be crucial for developing and coordinating the process; drawing up a detailed project plan and taking into account the necessary investments needed for the project, writing rulebooks, creating and implementation guide, to name a couple of examples.

• Secure a budget.

  Once the scope of the project is known, a central budget should be drawn up. Some treasurers whose departments completed ISO 20022 XML migration as part of their SEPA compliance projects are on record as saying a phased approach with commitments spread out over a long period is preferable to project funding that is monolithic in nature and sought from the outset. One of the lessons of SEPA is that there was a tendency for companies to underestimate the cost of migration at the outset.

• Determine the timescale for implementation.

  A plan should be established that includes approximate timeframes for the migration. This should cover everything from writing technical documents, making IT changes, testing, going live, and decommissioning legacy systems. When doing this it is worth noting that resources of your banking partners may also be constrained and this might impact the turnaround times for the XML files they are producing, which may in turn affect your projects timeline.

• Make use of validation portals.

  For a corporate, being able to test whether their use of XML is in line with the implementation guide before they go live is vital. Validation portals can be very helpful in this respect. Many of these portals can even point out exactly where problems occur by highlighting the data field and providing a direct link to the section of the implementation guide or rulebook that explains how to fix it.