In the IT world, process optimisation demands that the four key pillars of integration, interoperability, compatibility and portability are met. In the context of financial data exchanges between banks and corporates, the key to success is the adoption of the appropriate standard. Today this means XML. In this Section we look at what it is, how it is used and how best to deploy it.

“The nice thing about standards is that you have so many to choose from.” This aged quote from computer scientist, Andrew Tanenbaum, will resonate with most treasurers today, particularly those operating cross-border. However they are resolved, the desire to bring order to processes so that they may be used and understood in a broad context is laudable. But the enthusiasm with which standards setting bodies take up the reins can sometimes seem like the creation of new models just because they can. Certainly, there is little or no obligation to use their output, but when proclamations as to the way certain activities are believed best executed are stacked up alongside each other, the volume of work required to implement them to achieve process unification may appear as daunting as overcoming the original problems the standards try to fix.

That said, there are some standards that seem to have gathered momentum to the extent that they are indeed a ‘standard’. In the world of treasury technology, few would not recognise the work of the International Standards Organisation (ISO) in establishing ISO 20022 as the model for the way financial data is exchanged between corporates and financial institutions.

With its genesis in the main due to the proposal and eventual delivery of the Single Euro Payment Area (SEPA), ISO 20022 is a standard that not only works as intended but also has potential to reach far beyond, offering a credible standard approach that helps smooth the flow of transactions. For all counterparties in a transaction, this is a good thing.

In today’s increasingly complex and volatile global financial markets, few matters are of greater importance for companies and institutions than the ability to exchange financial data in a standard and efficient manner. But it was not so long ago that 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 when, in 2003, ISO developed a new messaging standard specifically designed for the financial services industry: ISO 20022.

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

ISO 20022 was not created to replace any existing incumbent messaging standards and syntaxes. 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: The Treasurer’s Guide to Digitisation 2015

Driving SEPA

If, as mentioned above, the ISO 20022 messaging standard is associated with one thing above all else, then it is 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 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 the adoption and roll out of SEPA across Europe.

ISO 20022 alongside the XML-based messaging format in the two live SEPA schemes means that, for the first time in payment processing history, the entire end-to-end transaction flow can 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 be supported as well,” says Frank Van Damme, a standards consultant at trade finance platform provider, Bolero. Van Damme, who was involved in development of the standard, explains that if a bank standard was created that only looked at the information needed by the banks it would be “difficult to support the needs of the corporates that are the basis of the transaction between the banks”. Indeed, the need for remittance information is not, for example, a need from a pure bank point of view.

However, ISO 20022 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 is a real prospect for corporates in Europe now, facilitated by the across-the-board adoption of ISO 20022 XML payments standards.

A global proposition

The hype around SEPA as it slowly gained ground and became a reality led many to believe ISO 20022 XML is a Europe-only set of message standards. It is not. 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, albeit at a varying pace.

A number of major banks, corporates and technology vendors are 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 effort is to simplify implementation for corporate users and, thereby, to promote wider acceptance and adoption 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 box overleaf), and so replacing the need for corporates to support bespoke, domestic formats.

More than SEPA

Having 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 requesting technology that will allow them to automate the process of opening, closing and managing their many global bank accounts. With a typical corporate working with on average 15 to 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 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 can be defined, as can electronic mandates. Together with another SWIFT initiative to replace wet signatures, 3SKey, these XML messages would, in theory at least, allow corporates to perform the majority of bank account management functions electronically, promoting harmonisation, standardisation and traceability.

ISO 20022: current active payments message sets (each has multiple sub-categories)

The concept contributes the greatest added-value to international firms with a centralised structure and numerous subsidiaries, but currently there is frustration with the lack of progress with electronic bank account management (eBAM). Anecdotal evidence suggests that banks are slowing the process because their IT budgets, post the global financial crisis, are heavily skewed to compliance, despite the considerable savings that banks themselves could enjoy with better BAM processes.

EIPP: standard bearer

Aptly, the European agenda on e-invoicing using XML format is being pushed as a means of linking invoices to payments. It affords the ability to make a payment against real electronic invoices and provides a real change in the industry in terms of control and transparency over the transaction and the reconciliation of a corporate’s payment activity. Once companies have this electronic invoicing information coming together with the payment information, they can converge the working capital of the supply chain activities with cash management.

This matches current ongoing trends where treasurers are looking for more visibility. Getting information faster, with more accuracy, helps treasuries manage working capital activities as well as protecting against fraud and money laundering.

Efficient e-invoicing and processing has thus been on many a corporate treasurer’s wish list practically since the birth of the internet age in the 1990s. One other noteworthy innovation set to receive a boost from ISO 20022 is true electronic invoice and payment processing (EIPP).

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 back in June 2013, e-invoicing accounted for between 4% to 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 (not least with some governmental and EU directives and encouragement).

However, figures offered by e-invoicing firm Billentis, in 2016 show that employees are still strongly focused on paper processes, regardless of the fact that tax-compliant electronic, original invoices are available. Paper copies are often produced for convenience reasons and in Germany it reports that 69% of receiving companies print e-invoices (35% of large, 77% of mid-sized and 73% of small businesses). In the LATAM countries between 60-70% of the e-invoice volume is estimated to be printed by the invoice issuers and sent to receivers in parallel to existing and valid e-invoices (50% of large and 90% of other businesses).

There is clearly a habit to break before full acceptance of e-billing is achieved. Industry and government initiatives have strongly pushed the evolution from invoice images towards structured invoices or even hybrid files. An example of the latter is the ZUGFeRD (Zentraler User Guide des Forums Elektronische Rechnungen Deutschland or Central User Guidelines of the Forum for Electronic Billing in Germany). This creates a file format for the standardisation of electronic invoices, combining both machine-readable XML and human-readable PDF formats in a single file.

The final push to XML

XML adoption is now widely considered to be best practice. Even if not mandated to migrate, like European companies in the run-up to February 2014’s SEPA deadline were, moving to XML is something few treasurers today can afford to ignore. With that in mind, what does the migration process ISO 20022 XML typically involve?

Before anything can be done, the treasurer first needs to ensure that their systems – internal and external – support XML formats. For those 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. 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.

The complexity, risk and cost of conversion perhaps explains why third-party service providers proved a popular way to ensure compliance ahead of the SEPA deadline. For those not to use a third party, there are a number of steps that can be taken to ensure that an ISO 20022 migration project is relatively smooth:

• 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 an 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 the use of XML is in line with the implementation guide before going 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.