As treasury professionals, we have seen dozens of RFPs. The term API is often thrown around, but it is important to understand that not all APIs are created equal. In order to make full use of this innovative technology, it’s critical to have a thorough understanding of what you intend to do so you can make a clear request of your connectivity provider. Doing this ensures that you are getting the solution that you need and avoid falling victim to the catch-all phrase used by many bank connectivity providers: “We have APIs too.”
Where to Begin
A common misstep is not considering all phases of a technology transformation. A digital overhaul begins with planning and continues past ‘going live’. The success of the transformation depends on 1) understanding the entire operations cycle and how it will affect other departments, 2) enforcing clear evaluation criteria for technology, and 3) executing the onboarding process and measuring beyond the go-live date.
One of the first things to clarify is what type of APIs you need to integrate. These will depend on the types of processes that you are looking to update. For example: Internal APIs will connect internal systems, Partner APIs are used to embed a partner’s site to enable integrations such as single sign on, and bank APIs which create a direct connection between your systems and banking partners. FinLync provides bank APIs that establish fast and secure communication for balances, transactions, payment initiation, payment status and more.
To begin a successful project, start by drawing out a detailed list of treasury and finance data that you need to determine how you will create that connection from all available bank channels.
Designing the Future:
- Determine how many banks and bank accounts you need to integrate
- What does the reconciliation process look like?
- What does the payment process look like?
Expand the reach of the project by interviewing colleagues and other departments to understand how they will be impacted. In addition to treasury, other departments may get great benefits from the real-time connectivity through APIs. It will be an opportunity to not just re-create or automate the manual processes of today, but to improve them, and make them faster along the entire cycle.
One of the biggest mistakes we see in treasury software RFPs are questions that ask very vague and broad questions like “Do you have APIs?” The problem with this yes and no question is that there are many different types of APIs. A provider may answer ‘yes’ to this question because they have a single API connection to a bank, or internal APIS, but they do not provide the multi-bank connectivity an organization needs to enable true real-time treasury. In recent years, this question has progressed to “Do you have APIs to X bank?” But that question is still not good enough.
It lacks the specificity needed to know if the bank APIs will provide all the rich data you need. For example, they might connect to a single API for Acme Bank that only provides balance information, but not have a connection to Acme’s payments or transactions APIs.
The Right Question to Ask
So, what’s the right API question to ask on your RFP and avoid surprises on this front? “Do you have a bank API with <insert specific banks here>, so we can do <task(s)>in real-time?” A full review of your bank connectivity provider’s API Catalog will allow you to see the different types of bank APIs they currently connect to, which ones are on the roadmap, and those actively in use.
Creating connections to multiple banks via APIs has been a challenging task leaving many providers’ and treasurers feeling defeated and resigned to saying ‘the banks just aren’t there yet.’ It’s possible that the smaller banks may not have APIs. The solution can be to establish real-time connectivity to the banks through which at least 80% – 90% of the business is done, as an example
Some sample questions you may include in your tech evaluation:
- Review catalog of the bank APIs they connect to
- Do you have a bank API integration with <insert specific banks here>, so we can do <task(s)>in real-time?
- What is the process for requesting additional bank integrations or additional API integrations within a particular bank?
- How does your solution handle multiple bank credentials and secure storage of those credentials?
- When setting up multi-bank API integrations, is there any level of normalization/standardization across banks to ensure all bank data is presented in a similarly organized manner when displayed in the system consuming the APIs?
All banks have their own set of API specifications that requires each to be individually mapped in order to effectively create a communication link. All of this specific information will be published by banks in their API specification documentation.
Creating multiple links to each API belonging to each specific bank requires extensive work to setup and then maintain going forward. If a company chooses to take on this connectivity on their own, the IT team will require their own developers to be focused on this, become client support and troubleshooters, and have to keep up with future changes that the bank makes or if regulation changes.