XML: An Accelerator for SEPA Implementation and Standardisation
The Extensive Mark-up Language (XML) uses human language, which is conversable, and not the language used by computers, which is binary and ASCII coded. XML is even readable by people who have had no formal introduction to this language nor have been coached on it.
XML is an extremely portable language to the extent that it can be used on large networks with multiple platforms such as the internet. XML allows users to create their own tags with no constraints linked to standards or pre-determined by software vendors.
The use of XML brings technical benefits to both banks and companies, such as:
XML is accessible to everyone and therefore enables the creation of basic business applications. For example, someone willing to run an e-business from home can easily manipulate their own data (available stock, product references, etc) on an XML application. Today, banks tend to use XML, not for the good technical reasons listed above, but to either become compliant with SEPA or to satisfy specific corporate demands.
Market practices, and specifically the way banks use standardised messages, need to change. XML opens up a real opportunity to bring technical and functional improvements to all actors in the financial sector.
First, France’s migration to XML is about protocol and banking communication. The ETEBAC protocol does not support XML messages. In France, the ETEBAC migration is due to end this summer. This change of technology and equipment for companies is accelerating the SEPA migration since new protocols, such as EBICS or SWIFTNet and other IP-based protocols, can transfer XML messages.
Second, the migration is also about the new SEPA payment instruments. XML messages are the prerequisite to SEPA Credit Transfer (SCT), SEPA Direct Debit (SDD) and the SEPA Card Framework. Globally, the regulator mandates that corporates use ISO 20022 for euro payment initiation in the SEPA zone.
The International Organisation for Standardisation (ISO) is a non-governmental organisation (NGO) and the worlds’ largest publisher of international standards. Thanks to joint efforts mainly between ISO and SWIFT, but also with the participation of other organisations, the ISO 20022 norm was created to structure financial messages (payment, foreign exchange (FX), securities, and trade services). The two main objectives behind this norm are:
This means that banks and corporates have to use a set of messages in a standardised XML syntax based on ISO 20022. In addition, now that the SEPA end-date regulation has been approved by the EU Parliament and ratified on 28 February 2012, the European Payment Council (EPC) confirms that banks and corporates need to “speak XML”.
Within the payments business domain, there are messages supporting the following business areas:
XML file formats are variable, as opposed to the CFONB (the French Committee for Banking Organisation and Standardisation) format. The SCT and SDD Scheme Rulebook allows for a maximum of 140 characters for structured and unstructured remittance information. The information is delivered to the beneficiary without alteration or omission. In addition to information formatting, ISO 20022 also incorporates reporting functionalities capable of carrying all bank account reporting with transaction hierarchies in a structured way. This is a great opportunity for companies to improve their reconciliation processes.
Another significant benefit for treasurers running large businesses is the use of one single payment format for all subsidiaries and the possibility to standardise and reduce commission fees between banks. Some treasurers will take the opportunity of a SEPA migration and the use of XML to reduce the number of banking partners, as well as the number of accounts.
The adoption of XML provides treasurers with enhanced payment workflows within the company, with automated reconciliation and reduction of bank charges.
Currently and until the end of the migration period (1 February 2014 for euro-denominated Member States and 30 October 2016 for those Member States that do not have the single currency), SEPA payments and, therefore, XML messages have to include the Bank Identifier Code (BIC), which is mandatory, and International Bank Account Number (IBAN) data as an option. After migration, corporates will be required to provide IBAN information only.
Several recent studies pointed out that a number of companies in the travel, leisure and gaming industry had more errors in their account information than companies in other sectors. These errors in payment data (generally wrong BICs or wrong account numbers) are recurrent in the countries from which the payment is initiated and the countries with which the company is doing business. Thanks to XML, processing of such payments will be enhanced in future.
Accordingly, the move to SEPA underlying XML adoption is a great opportunity for treasurers to check their data and supplier references. It is the occasion to anticipate and avoid errors, rejections and other ‘R’ transactions.
A few points are still outstanding however:
The banking industry must improve certain services to satisfy new customer expectations. The electronic bank account management (eBAM) made of XML messages is a fantastic solution to dematerialise account management processes. Current processes are paper-intensive and time-consuming. eBAM will not eradicate paper-based methods and Know Your Customer (KYC) processes (which stay with the relationship manager) but account opening, account closures and changes in mandates can be easily sent in XML messages through the central utility. eBAM will also help treasurers reduce costs and boost efficiency by allowing corporates to open and/or close accounts online.
During Sibos 2011, SWIFT presented the eBAM pilot and study observations to banks, corporates and key vendors. Now the eBAM solution seems to be live with very few banks and corporates, and a set of XML messages is already defined.
But the market is not jumping onto it and the solution has yet to be extensively deployed. Why is this? There are several reasons:
From a bank perspective, the list of users that went live on eBAM is limited to the ones that were part of the pilot phase. Last but not least, a minority of treasurers are actually making use of new technologies such as mobile devices, software-as-a-service (Saas) or cloud-based solutions, which is not helping in a rapid adoption of the new benefits. Specific products such as eBAM are attractive but still not commonly used by corporates because of technology aversion.
From a technical perspective, XML has been a work in progress for the last 10 years or so. From a functional perspective, XML has been seen as an accelerator for SEPA implementation. However, the big benefit of XML is to push for interoperability and standardisation on financial markets. Once fully in place, the relationship between banks, corporates and other financial institutions will be completely different.
But at this stage, not everyone is ready. Every company is different and as a result the business case regarding the usage of XML for any organisation may vary. It is important to determine the impacts of its XML-based SEPA projects in order to identify the business, IT and migration challenges behind it. This is the way towards a new area for banking communication.