Building on my last article and the concept of mash-ups, I want to explore further the importance and challenges of APIs, which are a critical technology for connecting applications and pretty much essential for real-time treasury.

API landscape

Although APIs are much hyped at the moment, and heavily promoted by banks who have developed them, their adoption by treasurers – and even by TMS vendors – is hindered by a lack of standardisation and the difficulties of implementing bilateral API connectivity.

APIs can use different standards for:

• Functionality (both what and how).
• Content (the specific formatting of information).
• Protocol (the mechanics of communication).
• Security.

SWIFT, who are having good success with ISO 20022 XML as the common standard for file-based bank connectivity, are also working on API standardisation. SWIFT’s progress with API standardisation is slowed partly by the complexities involved and partly by banks’ desire to differentiate themselves in the API space.

Thus, treasurers seeking to evolve their bank connectivity into APIs are finding that the ambitions are thwarted by the heterogenous offerings and the cost and complexity of bilateral bank connectivity. This is especially problematic for treasurers who need real-time bank connectivity.

Fintechs to the rescue

This issue of heterogeneity and cost and complexity is an ideal environment for nimble fintechs to address. Established players have little incentive to address this area, either because they have vested interests (like banks wanting to differentiate or ERP vendors having their own proprietary solutions) or because the costs are too high to be attractive (like TMS vendors finding the heterogeneity overwhelming).

Fintechs tend to build from the ground up for diverse connectivity. They are normally too small and specialised to build broad applications, so they build specific solutions predicated on connectivity as a means to integrate into corporate ecosystems. So they have a natural advantage in addressing this challenge.

Fintechs also have less (or no) attachment to legacy, and are thus able to pivot faster to attractive niches (broadly areas where customers have problems that are not well addressed).

Pivot to APIs

A good example of this kind of pivot is FinLync. FinLync started with building apps within SAP to provide specific treasury and finance related functionality that was not inherent in the ERP. Led by customer demand, they started to develop APIs with their users’ banks to provide real-time functionality.

Demand from non SAP potential customers led FinLync to develop its bank connectivity API aggregator as a standalone product. This can be used by any API enabled solution at the corporate.

How it works

The concept of an API middleware is not new per se. Google Apigee, amongst others, offers this kind of functionality. The issue with such generic solutions is that they require the user to specify in detail the input and output across the four dimensions mentioned earlier. This is still a lot of work for treasurers whose focus is on bank connectivity, not to mention the hassle of keeping up with the evolution of each bank’s API functionality.

Further, many systems that are API enabled are not necessarily able to connect to bank APIs. For example, most ERPs use APIs extensively to connect their different modules. For example, SAP calls this iDocs – but that does not mean they support bank connectivity.

What differentiates FinLync is its focus on bank connectivity. FinLync relieves treasurers of the grunt work of specifying each bank’s API and ensuring a harmonised data flow to their own applications. They are also actively updating their multi-bank API aggregator with new functionality as banks deliver it. In fact, FinLync often advise banks both on the functionality required by corporates and on the actual implementation, acting as the de facto standardiser of bank API connectivity.

Conceptually, Finlync’s multi-bank API aggregator can be seen as the API version of what middleware and SWIFT provide for bank file-based connectivity. Corporate applications like ERPs and TMSs have only one API connection with the aggregator, which in turn converts the data across the four dimensions mentioned to bank specific APIs.

FinLync have already established API connectivity with over 30 global banks, and are continuously adding more, based on customer needs. Depending on bank responsiveness, they can add bank APIs within days.

How treasurers benefit

Treasurers who need real-time bank data have to use APIs. Normal MT940 bank statements are sent at end of day by banks, and are thus practically only available to treasurers at the start of the following business day. Even MT942 intraday statements are typically sent once or twice per day, at most hourly, and not all banks provide this service. APIs enable near real-time updates as and when transactions occur.

Bank API specifications are different for each bank. So treasurers using multiple banks face the challenges of implementing – and crucially maintaining – multiple different API connections to their different banks. Such implementations are expensive and time consuming, and, since API technology is evolving fast, maintenance is a big problem.

Using FinLync’s multi-bank API aggregator shields corporates from this complexity and cost – essentially outsourcing it to FinLync. This provides corporates with a less painful way to benefit from API connectivity with their banks.

Further, the aggregator provides a contractually simple solution – corporates already have legal relationships with their banks, and they need only the added relationship with FinLync.

Conclusion

The multi-bank API aggregator provides an elegant solution for treasurers seeking to evolve to API connectivity with their bank. It avoids the cost and complexity of developing API connectivity with each bank bilaterally, and helps them retain flexibility when they need to add new banks.