Underpinning the cold, administrative-like nomenclature of ISO 20022 concept is a common language that has the capacity to streamline and lower the costs of a number of corporate-to-bank messaging processes. Treasury Today looks at the story so far.

As a universal financial industry messaging scheme, ISO 20022 can be considered ‘state of the art’. Whereas EDIFACT, the UN-developed international electronic data interchange standard, tried to tackle the issue of message harmonisation and straight through processing, it has had limited success, largely because it has not been accepted as an international standard. ISO 20022 XML is different. With the push given by the mandated arrival of SEPA and the consequent embedding of its technical make-up into most ERP and treasury management systems, it has already achieved the kind of support necessary to help make it part of the everyday language of international treasury.

The standard was developed within the Technical Committee TC68 – Financial Services of ISO – of the International Organisation for Standardisation. The first edition, published in December 2004, proposed a standardised XML (extensible mark-up language) based syntax for messages. This would prove to be its saving grace. The inaugural communications for payments were approved in September 2005.

ISO 20022 (previously known as UNIFI) is by no means a static proposition and the changes keep coming to handle new needs like immediate payments (the ISO Real-Time Payments Group, made up of over 50 global experts, is tasked with driving forward the project of developing the ISO 20022 messages required). The breadth of ISO 20022 has also expanded from payments to cover areas including securities, trade, cards and foreign exchange.

Today, ISO 20022 is used both for market infrastructures and for corporate connectivity. Market infrastructures means bank-to-bank execution of payments via the central bank for most RTGS or a local central bank approved clearing house for most local low value payments. Corporate connectivity describes corporate-to-bank communications such as sending payment instructions to, and receiving statements from, a bank. Most central banks and clearing houses – in almost every major country around the globe – have increasingly bought into ISO 20022 as the best way to manage local clearing.

The XML part of the equation is the machine language counterpart to the more familiar HTML (Hyper Text Markup Language) found in every web page: XML carries data whereas HTML defines how it should be displayed: XML is purely a software- and hardware-independent means of encoding, storing and transporting data. But whereas HTML has a way of wrapping up a message in predefined computer ‘tags’, XML tags have no such definition and need to be written in order to send, receive, store or display the wrapped content. ISO 20022 formally standardised those tags, creating a uniform messaging tool that could traverse the financial space; the implementation of SEPA could not have been achieved without it.

SEPA gives rise

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. The EC decided that SEPA credit transfer (SCT) and direct debit (SDD) schemes should use a subset of ISO 20022 messages. With the XML-based messaging format, it 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.

If one corporate works with a specific bank and ERP system, and another corporate works with a different bank and ERP system, they can use the same XML format instead of going through a migration exercise and customising XML for each of these relationships.

It also now means that if one corporate works with a specific bank and ERP system, and another corporate works with a different bank and ERP system, they can use the same XML format instead of going through a 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 a real prospect for corporates in Europe, facilitated only by the across-the-board adoption of ISO 20022 XML payments standards.

Because of all the hype around SEPA, it may be easy to mistake ISO 20022 XML as a Europe-only set of message standards. But it was always intended to be used in every domain of the financial world. Indeed, ISO 20022 allows 65,536 characters which is enough to handle all known writing systems, hence its adoption by many ‘non-Roman’ language based market infrastructures. It is used, for example, for clearing in China (CNAPS2), Japan (Zengin and BoJNet) and Russia (CMPG).

ISO 20022 is as broad in its functional reach as it is in geographic spread. Whereas SWIFT’s FIN MT standards were designed only for cross-border high-value flows like FX settlement, ISO 20022 covers the likes of cheques, bank drafts, local low value (like payroll), bulk payments, cross-border and trade transactions. FIN was ‘patched’ to handle some of these needs, but saw each bank create its own workaround. This caused many difficulties for treasury interconnections, and major operational risks as market infrastructures around the world upgraded to offer new services like immediate payments. ISO 20022 offers standards for every conceivable message a corporate treasurer would want to send, and many more for other financial purposes (see table below).

Keeping ahead of the game

The flexibility of ISO 20022 means it is not actually necessary for corporates to use it to instruct their banks to make payments through ISO 20022 market infrastructures: traditional EDI formats such as ANSI X12 and UNI/EDIFACT, or even Excel, may be used. Corporates can also use ISO 20022 to instruct their bank to pay over legacy market infrastructures like ACH, FIN or even cheque – with standards available for how to execute each. The more market infrastructures move to ISO 20022, the more compelling it is for corporate connectivity and the more it will become the ‘de facto’ model.

However, there is a need for more than just new message-types in the corporate-to-bank space; there is a need to manage market practices, to avoid such workarounds and ensuing inefficiency. SWIFT has developed a number of tools to try to help corporates and banks work together. The key to co-operation is the CGI-MP (Common Global Implementation-market practice) Group. This is the new, more focused name for the old CGI, remaining the same group of industry stakeholders (mainly banks, corporates, market infrastructure providers and vendors) who have come together with the intention of creating a singular approach to SWIFT messaging standards, and now including all those under ISO 20022.

In practice, CGI-MP seeks to build a uniform layer on top of the basic message formats. It recommends how these messages should be best used in the corporate world. Banks can still develop their own specifications on top of CGI-MP as a third layer as they will have some competitive proprietary tools that require this approach but global adoption by market infrastructures and rapid standardisation of corporate connectivity by GCI-MP mean that ISO 20022 is effectively future-proof.

Whatever new payment technologies come along from now on, they will most likely be cleared using ISO 20022. And even if not, the global breath and coverage of CGI-MP should mean that corporate connectivity standards will be developed at the same time as any new payment systems are rolled out. This in turn ensures that treasurers using ISO 20022 are effectively hedging themselves against the operational risk and cost of future developments in payment technologies and services.

Moreover, being a global standard developed by corporates, banks and system vendors means that ISO 20022 is well-supported by corporate systems: indeed, almost all ERPs and TMSs have in-built ISO 20022 functionality. In effect, treasurers using ISO 20022 can lower their costs and operational risks by using established and well-known standards as opposed to implementing the likes of bank proprietary standards or Excel interfaces.

Despite the best efforts of CGI-MP there is a persistent myth that ISO 20022 is not globally standardised. In most cases, this stems from treasurers’ perception that ISO 20022 does not take away local requirements like withholding tax in Thailand, Boletos in Brazil or purpose codes for payments in Chinese RMB. What CGI-MP can and does do, is to standardise the way these local nuances should be coded in ISO 20022 messages, so that treasurers only need to figure it out once for it to work with all banks. Where treasurers may be dealing with countries that have not yet been standardised by CGI-MP, it may be time to step up and join CGI-MP.

Other use cases

Although SEPA was the 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. It is easy to 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.

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 was designed to cope with a range of different business scenarios including account opening after KYC, account closing, signatory and mandate management and 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 can be defined, as can electronic mandates. Together with another digital 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 adoption of ISO 20022 gathers pace, so too may eBAM follow. If 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.

Another noteworthy innovation that could receive a huge boost from increased ISO 20022 uptake is e-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.

Even if not mandated to migrate, like European companies were in the run-up to SEPA in February 2014, moving to these standard XML formats is something which treasurers today should seriously consider.

Although adoption of such solutions allows 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 standards. In Europe, for example, according to figures published by the European Commission just two years ago, e-invoicing accounted for between 4% to 15% of all invoices exchanged in the region. The 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. This would represent a big step towards the ultimate goal of automation right across the corporate value-chain.

Migrating to XML

The process to migrate to ISO 20022 XML typically begins with the treasurer first ensuring that both internal and external systems 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 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; for most international vendors this change would be applicable anywhere.

For treasurers 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 are a number of simple steps which can be taken to ensure that an ISO 20022 migration project is a smooth one:

• Establish a centralised governance and management structure.

  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. This will include processes such as drawing up a detailed project plan and taking into account the necessary investments needed for the project, writing rulebooks, and creating an implementation guide.

• 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. Another lesson from 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 specifications, 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 impact your project 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 – such as SWIFT’s MyStandards Readiness Portal – are able to point out exactly where problems occur by highlighting the data field and provide a direct link to the section of the implementation guide or rulebook that explains how to fix it.

Moving to XML is now widely considered to be best practice. Even if not mandated to migrate, like European companies were in the run-up to SEPA in February 2014, moving to these standard XML formats is something which treasurers today should seriously consider. The benefits of operating with this standard, in terms of the efficiency gains of end-to-end processing across the entire supply chain, cannot be ignored. As the harmonisation work on XML standards drives yet further adoption and promotion, the alternatives, such as EDI (which is still used in most bank systems because customers still use it), seem to be heading to the history books. ISO 20022 XML, looks like being the future of financial messaging.

Any readers who require more detail on the key features of ISO 20022 should visit the dedicated ISO website: www.iso20022.org