This is a relatively long posting in bobsguide, the subject matter being connectivity between corporate treasury systems and their all-important bank accounts. The author is a senior at Gresham, a London-based fintech dealing in software for data control in multi-bank scenarios. How does open banking affect connectivity?
So prior to readers pre-judging any piece as a sales pitch, we’ll just say it is a fairly detailed and logical argument from someone who lives and breathes the space. The article title is the outline, so to speak: the connectivity conundrum: why build, who builds and who pays?
We don’t spend a lot of time directly in this technology space, but are quite familiar with the issues faced by financial professionals in terms of outsized expectations versus undersized resources. Two of the themes in our CEP Outlook for 2020 are both applicable here; one being ‘globalization’ and the other ‘resourcefulness’.
The ‘why’ part is interesting because, as the author points out, many think that the onset of open banking (PSD2 in the Euro area) translates into immediate ability for standard API access to whatever one needs from whichever bank. As we pointed out in a member research piece last month, more banks than not are still unable to meet the API requirements for PSD2.
‘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
As for the ‘who builds’ question, the more global a corporate happens to be, the more accounts it will be managing. Getting resources assigned to bank connectivity is a challenge. This underscores what should be a bank’s (especially a primary bank) incentive to make interactions easier for its corporates. But the author makes a good point.
‘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.’
We’ll let you read through the ‘who pays’ part for the punchline, but this is certainly a good piece to spend a few minutes contemplating, especially if CFP is facing the conundrum.
Overview by Steve Murphy, Director, Commercial and Enterprise Payments Advisory Service at Mercator Advisory Group
