Open Banking Connectivity
We were recently referred to the great blog post by Rolands Mesters, CEO and Co-founder of Nordigen, where he nicely explains the basics of the Open Banking stack. On the lowest level of the stack there is “plumbing” layer, how Rolands is calling it, enabling programmatic access to the banking functionality either through official APIs opened by the banks for third parties or using other means, such as screen scraping or banks’ internal APIs designed primarily for their mobile apps. Another name for this is the connectivity layer, and its robustness ensures that “value add” (or data enrichment) and application layers can operate well.
Since Enable Banking is operating on the connectivity layer, I felt that it would be interesting to describe several issues arising when people try to integrate this layer. We are not going to dive into “alternative approaches” of getting programmatic access to the banking (e.g. screen scraping and use of reverse engineered internal APIs), because we believe open banking APIs are becoming mainstream and thus the old ways are going to become obsolete very soon. Here I have to say that I’m sure this is happening thanks to the old ways (no matter that they are now also seen as the bad ways). One may say that in Europe, which is leading the movement, it’s driven by the regulation (Open Banking in the UK and PSD2 in the EU), but I’d argue that it won’t be happening if the old ways didn’t gain enough traction. And I believe the open banking trend will expand beyond regulated markets, because it’s the way to give customers service they need and also to protect them.
What APIs are available
Before one can start using Open Banking it’s good to know what APIs are available, namely which banks provide which APIs. In addition to the most common individual (private customer) account information and payment initiation APIs, usually there are APIs providing similar functionality for business accounts and sometimes more specialized APIs with functionality for corporate users. Banks operating in the scope of PSD2 often combine functionality for individual and business accounts under the same API endpoints and authentication flows.
This may sound strange, but on most markets there is a lack of information on APIs provided by the banks, even where regulation is already in place. In the UK, the most developed market for the open banking industry, there is an official directory of ASPSPs (basically banks), but it is only available to the verified entities being part of the directory themselves. There are several independent attempts to build a list of the available Open Banking APIs and some provide good and valuable information, but they are far from being complete. So as a user of the open banking APIs you would mainly have to rely on the information gathered by your solution provider.
This may not be an issue for business customers wanting to integrate their own accounts in a limited number of banks or when operating on the well-known domestic market, but becomes more important when reaching a wider audience, especially on less familiar and rather fragmented markets.
Onboarding
Use of open banking APIs, as with any other not public APIs, always starts with onboarding. Theoretically in PSD2 environment ASPSPs (banks) are able to identify third-party providers (entities authorized by a local financial regulator to use either certain functionalities of the PSD2 APIs and usually referred as TPPs) by their eIDAS certificates, but in practice only a minority of banks allow direct access to their APIs with proper eIDAS certificates, while majority first require some sort of onboarding. Usually API client keys or similar artifacts are issued to the accessing party during onboarding.
The onboarding process from the bank’s side can be either automated through an API or a developer portal or be manual (in such case in order to use the APIs one would need to contact the bank's support and the access would be provided upon request). Onboarding through an API is often called dynamic client registration. For instance, Open Banking UK standard has adopted OAuth 2.0 Dynamic Client Registration protocol and thus made automation viable also on the side of API consumers. Onboarding via a developer portal is less suitable for automation on the API consumer side and onboarding involving bank support teams is literally impossible to automate.
When a number of the banks to be integrated raises, handling of the onboarding process becomes as important as the actual integration, especially when both automated and manual processes are to be handled. Thus connectivity solution providers are expected to assist their clients in the onboarding process, ideally through a self-service toolkit.
From sandbox to production
As it has been widely discussed very often banks do not provide sandbox environments to the standard set by Stripe and similar companies. And while one may expect that a sandbox environment shall be a fully functional “copy” of the corresponding live environment, banks usually don’t see ROI in sandboxes.
But provision of a sandbox environment is crucial for the development on the upper layers of the open banking stack. So the connectivity layer shall provide a robust mechanism for repetitive (perhaps even automated) invocation of open banking functionality, which would behave realistically but won’t involve any real data or live API calls. This can be achieved either by mocking APIs (as well as UI interactions) in the “plumbing” technology/service or by guiding its users to the chosen open banking sandboxes. Both approaches have their own pros and cons, and perhaps choice shall be made based on a goal.
Smooth transition from sandbox to production is as important as the functioning of the both environments. This is purely on the connectivity layer, but it’s important to highlight here that as the banking industry is heavily regulated, access to the live open banking APIs would most certainly be regulated as well (here I’m talking about markets where open banking is not yet a subject of the regulation). In some cases a connectivity solution provider can assist its clients, who are not regulated, in accessing the live APIs, particularly a client only needing to access its own data.
Harmonization
When the connectivity layer brings enough abstraction (i.e. takes care of secure access to the APIs, harmonizes data and flows, represents data using clean and simple format), it’s easy to integrate to the upper layers of the stack. Value add and application layers usually have to deal with multiple sources of data and interact with systems outside the pure banking ecosystem, so usability of the connectivity part becomes really important (as it helps to lower unnecessary complexity). One way to simplify the integration of open banking connectivity is to provide target platform tailored solutions (libraries, middlewares or microservices).
Although the connectivity layer lays on the bottom of the open banking stack, it’s not necessarily the lowest layer in the technology stack used for implementation of an end-customer solution. This is especially true when a connectivity solution is run “on-prem” or there is an intermediate “security box” needed for secure interaction with the target banks. It means a connectivity solution shall provide enough integration capabilities or be “programmable”.
Monitoring the changes
As mentioned earlier open banking is a living environment and API changes are very much anticipated. This is why monitoring of the announced changes and downtimes is really important. Open Banking UK is doing decent work consolidating the announcement from all the banks operating in the UK, while Europe under PSD2 regulation is still finding its way to deal with the issue. For instance, PRETA is working on the similar functionalities in its transparency directory.
As connectivity solution providers need to tackle API changes, they have to have efficient mechanisms for analyzing the changes, implementing adjustments and on-time migration from retiring APIs to the actual. On top of that continuous testing of APIs is needed to ensure that unforeseen disturbance in the APIs doesn’t disrupt the connectivity.
In his blog post Rolands divided providers of the connectivity layer into two categories: technology providers and service providers. He sees that while the first ones “provide a piece of software that allows connecting to bank accounts” and “don't store or process the data”, the second ones “ensure bank connectivity as a service”. I don’t disagree with the classification, but I’m sure it’s not that important, at least not at the higher level when we don’t compare particular solutions. Because Open Banking is very much a living environment and in order to provide an adequate solution, technology providers shall do all the same things service providers do and thus actually provide connectivity as a service (even if the software itself is run by its users). This is why I was not often making a difference between these two approaches and assumed that in both cases users need the same.
In the future we are going to write about technology pieces helping the Open Banking ecosystem in solving the plumbing. Stay tuned!
