XML is so much more than the Single Euro Payments Area (SEPA), argues Dieter Stynen, Head of Cash Management Corporates (CMC), Western Europe, and Head of Global Transaction Banking Belgium, Deutsche Bank. Corporates need to look beyond SEPA-compliance and use XML as a way to make treasury operations smoother and more efficient across their global operations.
Dieter Stynen
Head of Cash Management Corporates (CMC), Western Europe and Head of Global Transaction Banking, Belgium
While his first experience was in the chemicals sector, Stynen started his career in banking in 1996 with the Bank of New York Mellon as a Customer Service Officer for global custody clients. He joined Deutsche Bank in 1998 as a Cash Management Sales Advisor in the local Benelux/France sales team. After four years, he moved into the treasury solutions team and was made head of the Europe, Middle East and Africa (EMEA) region in 2009. In July 2012, Stynen was appointed Head of Sales for Corporate Cash Management (CMC) for Western Europe. He holds a Masters degree in Applied Economics from the University of Antwerp, Belgium, and an MBA from the Katz Graduate School of Business, University of Pittsburgh, US.
When the Single Euro Payments Area (SEPA) instruments were first introduced, in January 2008 for SEPA Credit Transfers (SCTs) and November 2009 for SEPA Direct Debits (SDDs), the governing bodies – the European Payments Council (EPC) and European Commission (EC) – needed a uniform message format across all SEPA zone markets. They chose eXtensible Markup Language (XML) to replace domestic formats for automated clearing house (ACH) transactions, payments, collections and direct debits. Adopting XML as a standard was a crucial component in the migration to SEPA.
However, when the XML specifics were submitted to the banks and software vendors for integration into their products, each one began customising the format and several different XML versions appeared in the marketplace. This obviously goes against the basic premise of SEPA, which is to transact in a uniform and harmonised way across all the countries in the SEPA zone.
In response, various transaction banks, software vendors, corporates, SWIFT and other industry organisations came together to agree on a common XML standard, which is the International Organisation for Standardisation (ISO) 20022. This 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 can both use the same XML format, instead of going through a tedious migration exercise and customising XML for each of these relationships.
This is also how the Common Global Implementation (CGI) initiative came into being in October 2009, when SWIFT hosted a meeting with various stakeholders in order 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”.
The industry’s commitment to have one truly uniform format is what makes XML different from previous global standards, such as EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport) and SAP’s proprietary format IDoc, both of which come in many different flavours.
Today the ISO 20022 standards have been published and every bank can decide whether it will offer XML to its clients – however, it is not mandatory. The vast majority of the bigger transaction banks and ERP vendors are offering the format, following ISO standards, and the bigger corporate clients are demanding it – many are bringing together in the same room their top global banks to ensure that the format is the same across the different banks.
As a result, the XML format is becoming increasingly standardised at the global transaction bank level. However, the smaller domestic banks are not as far advanced in adoption levels. This may be because domestic banks view SEPA more as a costly compliance project than a revenue generator; they just do not have the critical volumes needed to justify investing in every feature of SEPA. Conversely, the global transaction banks, such as Deutsche Bank, can see the benefits and will be able to attract additional transaction volumes, so it is a win-win situation for us.
Benefits of XML
Many corporates look at SEPA solely as a compliance project, as something that they are being forced to do. But it is a catalyst for transforming treasury, and XML can be leveraged for transactions beyond the scope of SEPA. As a leading transaction bank, Deutsche Bank can help corporates realise the full benefits. No longer do corporates have to grapple with multiple domestic formats – they can use XML for all their transactions across the globe. Corporates need to look beyond the compliance part of the project and use XML as a way to leverage SEPA to make treasury operations smoother and more efficient.
In addition to improving efficiency, adopting XML will also save corporates’ time, resources and money, as they will avoid having to keep up with multiple format changes in many different jurisdictions. Many corporates view this as a continuous change programme – today they are updating the format for Belgium, tomorrow they will change it for the Ukraine, etc. By working with the same format in all countries, a corporate’s maintenance cost will significantly go down.
Furthermore, XML makes the whole implementation process much easier, less time consuming and less resource intensive by standardising the information needed for each transaction type. This reduces implementation and development time: previously if a company was expanding into new countries, it had to test and developed several formats; now it only has to develop and test one format for the entire range of countries involved in the process.
Case Study
Migrating to XML
Arnaud Lajoinie
Financing and Treasury Department – Head of Project and Organisation
When did the LVMH – Moët Hennessy Louis Vuitton group start planning its migration to XML, and which particular challenges were top of mind?
We first thought about implementing a group platform for bank communication in early 2010. This idea was driven by the planned closure of ETEBAC – the French bank-corporate data communications network developed in the 1980s – and the possibility to use only one format (ISO 20022 XML) together with SWIFTNet for exchanging financial instructions with most of the banks worldwide. In addition, by using the XML format we could tackle SEPA at the same time.
Bank communication is a complex issue, so this was a massive change for many French corporates, particularly for a major group like LVMH with a portfolio of over 60 prestigious subsidiaries, each with its own communications solution. But we also realised that building a bank communication platform for the group was a great opportunity to rationalise LVMH’s bank partners per country, improve cash visibility and establish high standard security norms across the group.
In March 2010, most of the group’s treasurers met to discuss this topic and decided to build and on-board a global communications solution based on SWIFT and XML. Despite each of our brands operating independently – they are not dependent on LVMH and therefore could have opted out of a global solution – securing buy-in was not difficult. We were one of the first adopters of SWIFT back in 2007, which made it a ‘pressure-free’ decision, and there are obvious treasury benefits to be gained from a global solution. For example, some of our brands – such as Louis Vuitton – are present in more than 80 countries, and any platform that can allow them to increase cash visibility and security over all affiliates can only be a plus.
When the solution first went live, it was only used by the holdings. The on-boarding of affiliates was a real breakthrough in the process. The main challenge that we faced was the establishment of an organisation able to support all our affiliates as they behave independently and have their own systems.
What benefits will XML provide LVMH outside the scope of SEPA?
For us moving to XML goes beyond the migration to SEPA. We consider SEPA to be the catalyst rather than the driving force for XML. SEPA has had a clear impact on European banks, focusing their energy on rolling out XML capabilities.
Indeed, XML itself goes well beyond SEPA. SEPA migration alone will be responsible for around 70%-80% of bank flows for European companies, but XML can be used for all payments/collections and countries outside Europe. When you think of the number of different local payment formats – there are over 100 in Europe alone – the ability to deal with just one is ideal from an ERP perspective.
Using XML means we can standardise and dematerialise our transactions, which is more efficient and cost effective. Dematerialisation through the richness of XML is a great opportunity to eliminate the last paper-based transactions, which the local formats could not support. That is why we did not offer our affiliates the option to convert their local format into XML.
What were the specific operational challenges associated with XML migration? And how were the difficulties managed?
The issue of generating IBANs and Bank Identifier Codes (BICs) is often cited as a challenge, but this wasn’t the case for us as we put the necessary tools in place using SWIFT repositories. The key challenge for us was the issue of bank discrepancies and dealing with local means of payments.
Uniformity between banks is a real challenge with respect to XML, especially in London and Hong Kong. We spent a lot of time with our banks in an effort to convince them to use the format in the same way – particularly with respect to the use of Japanese and Chinese characters and bank cheques. Banks need to work in the same way, and we had – and still have – to really push for the required uniformity.
Did XML migration differ between Europe and the US? How did you time the transition and manage both internally and with external providers?
The first implementation in the US was done on the 1st January 2012, by which time the major US banks were already familiar with SWIFTNet and XML. The US and Europe migration were quite similar, with a few exceptions such as the routing code in the US to perform ACH or cheques, which are still very strong in the US.
LVMH is a decentralised group, so our affiliates are responsible for managing their own processes. Timing was dictated by individual affiliate requirements, as long as the group had declared their banking partners ready for implementation.
Our XML migration process is worldwide and we’re now ready in 40 countries – the US, Canada, most of Europe and key markets in Asia.
At which stages throughout the process were bank guidance and/or technical support required?
Initially, we experienced a real of lack of expertise – and consistency – when it came to XML. In some countries, it had to be pushed; in others, we had to go to great effort to ensure consistency among banks.
As a result of this process, we have rationalised the number of partner banks we work with, which has also increased efficiency and lowered costs.
What challenges remain with respect to SEPA compliance, and how are you going about addressing them?
We are in a good position with SCTs, but SDD remains a challenge, although it isn’t too great a concern as it’s not a core business for us. We are working on building mandate management solutions and our efforts should be well underway by October.
Looking at the market’s adoption rate, February 2014 would seem to be an ambitious deadline for SDDs. Banks will be faced with a massive increase in migration projects as the end-date gets closer and that could be an additional concern. In any case, we will do our best to reach the deadline.
Looking to the future, how do the efficiency gains presented by SEPA fit into your future treasury management strategy?
I would enlarge the case to XML, although SEPA has played a major role in Europe to mobilise the banks. Lowering costs, increasing efficiency and heightening security are universal treasury objectives. The use of XML and SWIFT presents a key opportunity for all treasurers: XML means you only have to use one format; while SWIFT – when integrated into an ERP system – can improve straight through processing (STP) by helping to ensure that the information sent to banks is correct.
An extra bonus is the ability to streamline our bank relationships. Identifying key partners – reliable partners are vital given what’s going on in Europe – has enabled us to concentrate our flows and create uniformity, which is a huge help to our cash management processes.
Greater visibility, improved communication, increased efficiency (the result of a single payments format (XML) and subsequent dematerialisation), lower costs and access to a worldwide depositary (via SWIFT), are the cornerstones of optimal treasury management. The move to XML together with SWIFT is, for us, a milestone in this process.
XML harmonisation beyond the scope of SEPA
Although the ISO standards are in place today, they have solely focused on SEPA instruments – SCT and SDD – to date. Therefore for those payment and collection instruments a uniform standard, XML version 3, has been agreed upon.
For transactions outside of the scope of SEPA, which are also in the XML format, there is much less uniformity – and the possibility remains that different versions will be developed over the course of time. Some markets have also developed dialects of XML in order to cater to local needs. Again, it is more likely that domestically-focused banks will look to offer a local dialect of XML if it is easier to implement, but global transaction banks, such as Deutsche Bank, will not do that, because we see greater, and sustainable long-term value in offering a uniform standard across many markets.
This will be an ongoing exercise. There is no doubt further versions of XML will be developed in the future, however we hope the industry can look at XML beyond SEPA compliance as a means for format harmonisation for non-SEPA transactions and markets.
Corporates still using MT940s for reporting
Today, most companies are working – or have worked – hard on rolling out XML for payment and collection files, but there has been less activity on the reporting side. The reason for this lag is two-fold. Firstly, there is already a uniform standard on the reporting side across most markets and banks – the SWIFT MT940. Companies, therefore, have set up reconciliation in their ERP systems based on MT940 statements, which is working well due to the ease of the reporting process compared to payments or collections.
Secondly, because so much energy has been focused on developing XML for payments and collections, less energy has gone into the reporting process. Although we have had discussions with our clients about how XML reporting statements are far richer, with additional information that MT940 statements cannot provide, they look at the switchover as a second phase within the SEPA project. Today, they are getting ready for SEPA, making sure that their outbound files to banks are SEPA-compliant and that they can migrate on time. Once SEPA is up and running then they can look at additional benefits, such as how to replace their MT940 statements with XML statements. But that will take some time and right now treasurers have their minds firmly focused on SEPA migration.
Migrating to SEPA and XML
In order to help our clients become SEPA-compliant and migrate to XML, last year Deutsche Bank created a SEPA migration guide, which clearly identifies what clients need to do to move to SEPA instruments and outlines XML specifications, such as which fields need to be present and how this can be accomplished.
In addition, the bank has developed an online XML checker. For example, when a client creates a test file in XML, rather than having to send it to a person at the bank to look at the file, test it and send feedback to the client (which could prove to be a time-consuming process), our clients can upload a file onto the online XML checker site and receive immediate feedback as to whether the file is correct, or if not what needs to be changed. Companies can quickly change the file and then upload it again to make sure that it will be successfully processed.
Thirdly, Deutsche Bank published a vendor guide, which includes a list of vendors in the marketplace that can help clients, whether that is on the XML side, or converting local account numbers into International Bank Account Numbers (IBANs), or helping with SDD mandate management. This is a great help to our clients, especially those who need outside and third-party assistance in order to be ready for the end date of 1st February 2014.
If companies haven’t yet started to develop XML capabilities for their SEPA project, they should reach out to a third-party vendor at this stage, given that there are only a few months left to go. Their top priority today should be to ensure that they are ready – and there are a host of third-party providers who are capable of providing support. The good news is that the newest releases of the larger ERP systems have XML already embedded in them, so if a corporate is upgrading its ERP system, it will need relatively little development and testing to go live.
Conclusion
In many ways XML will be game-changer for corporates, because of the efficiency it brings, as the industry moves away from domestic and proprietary formats to one uniform standard. This is a significant development for the global payments market and will make life much easier for companies.
