The Connectivity Conundrum: Why Build, Who Builds, Who Pays?

23 March 2020
Bill Wrest

In my previous article, I examined how effective liquidity management in treasury depends upon having a consolidated view and control of corporate cash. In this one, I consider why building dedicated connectivity is necessary to achieve this, who should build it and who will pay for it.

The effect of globilisation

One of the many effects of globalisation has been the proliferation of connections between corporates and banks. As corporates have responded to global opportunities in both sales and sourcing, their banking relationship needs have grown in tandem. Trade figures give an inkling of the pace at which this has happened: in the 25 years from 1993 to 2018, trade as a percentage of global GDP rose by ~50%1. The number of bank relationships and accounts corporates now have starkly underlines this, with recent research2 showing that nearly half of corporates use 10 or more banks globally, while 18% have 25-100 bank accounts and 16% have more than 500 bank accounts.

Corporate treasurers understandably covet the ability to consolidate all those relationships and accounts into a single platform that will give them maximum visibility and control. However, that raises three important questions:

• Why is dedicated connectivity needed to accomplish this?
• Who should be doing the necessary technology
integration work?
• Who will be paying them to do it?

Why build?

At first glance this question seems superfluous: to deliver the visibility and control needed by treasuries, consolidated connectivity is obviously needed. But some argue that simply by doing nothing this will all arrive free of charge by magic, courtesy of open banking, PSD2 or APIs. Sadly not.

The first two are (at least initially) primarily applicable to retail banking and so don’t provide an immediate solution. APIs simply provide an interface, they do not in themselves integrate or standardise the data passing through them. For instance, receiving proprietary bank format payment status files via an API rather than via FTP adds zero value from a visibility and control perspective.

Many corporates see this as essentially the banks’ problem. Therefore, the banks should collaborate and share data in a consistent format and that will resolve the problem. The evidence to date in other related areas isn’t exactly encouraging: the value of KYC repositories is hampered by banks’ differing KYC processes and requirements and the notional standardisation of SWIFT payments is undermined by individual bank implementations thereof. Pragmatically, the only solution is for someone to build the necessary connectivity and data integration between the corporate and its various banks. The question is, who?

Who builds?

Taking a realistic view, it’s highly unlikely to be the corporate treasury. Most corporate treasuries, even those of some of the largest global multinationals are, to put it politely, lightly staffed. While the new generation of corporate treasury personnel are more tech-inclined than their predecessors, they are unlikely to have the highly specialised skill set required. Furthermore, the magnitude of the task would divert them from critical day to day treasury tasks, such as financial risk management, cash forecasting and investment selection.

Getting the corporate’s internal technology resources to undertake the project is also an unlikely prospect. The tendency in many corporations even today is for treasury to be perceived as a cost rather than profit centre, which usually means that it is at the back of the queue when internal tech resources are being distributed.

The case for the banks to undertake the task isn’t much more compelling, although the issue here isn’t so much lack of resources as the appropriateness of using them. Some 80% of banks’ annual technology spending goes on keeping their existing systems running3, which doesn’t leave much for the future innovation that will generate adequate return on capital. It therefore makes little sense to divert bank technology resources away from that sort of innovation to deal with a task that would be better handled by a connectivity specialist. While banks obviously have experience in the sort of connectivity project that could deliver corporate treasuries the consolidated multibank platform they desire, it’s not what they do all day every day. They will have less total experience of the various corporate systems to which they will have to connect than a dedicated specialist that has done multiple corporate to bank connectivity projects.

Just one example of where this can make a difference is where a corporate client has grown by acquisition and has thereby accumulated multiple different enterprise resource planning (ERP) systems. The bank may have experience of the various vendors involved, but is less likely to have experience of all the various versions of the software being used. Corporates may only use one ERP vendor’s technology, but it’s not uncommon for them to be using different versions of this technology in different regions or business units. When, for example, implementing host to host connections, prior experience of these variants may be a critical factor.

At first glance, ERP or treasury management system (TMS) vendors might be suitable candidates for running the implementation, but the issue here is effectively the inverse of that which applies to the banks. The vendor will obviously know its own systems intimately, but how many different bank systems will it have experience of, especially if some vary within a single bank by country or region (as they do)? Both ERP and TMS vendors also have far broader objectives/expertise when running an implementation of their technology. They typically won’t be able to match the expertise of a specialist that spends all day every day dealing with corporate to bank connectivity and data integration.

Ultimately it is that sort of specialist who is best placed to conduct this sort of project for reasons of robustness, speed and cost. Not only should it be able to deliver on these three points in relation to connectivity and consolidation. A connectivity specialist that also has treasury expertise will also have the technology and understanding to maximise the treasury’s benefit from the resulting consolidated data, control and functionality. (A key point here is that these advantages only apply when using a suitable connectivity specialist, not a generic treasury consultant.)

Who pays?

The payment model for corporate/bank connectivity is like the proverbial length of string: it all depends. Nevertheless, the lack of treasury technology resources to conduct any connectivity implementation also applies to a lack of funds to pay for it. One of the top five concerns for treasurers in a recent survey was lack of budget for investment4, but this is hardly a new theme. As mentioned earlier, it’s still not uncommon for treasury to be seen within corporations as a cost centre and by implication less deserving of budget. Nevertheless, some corporates may see the commercial benefits of such a project as justifying the comparatively modest cost of engaging a suitable connectivity specialist to undertake it.

Where a corporate has multiple banks, the business justification for one bank to undertake the entire project itself for the potential benefit of all the others is, to put it mildly, tenuous. However, if that bank stands to gain further revenue from the client and it engages a connectivity specialist to undertake the work, the argument becomes more robust.
UK finance.

Firstly, the specialist will almost certainly be able to undertake the work at a lower costs than the banks own internal technology team, because of their lower cost base. For instance, it doesn't carry the same regulatory compliance overheads that banks do (currently USD 279bn a year)5. Secondly, a specialist will probably also be bale to complete the project faster, so the bank's time to revenue from the client will be shorter.

Conclusion

Corporate treasuries clearly need homogenous, multibank connectivity. This isn’t something that will be achievable in the foreseeable future without a dedicated implementation for each corporate. While it is theoretically possible for this to be done by a bank, corporate, ERP/TMS vendor or treasury consultant, a variety of practical considerations (including cost and speed) make a connectivity and integration specialist the standout choice. Who actually funds the resulting project will ultimately be a matter for commercial negotiation but it is worth noting that some global banks increasingly see the cost benefit as justified.

References:

1 https://data.worldbank.org/indicator/NE.TRD.GNFS.ZS?end=2018&start=1960&view=chart
2 https://strategictreasurer.com/analyst-reports-2019/ "Treasury Aggregators"
3 https://www.finextra.com/newsarticle/34855/swift-operations-forum-europe-2019-amsterdam---day-1-report
4 https://www.gbm.hsbc.com/insights/global-liquidity-and-cash-management/corporate-treasury-research-report
5 https://internationalbanker.com/technology/the-cost-of-compliance/

About the author— Bill Wrest


Bill was Head
BW March 2020of Innovation for Non-Bank Financial Institutions at Barclays Corporate. Prior to Barclays, he was with Bank of America Global Payments Solutions in London. As a Senior Vice President and Relationship Manager. He also has extensive experience working with multinational corporations and managing treasury system sales. Bill joined Gresham in 2016 where as Director of Sales and Strategy he works to create innovative cash and treasury solutions.


Gresham Tech’s Clareti Multi-Bank platform handles automated channel banking integration for corporate and wealth management clients and supports various payments-related business processes such as cash and treasury and trade finance.