APIs, beyond the buzzwords

Although this concept has only recently been invested with popularity, the concept of an API was first developed in the 1940s, when British computer scientists Maurice Wilkes and David Wheeler created the first documentation for linking two systems by means of coordinates stored in punch cards, accompanied by a set of instructions.

The concept evolved over time until the term “Application Programming Interface” first appeared in the 1960s and 1970s. You can read a concise history of this piece of technology in this article.

Even today, when talking about technology in the financial sector, the term API is used to identify a way of connecting two applications. In the common understanding, APIs enable real-time data exchange through a specific communication protocol.

However, it is not always clear among users (in this case treasurers and CFOs), what are the advantages of API technology over other file exchange technologies.

In this article we are going to analyze what the main uses of APIs are in corporate treasury, how API technology differs from the traditional secure file exchange protocol, and we are going to look in detail between different types of APIs.

Use of APIs in treasury

Since APIs are nothing more than a communication channel between two applications, such a channel is used, for example, in the following cases:

• Data exchange between a corporate (or vendor software) and bank (retrieve statements and send payments)
• Data exchange between software such as ERP (Enterprise Resource Planning) and TMS (Treasury Management Systems) (data exchange regarding financial planning, payment instructions, accounting entries from statement movements)
• Data exchange between TMS and trading platform (transaction execution request and its confirmation)
• Data exchange with other sources including software to import risk assessments or market data

Of the categories of APIs listed above, the one where the protocol has become most widespread is undoubtedly corporate-to-bank connectivity. The impetus behind the adoption of the API protocol was a piece of regulation called European Payments Service Directive 2 (PSD2). 

Because of this legislation, as of September 2019, European banks are obliged, through APIs, to provide payment and transaction data to third parties in order to improve the customer experience.

The widespread use of API technology helped in developing concepts such as Open Banking, that is the opportunity for financial data to be shared between banks and third-party service providers. Another concept that was developed as a result of PSD 2 is Embedded Banking, which is the ability to integrate financial products and services into non-banking platforms, such as e-commerce or social media.

API vs. SFTP

Despite the growing popularity of API protocols among professionals in the financial industry, it is not always clear to users what the differences are between an API interface and a file exchange via a traditional secure file exchange protocol.

The main difference is undoubtedly that an API interface occurs according to a series of interactions (requests and responses) between the two applications, and this allows for a real-time exchange of information. On the other hand, data transfer via SFTP protocol is file-based, and it occurs when such transfer is initialized by either party.

From the user’s point of view, I do not think this makes a substantial difference, especially in treasury where they mostly make use of information updated to the previous day.

The extensive use of the word API, sometimes to actually imply a normal SFTP transfer, is often brought forth by technology providers desperate to differentiate themselves from competitors, but leading to confusion among customers.

Generic API vs. API solution specific

As described in the previous section, there are no real differences for users of a service from an API to an SFTP connection, at least as far as needs related to basic treasury processes are concerned.

However, there is a distinction to be made between the potential of a generic API compared with an API designed and developed to connect two specific solutions.

A generic API, by definition, is developed to connect two applications according to a specific protocol, allowing a real-time exchange of data.

On the other hand, a solution-specific API can provide several advantages: if designed well, solution-specific APIs can use data transferred from one application to another, enriching it so that users can perform new operations through dedicated user interfaces.

In addition, another potential advantage of solution-specific APIs is that they can be maintained and adapted in the event of updates by the connected applications. In this case, even if one of the two applications involved were to update, the API evolves in a way that does not interrupt the flow of data to be transferred.

Finally, a final advantage of solution-specific APIs is that they are potentially more convenient to be integrated by the end user. Although generic APIs, such as traditional SFTP connections, almost always need a minimum of user intervention to connect the two solutions, solution-specific APIs can be designed in a way that facilitates the integration phase, so that the API can be configured in as plug-and-play a manner as possible.

An example of a solution-specific API is the FIS ERP Connector. FIS has developed a range of pre-built APIs that provide integration as a service between FIS Integrity and FIS Quantum treasury management systems with the main ERP software such as SAP, Oracle and Dynamics, so that data contained in the management system can not only be transferred to the TMS, but also enriched to allow further processing.

With FIS’s ERP Connector, for example, it is possible to import invoice history for a company’s customer base and its past payments, so as to calculate not only how punctual a customer has been in paying past invoices, but also to predict when future invoice payments will be made. This data will then be transferred to the TMS (FIS Integrity or FIS Quantum), to update financial planning.

Possible evolutions of bank-to-business connectivity

What future then for APIs? Personally, the development I hope for is the creation of an API standard to connect European banks with their customers, for both informational (retrieving statements) and device (sending payments) purposes.

Bank-to-business connectivity is still a very fragmented service, causing several headaches for treasurers: each bank has its own connectivity standard, and when a financial institution offers APIs, they require dedicated integration efforts for each counterpart to be connected.

Having a European API standard for bank-to-business connectivity would expand at the community level the positive experience of the CBI standard used in Italy, whereby all member banks can be easily connected to their customers in an efficient manner, at low cost and without any configuration work on the part of the company.

Other attempts to provide common connectivity protocols at the European level, such as EBICS, have unfortunately failed to cross the borders of a handful of European states.

Having a European standard for bank-to-company connectivity, possibly in real-time, would significantly reduce the, sometimes, large costs that companies have to bear to exchange information with their banks, especially if these companies adopt the SWIFT Score protocol because of the high number of bank counterparties outside Europe.