Introduction
You may have recently heard about corporate bank API standardization initiatives. But what does that mean for treasurers? And is it really something to be excited about? In this blog post, we’ll discuss the truth about corporate bank API standardization – why it’s needed, why it’s unlikely to happen, and the alternatives treasury teams can turn to. Read on!
The difference between bank APIs vs. Host-to-Host
First, let’s be crystal clear on the difference between bank APIs and legacy bank connectivity methods, like host-to-host and SWIFT. The big difference to be aware of is that legacy bank connectivity methods are file-based, whereas bank APIs are not.
Every treasury team is familiar with file-based bank connectivity because it’s been around for the last 20+ years, ever since file transfer protocol (FTP) was invented in early 2000s. Here’s a typical file-based process: A file is sent from the corporate to the bank, the bank picks up the file from the server and processes it in their downstream systems. If it’s processed successfully, the bank generates a second file of data – an acknowledgement – to confirm receipt. The acknowledgement is sent to the bank’s fileserver and then sent to the corporate. The person at the corporation has to constantly check if it has arrived, and once received, pick it up and move it to another location to continue processing it.
Now onto APIs. Nearly everyone uses APIs in their daily life – from the weather app on your smartphone, to the GPS guiding the driver of your rideshare app – because APIs are a technology that connects two systems and sends messages between them. In the case of corporate treasury teams, we’re talking about bank APIs. A bank API connects two systems: a corporation and their bank(s), and sends messages between them.
The primary benefits of bank APIs vs. legacy bank connectivity methods:
- Bank data on-demand leads to more-timely and more-precise decisions, and improves efficiencies within the finance team
- Reduces risk of fraud
For a deeper dive into the differences between bank APIs and legacy bank connectivity methods, we invite you to review this infographic, or take our free 15 minute “Intro to Bank APIs” course.
Check out the 2022 Annual Power Rankings Report for Corporate Bank APIs
Limits on bank API adoption
As you can see in the Bank API Catalog, all major banks have created transaction bank API offerings, with more boutique and regional banks actively building out their own API roadmaps & offerings. Even The Hackett Group says “Bank APIs are the cornerstone of modern treasury” and CFO.com says bank APIs are the future of business-to-bank connections.
It’s safe to say bank APIs are here to stay.
So why is the whole world of corporate treasury not already using bank APIs?
Adoption is the keyword that is the issue for all corporates looking to move to bank APIs right now. The value proposition for bank API-powered, real time treasury experiences inside a corporates ERP is very much there, for example; real time cash visibility and payment status tracking from within the ERP, eliminating files and bank portals,
However, each bank has created their own APIs in their own way.
Every bank has its own unique design – their own authentication standards, messaging formats and data sets. And in many cases, even different types of bank APIs within each bank have been designed and built differently. For example, the payment initiation bank API and a payment status bank API, both from Acme Bank might be built totally differently.
Why would the banks do this? The reason banks have created their API offerings in this way, is so that they can differentiate themselves from all the other banks (their competitors). Every bank has invested heavily in their own API roadmaps, bringing out complete custom solutions for their customers, which are not comparable to other banks. Legacy file transfer protocols are limited by file formats and character limits, so leveraging APIs, banks have tried to “right the wrongs” of the legacy world and offer their customers the best digital experience possible.
Barriers to bank API standardization
Bank message format standardization is not a new topic. In fact, lack of standard messaging formats with legacy bank connectivity methods are an even bigger problem than with bank APIs. For many years, the industry has tried to solve the issue of lack of bank file standardization. For example, over the last 20 years, ISO20022 has attempted to create global standards for payment files and tested with multiple country-specific standards, with little success.
When it comes to standardizing bank APIs, there are several barriers at play:
- Too many parties involved. All countries have different payment types and methods. Is it realistic to expect every bank in every country to agree on the same standard? The electrical plug was invented over 100 years ago, yet nearly every country has its own plug design, leaving us to carry adapters with us whenever we travel.
- Competition. Earlier we discussed that the reason banks design their APIs uniquely is to differentiate themselves. With this competitive landscape in mind, banks are reluctant to share their API designs with others because they consider this proprietary knowledge. Banks are unmotivated to standardize because they don’t want to share trade secrets.
- Impairment to innovation. In an alternate world where all bank APIs are standardizes, it would squelch innovation. Banks are motivated to stay ahead of the competition, which in turn spurns innovation and new ideas. If all bank APIs were standardized, it would become a commodity.
Bank API messaging standards won’t, in my eyes, ever be globally standardized. And if I’m wrong, just like phone charger cables between Android vs. Apple, it will be decades until a universal standardization is achieved.
Build vs. Buy: Bank API Connections
So far, we’ve discussed why banks build their APIs differently, and the barriers to standardizing them. But where does this leave corporates who don’t want to wait? For those that see the benefits of real-time bank data and want to advance to real-time treasury now?
Check out the 2022 Annual Power Rankings Report for Corporate Bank APIs
Option 1: Building Bank API Connections Yourself
The uniqueness of each bank API design and format makes them difficult to connect to. Corporates must build the integration bank by bank, and API type by API type.
For a corporate treasury team with reasonable IT support, it will take approximately 6-8 weeks to build 1 integration for one type of bank API. That means 6-8 weeks to build just the balances API from Acme Bank. It would take an additional 6-8 weeks to build the transactions API from Acme Bank.
For a company with 3 banks that wanted total payment traceability, it would take:
3 payment initiation API builds (1 per bank) x 6-8 weeks per build = 18-24 weeks, plus
3 payment status API builds (1 per bank) x 6-8 weeks per build = another 18-24 weeks
= Total of 36-48 weeks
And that’s assuming the company has access to specialized engineers that have experience with building these types of integrations, and if not they should plan for several more weeks for trial & error.
The challenges of building your own bank API connection don’t stop once a connection been established. As treasury teams know from file-based connectivity, when a bank decides a new field is needed or something else is updated, the file specification needs to be updated and the systems creating payment files for example need to be reconfigured. Although bank APIs eliminate bank files, the banks will always be updating their APIs – either to launch enhancements, to fix something, or to comply with new regulations – which means ongoing IT and treasury resources are needed to maintain the bank API connections and keep them up to date.
It’s easy to see how direct bank API connection projects are deemed not worthwhile.
Option 2: Multi-Bank Corporate API Aggregator
Treasury teams who have already advanced to bank API connectivity are using a corporate bank API aggregator.
Multi-bank API aggregators have pre-integrated with more than 90+ corporate bank APIs – like a universal plug for electricity across all countries. This means the corporate can connect to many different banks through 1 single connection.
These aggregators remove many of the barriers to entry and the pains of adoption. Rather than a long, complicated self-build bank API project, companies instead have a one-time project to integrate a single standardized endpoint, and the bank API aggregator is responsible for all the ongoing maintenance. This will result in a reduced TCO of implementing bank APIs, and a reduction in the resources needed to maintain bank connectivity on an ongoing basis overall.
Option 3: Bank API-Powered Treasury Tools
A third option for advancing to real-time bank data is to purchase a bank API-powered treasury tools. An emerging category, these tools have bank APIs baked into their product and often come in the form of an ERP-embedded treasury application.
