Azzana’s Herreman: "Will corporates use API connectivity?"

Open banking and the API economy are the talk of the town – what it all means for banks, third party payment providers, and account information service providers – but one element seldom discussed is what all these developments will bring to the corporate treasurer? What API’s are available to corporates today? How do we expect this to evolve? Which use cases have the greatest potential?

One area where API connectivity for corporates is already quite prolific is in the execution of FX operations. Non-bank FX providers, ranging from the well-established INTL FCStone to the quickly-growing Ebury, have invested heavily in a suite of APIs for their corporate customers that empower them to request quotes in real-time, and to execute trades based on those quotes. A few of the more agile banks have started to develop API connectivity in this area, but the age-old (and dare we say antiquated?) practice of having your favourite broker on speed dial for quote requests still seems to be the ordre du jour.

In the FX space, as in all others, multichannel connectivity is key – and API is quickly becoming a prominent channel that can no longer be side-lined. Banks that wish to remain competitive in this area will quickly need to make sure that they have excellent API connectivity, keeping pace with other providers that can empower FX hedgers to get a real-time view of their options.

Whereas in FX operations there are three steps to an interaction (request quote, execute transaction, receive reporting), this is typically not the case in payments, where the first step is largely replaced with pre-negotiated rates. However, we have noticed that Fintechs are integrating this quote step into their payment processes. Mastercard Send, Ripple, and Transferwise are all reachable through an API, and all provide a real-time quote for your transaction prior to execution. Although the use-cases are currently focused on retail money-remittance payments, we have no reason to believe this practice of validating a quote (especially in the context of international payments, where there is still a great deal of price variability) won’t extend itself towards high-value corporate payments in the near future. API’s lend themselves excellently for requesting quotes from multiple banks/service providers at once – and as soon as a few of them are offering API connectivity, the rest will have to follow before they completely disappear from the treasurer’s radar.

On the fifth of December, SWIFT announced that 14 major banks have joined gpi’s API-based transaction pre- validation pilot. Although these APIs are currently only being developed in the interbank space, the gpi for Corporates pilot sets a precedent of the inter-bank segment of a payment being addressed first, with the bank-corporate segments being covered in a later phase. Even if SWIFT does not extend this service to corporates directly, it would make sense for innovative banks to serve as proxy for their customers to pre-validate their transactions in order to provide unique value propositions to their corporate customers. They could use SWIFT’s API’s to validate these transactions, alongside with their own currency guides, or even third-party providers rendering API services in this space (such as Accuity’s Banker’s Almanac). It would make perfect sense to integrate pre-transaction validation with a quote step (as is seen in fintechs such as Ripple), and for banks to provide this service using an API. A logical next step would be to allow corporate customers and service bureaus to execute the payments using API, especially seeing that banks doing business in Europe are required to have a similar API available to payment service providers in the context of the PSD2 regulation.

In order for API’s to become commonly used in corporate treasury, it needs to become easy for their service providers (treasury management systems, ERPs, service bureaus, …) to integrate multiple banks by means of a unified API schema. SWIFT’s CGI initiative, or alternatively ISO20022 could, and should, play an important role in ensuring that API’s are as standardised as possible. However, even if the API landscape develops chaotically and without widespread standardisation, there will be plenty of fintechs (such as Ibanity) and even banks (such as BBVA) clamouring to play the role of API aggregator.

The final area in which we expect APIs to develop is in the reporting space. This could be both in the context of end-of-day reporting, and in real-time reporting such as payment statuses. However, we believe that for these use cases to flourish, we must wait for a more widespread adoption of webhooks – a form of “subscription based” API which will push data whenever it is available – analogously to an RSS feed for applications. Therefore, we believe that API use cases in reporting are a little bit further on the horizon.

One can wonder, when all three steps of a transaction have been implemented in API’s – quote, execute, and report – will there still be a long-term need for file-based connectivity? Or will the transaction banking community one day move towards a fully API-based ecosystem?

Kjeld Herreman is the Head of Transaction Banking Advisory for Benelux in Azzana, a consulting firm focusing on Payments and Cash Management, active in France, Benelux and Singapore.