Experiences with APIs in Corporate Treasury

In our recent survey of 133 corporate treasurers and professionals (report here), less than 10% said APIs are of no interest or not relevant. At the same time, less than 30% said they were actually using them. So what is really going on?

The full report (15 pages) is full of granular detail and a must read for any treasurer embarking on this journey- please ask to find out how to get a copy.

The overwhelming conclusion from this call is that many treasurers see promise, but there are a lot of real obstacles to overcome:

• Cost: all participants found the implementation was painful and expensive. The biggest concern, and source of expense, was security: as you are accessing banking systems and potentially allowing payment authorisations to go through the channel, security has to be rock solid.
• This, in turn, gets into organisational problems within the corporate: treasury needs to be able to call on internal IT resources and budgets.
• Logically, everyone is anxious to maximise the benefit from this new channel. The main use today is transaction and balance reporting, often replacing the traditional SWIFT MT940 and 942. This can generate sufficient savings to justify the investment, but there was a common feeling that the real benefit will come from using this new method of communication to carry much more information – one participant sees the potential for significantly broader benefits, but is not yet accessing them. All participants are anxious to have a single channel carrying as much information as possible in a secure way.
• Inevitably, this leads to the bane of every treasurer’s life: internal silos. The business case for adopting APIs with a rich flow of information is stronger if all potential users of the data are involved: treasury (obviously!), but also accounts payable, accounts receivable, accounting, financial planning, HR, etc. It can be difficult to organise a successful coalition – one participant found that other functions were negotiating directly with the banks to create their own, independent, APIs.
• Given this, and the presence, or otherwise, of existing IT systems, the general experience is that young companies tend to be more willing and advanced adopters than more traditional, longer established, users.
• The benefit of APIs is that they are usually tailored to the specific situation: the user gets the precise information they need, when they need it, in the format they require. The drawback: either the bank has to manage a library of APIs for all their customers, or the customer has to manage the library, for all their banks. We are beginning to see the emergence of aggregators to handle this issue, but none has yet established a dominant position.
• Given these complexities and issues, there is a natural reflex: view this as a simple bank connectivity issue, and rely on the TMS providers to handle it. As long as the data is coming into my TMS, why would I care about whether they are communicating with the banks via SWIFT or APIs, or any other means? This is a valid approach, and reflects many use cases today. But it does not yet maximise the benefits of APIs: on demand information, or event driven uses. These include, for example, triggering a credit release or initiating an FX transaction on receipt of a payment.
  • Indeed, uses today go beyond traditional transaction and balance reporting:
  • One participant is using APIs for bank account information for accounts payable
  • Several participants use them to populate FX rates in various internal systems.
• The biggest use reported on the call was to share data between internal systems within the company. The common experience has been that this helps IT become familiar with the technology, and therefore more comfortable using it to communicate with banks. It can be argued that traditional IT interfaces are a form of API.
• Are banks happy to provide APIs? Initially, this was a challenge, but most participants now find that the major global banks are on board – JPMorgan, Citi, HSBC, Deutsche and Bank of America were specifically mentioned. However, there can still be some reluctance amongst regional or local banks, and in some countries: this is a problem when rolling out a global solution.

Would you like to get our commentaries direct to your inbox? – sign up here

Bottom line: APIs are a potential game changer in terms of how corporates communicate with their banks, and how data is shared within companies. Treasurers understand this – but they face a daunting series of challenges. The IT security issues are significant and complex: it takes time and money to overcome them. The main use case today is for traditional transaction and bank balance reporting, with some payment functionality: these functions are performed adequately, if not optimally, by existing technology, such as SWIFT. Especially for an established company, there is little urgency to replace these technologies, and there is a natural tendency to let the TMS providers manage the issue.

The real benefit of APIs comes from potential changes to how companies work: moving to event driven actions, for example. It can be used to take over many of the functions of the TMS, as one participant showed. But there is a lot of complexity to be managed, as there is little to no standardisation today.

There is potential here for a massive change in how we all work. But it will take some time.