Why are APIs and API First important?
One of the key decisions FinanceKey has taken is to consciously put APIs first — a decision I am proud of as a CTO. Many people have asked why we considered this decision to be so important. In the words of one person: “When faced with so many other ongoing demands, why should we be investing time into APIs now?” Good question! In response, I thought I would write a post explaining why we think APIs are so important, and in particular, what benefits they will bring to the banking and treasury domains.
Many systems (including FinanceKey) claim to be real-time. A common misconception is that payments flowing continuously 24/7 would have huge ramifications on existing processes and this is quite a daunting prospect to many process owners. In reality, ”real-time” means that the API Data/Service is available on demand 24/7 at the customers’ convenience. For example, with legacy approaches, companies often have to wait for a bank statement to be delivered before the reconciliation process can begin. With APIs companies have the freedom to ‘request’ the latest statement as soon as they are ready to commence the reconciliation process. The same goes for other processes: pricing FX positions can use the latest market rates, payment beneficiaries can be validated as part of the payment initiation process… and the list goes on. By moving to an on-demand solution, businesses can adopt lean principles in those processes and reap the benefits they offer.
The upshot is, in a domain that is dominated by cut-offs and deadlines, treasury and finance teams can start to execute processes when it suits them and avoid bottlenecks and spikes in workload.
Service-oriented, increased automation
Traditionally, banking services have been provided via banking portals. The bank’s portal is the hub from which companies can initiate payments, view transactions and balances and conduct other banking activities. By adopting and providing this functionality as an API service, corporate customers and FinTechs can use these APIs in new and creative ways — possibly even in ways that banks had not yet considered. For example, corporate customers could combine an API from an HR system with an access rights API in the bank portal which would allow line managers to receive notifications to revoke bank portal access rights for employees who leave the organisation. By providing APIs, banks are adding value, increasing the opportunities for customers to automate and opening the doors to innovation.
Richer data content
The current file formats used to initiate payments and receive bank statement information were created in an era when there were restrictions on data size. As a result, the amount of information transmitted in current file formats is limited and often deliberately reduced, leading to missing data points. With APIs, that is not the case. APIs often contain more data which is labelled and structured. For example, APIs would make it easier to identify remitters on bank statement transactions and the purpose of those remittances.
APIs have been designed with evolution in mind. API providers can improve and release new versions without breaking existing systems, and the type and quantity of data do not have to be restricted. Consumers can quickly and easily swap API offerings in and out, or build in layers of redundancy and flexibility by integrating into multiple providers.
Being service oriented, APIs can be embedded into any capable product, to create seamless experiences for users. Effectively, the user interface (UI) layer of an application is completely separated from the business logic, and that logic can evolve without impacting the UI. This architecture is extremely flexible and removes a lot of complexity when creating software solutions. The possibilities and opportunities will grow exponentially as new APIs become available. It really is the dawn of a new era in digitalisation.
Secure and robust
OAuth2 (authentication and authorisation), data encryption, service throttling and other practices mean that APIs are just as secure if not more so than the existing system-to-system connections. By nature, there are usually only two parties for a web API: the consumer and the provider, which limits the attack vector, but also makes it easier to identify problems when they occur. In a legacy setup, if a statement does not arrive, the IT team would have to do a lot of digging to find the source of the problem: did the bank not send the statement? Did it get stuck on the swift gateway? Or at the swift service bureau? Or is it stuck somewhere else? Moreover, rather than wait for a file to be delivered, the latest data can continuously be polled, and if a problem arises, IT teams can react before users are aware. As an IT professional, this was the best way I found to improve the quality of the services we were providing.
Adopting APIs is a journey
APIs are nothing new. They have been around for decades, but the movement to the cloud, the improved security, the advancement of open banking regulation and the ever-increasing pressure to deliver new value, means that APIs are easier than ever to implement and offer great opportunities now and going forward for corporate customers.
Admittedly, there are some challenges when using APIs, and the FinanceKey solution has been purposely designed to mitigate these. FinanceKey customers can take advantage of all the benefits easily and practically. In summary, adopting APIs is a journey, but the earlier the journey starts, the sooner continuous incremental gains can be realised.
Not sure what a web API is: see the Wikipedia article here.
Please contact us at hello[at]financekey.com for more info or how we can help you with your API banking journey, and provide real-time insights and automation.