The Complexities of Delivering Workable Multibank Solutions

Introduction: The Rise of New Multi-Bank Initiatives on The Back of Old Ones

The cash management marketplace is currently active on new initiatives that require multiple banks to be involved if they are to be successful:

• Banks to adopt new data formats (e.g. TWIST, SWIFT C2B XML)
• Banks to supply data (e.g. RTNS, SWIFTNet Cash Reporting)
• Banks to sponsor clients into an arrangement (e.g. MA-CUG)

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:

• To service their own clients; or
• To compete with the other the banks to win the business of clients who are on the target client lists of them all

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:

• A high-value payment (HVP) will probably be done quicker if the bank receives it in SWIFT format than Edifact – because the route from the SWIFT interface to HVP processing is shorter, and there is no reformatting; and
• Client A will get a better deal on value-dating/pricing with bank A than client B, because client A has more business in that country.

So the Holy Grail is not discovered: the corporate has to devote a lot of time and IT resource, and does not achieve harmonisation.

IT Vendor or ICM Coordinating Bank: What’s the Difference?

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.

Failure to Deliver to Customer Expectations

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.

How Bilaterals Arise and What is the Outcome

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 arrangements between the ICM bank and the client’s local banks all differ, meaning the client does not have a consistent process at its end, which frustrates efficiency
• The ICM bank – acting just as a message switch and not earning substantial net interest income – is not motivated to review and refresh the bilaterals at regular intervals for (a) on-going performance (b) updates to SWIFT’s message user guidelines or (c) marketplace changes such as the introduction of IBAN and BIC
• The efficiency permitted by the bilateral erodes over time, perhaps not in absolute terms, but because new possibilities emerge and the bilateral is not updated to take advantage of them

How a Banking Club Addresses the Issues with Bilaterals and IT Vendors

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:

• Club membership rules are that the banks work together to deliver services, eliminating tensions and suspicions
• All banks sign the same multilateral agreements, allowing consistency
• Comprehensive SLA covering account-opening, payment processing, pricing, value-dating and information, so nothing falls through the cracks
• Data standards between the banks are consistent
• Quarterly meetings of the banks to monitor service standards, address issues arising and plan actions – banks devote 30 days a year face-to-face to their relationships with one another
• Dedicated central staff to record actions, allocate them and ensure delivery
• Regular review of processes and messages for changes within SWIFT or in the marketplace

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.

Implications of monies outside the ICM system

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.

Why Are These Points Of Significance When Considering New Initiatives?

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.

What Are The Lessons From The Banking Clubs To Help Avoid The Pitfalls Of Old Initiatives And Bilaterals?

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:

• it becomes increasingly difficult for banks to get funding for investments that are not mandatory
• this will inhibit adoption on an industry level such that it is unthinkable that one could rely on all major commercial banks in every country being connected; the only thing they are all connected to is SWIFT
• a solution that wants to access the world outside a mono-bank or a closed user group of several banks requires changes in clearing systems, because one cannot dictate that all one’s customers and suppliers bank with a single bank or one bank that is in the closed user group
• an initiative that gets underway and creates some change in part of the process or in one dimension of it, does not create efficiency, it reduces it

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:

• XML in and of itself being seen as a path to accessibility for all and overcoming the issues (a) in multi-bank structure and (b) at the back end of the payment process
• That it is possible to have multiple initiatives in the corporate-to-bank-to-clearing-to-bank chain, and that these can converge with one another when the natural direction is to diverge
• That it is possible to make progress in the corporate-to-bank portion of the chain when the bank-to-clearing-to-bank portion is dealing with current and future mandatory change affecting all client segments

These changes include:

• Education of clients to adopt IBAN+BIC for all euro payments
• Adoption and optimization of EBA STEP2 for EU regulation payments
• Migration of local ACH onto STEP2 in certain countries together with the replacement of the local format with MT103+ where that occurs
• Imputation of Operational Risk Capital under Basel II
• Pan-European Direct Debit where it will be mandatory for all EU banks to act as receiver
• TARGET2
• New Legal Framework for Payments

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?

Comments are closed.