APIs as a Game Changer for the Office of the CFO: Expectations vs Reality

However, the present-day value of many API projects do not always live up to expectations.

Considering the use-case of real-time payments, an API alone cannot guarantee the processing of payments which are initiated at a company’s ERP-system in real-time. It is only the combination of an API and a real-time payment scheme that allows for faster processing times and real-time payments.

And here, we have one major obstacle.

While several global banks have developed their own APIs which can connect to customer systems for real-time payment schemes, the customer back-end systems in treasury and finance departments are often not designed for real-time payments yet. Banks are enabling API-based data processing while the initiating systems are still stuck in a file-based world, working with payment batches. There is a notable friction in the process and the result of this setup won’t be the expected real-time payments.

Although this may not be an issue for payment scenarios like a supplier payment run initiated within the Accounts Payable department — where real-time payments would not add value — it can be a problem for urgent treasury settlements or critical material orders for your just-in-time supply chain.

To better understand these scenarios and the impact of APIs on the topics of payment execution and processing, it is important to take a step back and examine what APIs are and what their significance is in the field.

APIs are programming codes which allow for a dynamic exchange of data between two or more systems, in which information is transmitted as data objects over HTTP. The communication between the systems follows a pre-defined syntax and allows for near-real-time updates. In the world of banking and payments, APIs can enable use-cases such as account validation, sanctions screening, balance queries, and the beforementioned real-time payments. Data transmitted via APIs is access-controlled, encrypted in transit, and processing of data is faster compared to a file transfer. The advantages of APIs — such as such smooth, accurate, and real-time data exchange and processing — are clear. However, integration efforts are required to connect to an API, and it may not be suitable for a large set of data.

If an API has to deal with large data sets, this may lead to performance issues. Also, it’s worth mentioning that there is often a lack of standardization in APIs. Many bank APIs adhere to the European standard PSD2. Others like UK Open Banking, for example, have much in common with PSD2. But there is no mandatory standard or regulation on a global scale. Different countries and market players have different standards for their API projects. And if there are even minimal differences in the data fields of APIs which are supposed to communicate, this can lead to errors, delays, and incompatibility.

In addition, so-called premium APIs do not follow the same authentication method in the same way that PSD2 and Open Banking APIs do. This also increases complexity.

With this in mind, the friction between bank APIs and file-based payment batches initiated by a company’s systems becomes clearer.

A company’s backend systems, such as HR- or ERP-systems, will typically transmit large volumes of payments as payment batches, meaning in one large single file or data flow. But because APIs are not made for large data sets, the processing of the batch via API may actually not deliver faster processing times compared to a “normal” file transfer. Thus, if a company’s banks are ready for API-based real-time payment scenarios but the back-office ERPs are not, the processing of batched payments either over API or SFTP may have the same processing speed and underlying processes involved. Ultimately, this means most payments will not become faster, and even other use cases expected through APIs, such as a real-time vendor data or compliance screening, may be more complex than anticipated.

How to bridge the communication gap between the different worlds of banks APIs and back-office systems.

The solution to streamline communication between the two worlds is to work with a payment aggregator that does not deal with batches but streams them. A true end-to-end API connectivity ecosystem allows companies to fully benefit from the capabilities that APIs bring. One example would be to initiate single line payments, like treasury deals, from source to target system via API connection end-to-end. Another would be to set up payment collection cycles with the banks directly via API. In this case, the source system would only receive updates via webhooks, which are event-based custom callbacks, about important updates, direct debits, and recurring payments. And a third and final option would be for customers to change their processes and underlying systems to initiate single payments based on a demand or scheduled basis.

For end users, embedding APIs directly into a source system (Accounting Software, HR tools) can provide an interactive interface that asks for and truly receives information and updates in near real-time. This effectively automates most of the manual processes and puts customers in the driving seat to make use of Open Finance with a few clicks of a button via a normalized single API which aggregates integration into multiple banks and regions. Thus, the complexity and friction for companies is significantly removed.

A successful use case between numerous banks, back-office systems, and a payment aggregator is Siemens Gamesa’s early adoption of SAP APM, which resulted in automated processes between their banks and their back-end systems and a clear status overview of all transactions across their ERP-systems in real-time.

APIs are only part of the puzzle for a substantial change across the Office of the CFO.

In conclusion, APIs have the potential to be a game-changer in the field of treasury and finance. The benefits that come for the organizations that integrate them, including real-time insights through balance or statement retrieval, real-time payments, and more direct and precise analysis, are clear. But while banking APIs have been around for a number of years now, reality has yet to fully meet expectations.

It is important to keep in mind that APIs are only one of several building blocks that make up the tech stack in the Office of the CFO. For bank integration, this likely means that a multi-protocol strategy is the most appropriate way forward. Depending on the use case, the bank, the country, or the payment modality, it can be advantageous to have the option to choose between different channels, such as SWIFT, EBICS, H2H, or API (especially if such connectivity options are available “out-of-the-box”).

For corporates to truly benefit from the potential of APIs, it is of vital importance to not only choose banking partners that have APIs in place, but to build up the right technology setup between the back-office systems and their APIs. This means curating the right setup of technical components and developing a proper solution stack, including an application layer and an orchestration layer with a data lake and APIs for bank communication, back-office integration, and collaboration with partners. Only if the stakeholders in the Office of the CFO evaluate both their processes as well as their systems in use, and through this analysis manage to identify the right combination of solutions, can the expected (real-time) results of APIs be achieved.

For more information about how TIS supports API connectivity alongside other methods for connectivity, reporting, and payments, download our recent factsheet. You can also contact our team to learn more about the various solutions and capabilities we offer.