Bank-to-corporate Connectivity: The Next Stage II
As I mentioned in my article on bank-to-corporate communication two years ago (Bank-to-corporate Connectivity: The Next Stage), electronic interfaces are often the biggest hurdle facing the use of straight-through processing (STP) in the payments and cash management world. But since then, some of important developments have changed the landscape dramatically:
But why is standardisation so important in this space? It’s all about the ability to change bank in a cost and time efficient manner.
Corporates are interested in having an interface that is as standardised as possible to make it easier to switch banks without having a major bank interface project on their hands. If all banks supported the same formats, used the same communications channels and supported the same security features, then changing banks would be no more difficult than changing your telephone at home. Your new telephone uses the same power plug, uses the same socket to the phone network as the old phone and we all know how to use the basic features to be able to call a friend.
However we should not forget that changing bank involves more than just bank communication. You also have to inform your customers and maybe also your vendors about the new bank accounts and that might be a lengthy process. It is like changing your telephone number every time you change your telephone provider.
A few countries have solutions for this, but most don’t.
Over the last years, several groups have tried to standardise formats used in bank communications, but with mixed success. The ones that came closest were the EDIFACT format and SWIFT’s proprietary MTxxx formats.
The latest entrant is the UNIFI format, better known as ISO 20022. The question is whether this will have a better fate than the Edifact format which, although widely predicted to have a great future, never became a single format supported by all banks in a uniform way. There is still a difference in the ways the same features are implemented between banks and countries.
So far, the take-up of the ISO 20022 format has been slow, although it has become the mandatory format for inter-bank communications for SEPA payments.
And even if it were used more it might still suffer from the problems that plagued Edifact and MTxxx formats. Each bank, for instance, would require slightly different layout and content. Many banks have also embedded special features in the formats and used individual design to keep their clients locked in, claiming a competitive edge.
At Nasarius, we have often discussed this with some of the major international banks. While most international banks agree with the principle that formats should be part of the cooperative space between banks, they generally balk at the idea of removing their bank-specific features in the name of standardisation, since they feel they will lose a competitive edge.
A valid question is therefore: will the banks ever give away their ‘specialities’?
The formats easily become polluted when banks have their own interpretation of the standard and especially when they add bank-specific features. It’s no longer standard, which means it becomes a major task to change banks, as you have to modify and tweak the formats and test the interface again.
On top of this, there are country-specific payment formats to tackle. Over time, many countries have developed special formats to make payments and payment processing more efficient. While it generally works well within a country, it usually requires lots of extra work in the interface to get it to work. All too often, the banks have their own local interpretation of how to handle this in the ‘standard’ formats.
This obviously makes it more difficult for a corporate to add a new country to the list of those supported, and makes it even harder and more costly to change bank.
To ensure that ISO 20022 has a better fate that EDIFACT and the MTxxx messages, it is important that the standard doesn’t become polluted. SWIFT plays an important role here in two ways. First, it is the Registration Authority, which means it is in charge of the consistency of content across the different business areas, and has to secure the integrity of the information in the repository.
SWIFT also publishes guidelines and makes rules for SWIFT SCORE, which helps maintain a regular implementation of the standard.
Further, the ISO 20022 format is not even complete. An important part of the bank-to-corporate process has been missing until very recently: the bank statement. EDIFACT has had that format for many years now.
The formats for the bank statements are still in the pilot phase, and the SWIFT SCORE guideline on bank account reporting is only being published by the end of June this year. Adoption of ISO 20022 has also been held back by this, as few corporates have an interest in utilising different formats within their bank connectivity solution.
Many banks are not yet ready for the new format. They are SEPA compliant, but not yet technically ready to receive the new formats for all transaction types for example country-specific reference payments from their corporate clients. Adoption of ISO 20022 will not gain speed until the majority of banks are ready, which may still take one or two years.
There are still many ways to connect to banks, as I described in 2007, and these remain more or less unchanged except in one place: SWIFTNet connectivity.
Here the most significant development has been SWIFT’s active promotion of SWIFTNet to corporates.
By introducing the SWIFT SCORE model in 2007, SWIFT has made it easier for corporates to sign up, since they no longer need to sign up with a member-administered closed user group (MACUG) for each bank, and can reduce some of the legal work. SWIFT has also significantly lowered the cost, making it even more attractive.
SWIFT SCORE is primarily, however, for the very large corporates. The setup is still technically difficult – even though SWIFT is trying to make it easier – and it’s still expensive if you don’t have enough volume to send through. But SWIFTNet remains attractive for bank communication because of its high availability and security.
SWIFT has also developed Alliance Lite for smaller corporates and financial institutions. However, sales have not been as good as hoped and SWIFT has had to use resellers to increase take-up of Alliance Lite.
Meanwhile, many suppliers of cash management systems, payment factories and enterprise resource planning (ERP) systems have developed SWIFT connectivity features that make it a lot easier to connect to SWIFT, which of course will further drive adoption forward.
Communication between banks and corporates is no longer limited to just payments and bank statements, and plans are in place to expand the electronic services that banks can provide to corporates. Again, here SWIFT is playing a leading role in defining the formats for the services.
For example, formats are being created to make it possible to open and close bank accounts and change signatory rights electronically instead of the paper-based process that we see today.
SWIFT has also developed a standard for exceptions and investigations which should help making it easier to follow up on exceptions in the payments processing, such as the failure to reconcile received funds with an open position.
What many banks and industry thought leaders hope for, however, is to use the bank-to-corporate communication for exchanging invoices electronically. This will take a long time before we see working global standards.
Corporates usually don’t have a business case for changing an existing and functioning interface to a new channel or format. Which means changes tend to come on the back of other events, such when an old cash management system is swapped out, the ERP system is upgraded, a payment factory is installed, or, most importantly, when the corporate changes one or several of its banks.
As this doesn’t happen so often, we should not expect a run on the new channels or formats, but rather a steady trickle towards ISO 20022 over several years.
So what is required to get to the point where we have a standardised interface between corporates and banks?
Most importantly, ISO 20022 needs to become a truly unified and standardised format; unfortunately we are not there yet.
Too many banks are not ready to receive the format. In addition, the service offering is not yet complete. Only when relevant banks and countries have embraced the new format, can we conclude whether the implementation of the standard is homogeneous or whether it has become victims to the same flaws as EDIFACT and the MTxxx formats.