In the past, creating connections to bank APIs has been notoriously challenging, leaving legacy technology providers and treasury teams feeling defeated. Bank APIs are a topic that has been talked about forever but until recently, hasn’t really been a viable option. Many in the industry will tell you ‘the banks just aren’t there yet.’
But in reality, most banks either already have APIs available, or are actively creating them. Some banks have launched bank APIs because they’ve correctly read the technology landscape and realize that legacy connectivity options like host-to-host will soon be made obsolete by bank API connectivity. Others have become motivated to build bank APIs in order to comply with Open Banking regulations. Either way, banks no longer view APIs as a nice-to-have, they are now a business necessity.
It is true, though, that connecting to a bank API hasn’t historically been easy.
The barriers to adopting new technology come in two flavors: technical and market barriers. Let’s discuss the 3 main technical barriers to bank API adoption.
Read The Essential Guide to Bank APIs
Barrier 1: Bank API specifications are not standardized
Bank APIs are designed and created by each individual financial institution which means they are built in different ways. Every one of the roughly 44,000 banks in the world will have different data formats, different programming languages, and each will contain different levels of detail.
Some treasury and IT teams might consider building their own bank API connections. Each bank offers multiple unique API streams – one for transactions, another for balances, payments get two different streams: payments status and payment initiation, and so on. The instructions on how to connect to just a single one of those bank APIs typically runs into the hundreds of pages, single spaced! Building your own bank API connection from scratch takes years of internal IT resources, an army of super-specialized software developers and a great deal of budget. And even then, your team will be building this for the first time, so extra development and testing time should be expected.
Efforts to standardize bank API protocols have gone nowhere fast because banks view their APIs as proprietary information – they don’t want to share it with others because they don’t want to reveal their trade secrets.
Barrier 2: Bank APIs must be adapted to meet company security standards
IT teams at today’s corporations use cutting-edge and ever-evolving security protocols to protect against fraud and other cybersecurity threats. Out of the box, bank APIs will not meet the unique security requirements of your company. Modifications such as signing the JSON web token with an x509 certificate or other technical processes must be performed.
For anyone who has tried to bring a new technology into their workplace, IT signoff is crucial to the success of the project. Without modifying the bank APIs, your in-house IT team will not approve them for use.
Read The Essential Guide to Bank APIs
Barrier 3: Internal Systems must integrate with Bank APIs
If you’ve managed to solve the hurdles of standardization and security standards, you must then integrate bank APIs into your existing internal systems. Which of your existing software systems are setup to receive this data securely? Which software systems can process and display the data? How will it integrate into the data you are piping in from other sources?
If your company has a data lake or data warehouse, the process is simplified because data lakes and warehouses are typically setup to consume APIs and regularly add new streams of data.
Without a data lake or data warehouse, consider what other software systems your team uses. If you have a treasury workstation, does it allow the hookup of new streams of data? If yes, how do the new streams of data interact with legacy data streams? In some cases, embedded apps that live inside your ERP system are the answer, or perhaps another system is setup to provide a “socket” to the bank API “plug.” Partner with your IT team to see what options you have to work with.
Don’t lose heart: all of these barriers are solved by working with a multi-bank API aggregator . These providers take care of standardizing and harmonizing the bank API streams, they adapt the bank APIs to meet your unique security standards, and will work with you to make recommendations for ERP-embedded apps for treasurythat can readily consume these data streams, or how your existing internal systems can best consume the information
Change is challenging, even for organizations that embrace it, with leadership that is fully bought in and when you’ve identified one of the 5 best times to start a treasury technology project . Budgets are often squeezed, people power is hard to come by whether that’s treasury team members who are able to run parallel processes to ensure the changes are accurate, or IT resources to review the new technology.
