The Complexities of Delivering Workable Multibank Solutions
The cash management marketplace is currently active on new initiatives that require multiple banks to be involved if they are to be successful:
The connecting theme is the ability for a corporate to connect to any bank regarding any payment type (for both initiation and information), using the same data format, channel and security. That is not to say that any one initiative has this as its aim.
At the same time, initiatives driven by individual IT vendors to link a user of their system to multiple banks seem to be somewhat in decline. Their legacy is the belief that it is feasible to construct a plug-and-play international cash management (ICM) solution through which multiple corporates can operate their relationships with banks. The implicit structure of such a solution is that (a) there are many banks involved and (b) the banks are not working together to deliver a solution for a specific mutual client, or set of clients.
This legacy exists despite the discovery of the practical barriers to implementation of this kind of solution. Under such a structure, which the old and new initiatives have in common, the business interest of the banks around the table is either:
The outcome of the old initiatives has been either (a) a mono-bank solution where the IT package functions little different from the mono-bank’s eb service, or (b) a multi-bank solution which consists of a series of point-to-point one-off linkages, inconsistent even where the same banks are involved for two different users of the same IT package.
This is the outcome when user A wants to use SWIFT format but user B wants to use Edifact, but the bank receiving the data is the same. The bank will have a preferred channel down which to receive Edifact (e.g. a virtual private network) and a security standard appropriate to that channel. The bank receives SWIFT data over the SWIFT message network. The IT vendor could conceivably have to maintain multiple channels into the same bank, and this defeats economies of scale on the vendor side, as well as lengthening the implementation timeframe.
Operationally this also has its knock-on effect on the client. The client does not experience harmonisation in its exchanges with different banks: turn-around time is affected by the channel, and value-dating and all elements of pricing are negotiated bilaterally:
So the Holy Grail is not discovered: the corporate has to devote a lot of time and IT resource, and does not achieve harmonisation.
The IT vendor’s application is broadly acting as an aggregator. This role can also be filled by an ICM coordinating bank, where the electronic channel from corporate to bank would be a service provided by the bank. The ICM coordinating bank then collects messages from and sends them to a group of banks, invariably using SWIFT FIN messages and the SWIFT network. A better outcome for the corporate – compared to when the aggregator is an IT vendor – only occurs if the group of banks with which the ICM coordinating bank is working is structured in a fundamentally different way.
If the client has mandated the ICM coordinating bank to put together a solution involving a list of banks designated by the client, the existing competitive tensions within that group of banks are the same. Harmonisation is not achieved even where the interbank messaging is all going over SWIFT and using SWIFT FIN messages such as MT103 and MT101.
In the client’s eyes, the banks should be working together for the client’s benefit. The banks, in fairness, do not wish to disabuse the client of this belief. The economic interest of the banks on the designated list is to keep what they hold. It is the client, not the ICM coordinating bank, that has genuine leverage over those banks to cooperate, but only if the value and amount of the residual business is substantial. Leverage reduces if balances are moved away, and this can lead to a repricing upwards on the transaction business, or withdrawal of credit lines.
The ICM coordinating bank is then charged with getting the arrangement in place, almost always meaning that local balances are moved to the centre. To do this, the ICM coordinating bank needs to have either a pre-existing partner bank relationship, or a bilateral arrangement. If they have nothing at all, they have to set up a bilateral arrangement as quickly as possible.
The local bank assumes that the ICM coordinating bank will earn that value instead, increasing the tension between them, whereas in reality local surpluses and overdrafts will largely cancel each other out at the ICM coordinating bank level.
However, this basic construct will have difficulty in meeting the requirements of the client for efficiency, in terms of: execution speed and by implication STP rates; value-dating and pricing; consistency of data and interpretation of data. The ICM marketplace tends to overestimate the contents of a bilateral arrangement when measured against the above points. A bilateral typically comes down to an exchange of the MT101 Request for Transfer message, enabling the customer to debit the account at the other bank by sending a message through the electronic banking system of the ICM bank.
The bilateral agreement should cater for a payment out of the local bank back to the ICM bank, but it may not cater for the MT101 resulting in all of the following local RTGS payment; local ACH payment; and payment cross-border to third-party banks.
Nor may it govern all of the following points regarding the payment types it caters for: processing timings; value-dating; pricing. The missing points will have to be negotiated by the client – which may leave the ICM bank playing the role simply of a message forwarder, i.e. an IT vendor.
Even if the bilateral does cover those points, it may do so in a way that was tailored to the needs of the first client it was signed to support, and may not then suit the second or nth client.
This construct can have three results:
The basic construct when an ICM bank signs bilaterals or when an IT vendor has a contract with a specific client contrasts sharply with that of a banking club:
The banks are actively focused on one another and by extension on one another’s customers, as opposed to being in defensive mode on each customer where they get a request from an ICM bank or an IT vendor. Negotiations on a particular client can be focused on pricing and detailed operational issues, not the basics, which are all included in the deliverable to start with. Not only does this foster efficiency, it makes for ICM solutions that are comprehensive and watertight. Comprehensive because the banks involved are full-service in their own countries, as opposed to overlay banking which necessitates the inclusion of further local banks. And watertight because no balances need be left at banks outside the system, or within the local banks.
Where the solution is either overlay or bilaterals, there will be residual balances that are not brought into the ICM system on the day they arise – because transfers into or out of the ICM system are based on information reports that are taken either at the end of the previous day or sometime during the current day, not at the end of the current day. If just EUR500,000 of cash stays outside the system and EUR500,000 of overdrafts, the cost at a 3 per cent spread is EUR15,000 a year.
While in the past a client might portray that as an opportunity cost associated with having a given list of relationship banks, it might not be quite so easy to sustain that line in future. The implication is that a certain amount of cash is invisible to and out of the control of the ICM process that is controlled from head office.
We know that efficiency is inhibited by current market structure. The point is: what has changed in the intervening period between when old initiatives became blocked and now, that creates optimism that success will ensue this time around? If the new initiatives move forward without being based on a real interbank collaboration, they will not overcome the barriers faced by the old ones.
If the answer is that there are both new data standards available (e.g. TWIST, SWIFT C2B XML) and new channels (e.g. MA-CUG access), the answer is unsatisfactory, since each initiative only addresses one of those dimensions, and even then only on the front-end of the payment process.
When efficiency is increased only in one dimension, e.g. communication channel and related security, one may in fact be introducing the n+1st bespoke solution. When it is possible to send a multiplicity of data formats down a channel such as it is with FileAct, accessed via a MA-CUG, proliferation begins. The first MA-CUG client uses Edifact; the second uses local format. The third wants to agree a usage of SWIFT C2B XML but only filling certain fields. The fourth wants to add some other fields too. For the bank’s systems, each arrangement becomes bespoke, adding to the bespoke arrangements with IT vendors. Multiply all of that across the industry and version-control is lost.
Yet when we discuss a credit transfer payment, the message that the bank’s processing systems want to receive should be the bank’s standard MT103, or standard MT103+, or local ACH. Note that it is “the bank’s standard MT103” – MT103 differs from one bank to another.
And how can it be that multiple so-called standards bodies are working on new data standards for initiating payments that, within the banks, must eventually be handled in the MT103/103+ format, when SWIFT has declared that the MT103/103+ will not be further developed? This is the case even though several ACH systems in Europe will retire their local format and adopt MT103+ as a replacement.
The first lesson is that it is vital to ensure from the outset that initiatives are pursued within a construct where there are genuine shared business objectives, and not tensions or absence of mutual interest.
Secondly, that there are substantial blockers that will not go away and that the initiatives by their nature cannot shortcut:
Banking clubs have achieved convergence within the SWIFT FIN environment – no mean achievement given the permissible differences in populating and processing the standard SWIFT FIN messages. A banking club is a closed user group, but with links to clearing systems – without requiring the clearing systems to change for its purposes.
The challenge for the banking clubs is to repeat the act in an XML environment in the face of three paradigms that have established themselves:
These changes include:
The back-end agenda is therefore very full for the next five years. Given the economics of the business where there has been substantial give-up of income as a result of the EU regulation, where will be the business case for non-mandatory front-end initiatives that do not completely solve a problem from end-to-end (or solve it at the front-end but make it more difficult at the back-end)?
And if they do not solve a problem and are only adopted by a few banks and those banks already offer ways of initiating payments and receiving information, why is a new one needed at all?