Kill APIs if we want Open Finance

an article written by ANDREW SMITH CTO

Over the past years we have seen PSD2 come into force, we have had Open Banking (and the OBIE) both with the aim of bringing a world of APIs to banking, the desired goal, to enable third parties to gain access to banking to enable them to provide better customer experiences and choice. However, as the OBIE is being wound down, we are starting to look to the next governing body to help define API standards and ensure infrastructure resilience while also playing with the concept of Open Finance.

While Open Banking may not have proven to bring mass adoption with it by end customers, it has at least shown that there are other ways of doing things, more modern approaches. There are some great solutions now being brought to the market which are only possible because of Open Banking APIs, but it is fair to say, Open Banking hasn’t had the impact many predicted or may have hoped for.

So, has Open Banking failed? Well the short answer IMHO is no, rather it has shown that for real customer outcomes to be improved, we need to look at customers finances as a whole and not just their bank account/credit card activity. This brings us to the concept of forcing other areas of the financial services sector to provide Open API type of access. While this may seem all great, there are some learnings that must be learnt from Open Banking, and for me, these need to be addressed asap.

Standards aren’t standard

Standards are often the keys to interoperability. So, with this in mind, the OBIE and PSD2 set about setting standards of what Open Banking APIs should look like, how they should behave. Banks though have to build these API layers, knowing that they don’t really fit with the infrastructure or approach they may have within their technology stack. Let’s park the issue of legacy systems, because even with an uber modern Core Banking system, Open Banking APIs are very prescriptive and will not follow your IT design pattern of choice. Because of this, and various other technical challenges, we find that banks have to work around the spec, and this leads to interpretation. The result, a third party needs to have tweaks for bank-to-bank integration. This is a maintenance nightmare, not just for the third parties, but also the banks themselves, which has resulted in infrastructure that clearly hasn’t got the same up time as the bank’s core systems.

With standards, less is often more. Less to cover leads to better focus which leads to the removal of interpretation which leads to a robust standard. A key learning before we embark on Open Finance is that we MUST have less documentation and greater focus on accuracy.

Ditch direct APIs

If we really want to thin out our standards, then we need to focus on what data is needed, and less on the API implementation / flow. This wont thin down documentation massively, but it will allow the pencil to be far sharper in terms of accuracy and the removal of interpretation wiggle room. The second learning is that banks need to make sure their “Open Banking / Open Finance” infrastructure is resilient and fits more seamlessly with their technological approaches. Given that each bank is different, their IT strategy will be different, their core systems are different, their capabilities are different, their ability to invest in Open Finance is very different this is the biggest learning we must take forward into the world of Open Finance.

So how do we solve these two issues while still providing external standardised connectivity and interoperability amongst financial services companies. The answer is simple, move with the times…

Direct APIs are dying off. We therefore need to move with the times and kill off this concept of direct Open Banking and Open Finance APIs. Modern architecture uses Event Patterns and not direct APIs. With an event pattern, components (software) raises /publishes an event to an event broker. The broker has subscribers who then receive that event and can process it accordingly. There are many benefits here, including the fact that publishing and consuming events is consistent, no matter what the system is you want to integrate with or what process you wish to trigger. The API for publishing events is consistent and does not change, so you are abstracting API change away from your system. In addition, the beauty here is a single event can be picked up by multiple subscribers, and therefore promote parallel processing. You can see why direct API integrations are dying off…

Event brokers and orchestration

If we want to provide Open Finance, then financial institutions need to expose an event broker. Third parties can then push events onto that event broker which can be picked up by the financial company and acted upon. The financial companies’ implementation becomes irrelevant at this point, rather it is down to them to simply act upon the event and return an event if required. This gives them freedom to architect their solution in a way they know will work, in a fashion that plays nicely with their IT strategy and in a way, they can improve resilience. This also makes them far more accountable if they are unable to meet certain up-time obligations.

From a third-party point of view, event broker APIs very rarely change, they are constant. This means the focus becomes that of what data is within the event, something that can be specified and made extremely concise. From institution to institution the approach will be unified as to will the experience for the third party. This removes the challenge largely of API management and supporting a plethora of direct APIs and their versions. Essentially API implementation and change has been abstracted away.

This is how we can move to a far more prescriptive standard regarding Open Finance while at the same time, simplifying implementation.

I should also add that event patterns will dramatically improve the customer experience and make everything feel far more integrated – when compared to that of multiple APIs from multiple providers all of which have to be triggered in specific orders.

Implementation

Financial Services need only leverage small aspects of the Cloud to enable this new approach. Both Azure and AWS have highly mature, robust event orchestration capabilities, and most banks globally have relationships with both Microsoft and Amazon. Simply utilise these cloud providers orchestration capabilities, technology such as Event Grid and Event Grid Domains from Azure will do the trick.

The setup is consistent and simple across the financial services organisation and for a third party. The implementation by the financial services organisation is behind the event broker and therefore they don’t need to worry about following specifics, rather they hook directly into what works for them best. The standard becomes highly data focussed in terms of what the data being published onto the event broker looks like – standards such as ISO 20022 will help here and Microsofts Common Object Data Model (for financial services) will also help.

Summary

Open Finance will provide dramatic improvements in terms of customer outcomes once in-place. Better access to financial products, improved transparency, better customer services and new innovations that can be taken advantage of will all start to happen. But this can only really happen with better standards regarding data and simplified implementation approaches – for both the third party providers and financial service organisations. Direct APIs bring with them a level of complexity which is simply not required in todays modern architecture. By moving Open Finance away from this now dated construct and towards that of Event Patterns, Open Finance becomes far easier to implement and execute successfully. Here is to the death of Open Banking APIs and the birth of Open Finance Eventing….