Introduction
Corporate treasury is advancing to application programming interfaces (APIs) as the primary means of obtaining bank data. But, some have been concerned that APIs from different banks may not be compatible with each other, leading to data inconsistencies and other problems. Fortunately, there’s another way: bank API aggregators. Read on to discover more.
What exactly has changed?
After roughly 20+ years of using SWIFT and host-to-host bank connectivity methods, the technology of bank connectivity has advanced. Bank APIs are rendering these legacy bank connectivity channels obsolete and treasury teams are actively adopting this new channel and reaping the benefits.
Treasury and bank communication have been managed disjointedly for far too long. The connections are built from scratch when new requirements or new banks are needed, and the added manual work and security concerns of file-based bank connectivity have left companies vulnerable to fraud.
Treasury teams waiting for banks to standardize APIs among themselves are likely to be waiting a long time, and risk being left behind if they opt to stay reliant on legacy bank connectivity methods.
If you’re building a connectivity architecture from scratch, deciding to build with bank APIs rather than legacy connectivity methods is an easy choice. But, if you’ve already lived through the pain of onboarding bank after bank with legacy connectivity methods – with each bank’s nuances and differing standards and formats within a single bank across countries, you’re likely to be more skeptical.
Get the Essential Guide to Bank APIs
Lack of bank API standardization
Many treasury practitioners understand the clear and significant benefits of advancing to bank API connectivity , but these teams also often bear the scars of having set up legacy bank connectivity – a truly painful and lengthy process. When creating these host-to-host connections, each bank and country brought new and unique challenges and what felt like the same work was being done over and over again. This formatting is a project remembered all too well by those who participated in the build out of these file-based communication channels.
The concerns about lack of bank API standardization are valid.
Each bank does indeed have its own API design – with different formats, protocols and languages. For example, a payment initiation API from JP Morgan may have similar elements as a payment initiation API from HSBC, but they will certainly not be identical.
But don’t lose heart – there is a solution. Read on.
Building connections directly
A highly motivated treasury team might consider building their own connections to each of these uniquely designed bank APIs. Given the significant benefits of instant treasury, their interest is understandable, and it is certainly possible to do it.
But, connecting directly to a bank API directly is an expensive process that requires an army of IT resources, and i reality, the lack of API standardization among banks is just one of 3 barriers that can prevent companies from building their own connections to bank APIs:
- The first barrier is the lack of bank API standardization, as we’ve discussed.
- The second barrier is that bank APIs must be adapted to meet company security standards. This can often require substantial, added IT effort, and it can be challenging to find developers with the necessary expertise.
- The third barrier is that internal systems must integrate with bank APIs. This can be a complex and time-consuming process, particularly if the company’s systems are outdated or poorly designed.
Then there’s the ongoing maintenance to consider. Every time a bank upgrades or makes changes to their APIs, more IT and treasury work is needed.
Despite these challenges, many companies are successfully connecting to bank APIs and advancing to real-time treasury.
But how?
The solution to bank API standardization
Bank API aggregators are the answer to the lack of bank API standardization. Corporate bank API aggregators bring calm to the chaos of non-standardized bank APIs because they act as a “google translator” for bank APIs.
Google translator allows us to paste in text from any language and instantly translate it to our native language. It also does the reverse – we can input our native language and it translates the text into any language in the world.
The same concept holds true for a multi-bank API aggregator.
A multi-bank API aggregator takes all the unique API designs across all your banks and PSPs and “translates” them into a single message format.
It also does the reverse: taking that single message format that your organization uses, and “translating” it into the unique format of the bank or PSP that it’s being sent to.
Take a payment API, for example. With a multi-bank API aggregator, a single message format containing all relevant payment information originates from your ERP and is translated automatically by the bank API aggregator into the newly concocted formats for all your various banks, countries, and even new payment channels.
Get the Essential Guide to Bank APIs
Gain bank APIs without the pain
If everything about bank connectivity has advanced to bank APIs, does this mean treasury needs to prepare for another year or more of late nights and fire drills like they did when they setup their legacy connectivity?
My answer is a resounding NO.
No need to worry about bank API standardization. A multi-bank API aggregator takes care of normalizing everything to fit the unique format of your internal systems. No more fire drills to add a new format or bank last minute because adding a new bank or PSP is now as easy as flipping a switch at your provider.
What about the other 2 barriers?
Adapting to internal 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. Another nail in the coffin for those wishing to connect to bank APIs directly or waiting for bank APIs to become standardized. Fortunately, part of a bank API aggregator’s job is to adapt the bank APIs to meet your unique security standards.
Integration with internal systems. If you’ve overcome the hurdles of bank API standardization and figured out how to adhere to internal security standards, there still remains the question of where you’re piping this bank data into. Is your TMS setup to consume this information? What about your ERP? A bank API aggregator will partner with you to share best practices from other users and make recommendations on how best to consume the data streams.
Finally, a bank API aggregator is responsible for all maintenance to keep up-to-date with bank API changes like format changes or upgrades.
