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 around 50%. The number of bank relationships and accounts corporates now have starkly underlines this, with recent research (Treasury Aggregators) showing that nearly half of corporates use 10 or more banks globally, while 18% have 25 to 100 bank accounts and 16% have more than 500 bank accounts.
As an example, many corporates already faced challenges in terms of total visibility across all their accounts and the fact that they are often looking at the overall picture through multiple portals and systems. The current crisis highlights the need to be able to see all the liquidity across the company and the risk associated with underfunding.
Strategically, a treasurer needs to optimise company cash and working capital by speeding up the supply chain as much as possible while minimising unnecessary funding costs. In addition, current circumstances are quite unique, and treasuries need to be able to proactively manage their positions across the group – and as near to real time as possible, because passive cash management has both potential downside risk and lost investment opportunity. Being able to see 80-90% of the group-wide position carries risk and exposure. Viewing that exposure via traditional end-of-day MT940 reporting is also too late, given the dynamics of the environment we find ourselves in – and the potential market volatilities.
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:
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, Payment Services Directive 2 or application programming interfaces (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 File Transfer Protocol adds zero value from a visibility and control perspective.
Many corporates see this as essentially the banks' problem. To resolve it, the banks should collaborate and share data in a consistent format. The evidence to date in other related areas isn't exactly encouraging, however. For instance, the value of know your customer (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?
Taking a realistic view, the task of building the right connectivity is highly unlikely to fall to 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 running, 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 and 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.) Nevertheless, in practical terms some work will need to be carried out by and with internal IT colleagues – even if only to confirm to procurement that their help is not required, or on the integration front – and their buy-in will be important.
The payment model for corporate-to-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 investment, 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.
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.
Firstly, the specialist will almost certainly be able to undertake the work at lower cost than the bank's 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 $270bn a year).
Secondly, a specialist will probably also be able to complete the project faster, thus ensuring that the bank's own ‘time to revenue’ from the client will be shorter.
Ultimately, there are some banks and locations where this kind of connectivity, though desirable, will be too expensive or difficult to achieve and some manual workarounds will still be necessary.
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 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.
Bill Wrest is director of sales and strategy at Gresham where he works to create innovative cash and treasury solutions. He was previously head of innovation for non-bank financial institutions at Barclays Corporate and has a long career working with multinationals and managing treasury system sales.
