Open Banking Connectivity

We were recently referred to a great blog post by Rolands Mesters, CEO and Co-founder of Nordigen, where he lays out the basics of the Open Banking stack. At the bottom of the stack sits what Rolands calls the "plumbing" layer: the layer that enables programmatic access to banking functionality, either through official APIs that banks open up to third parties, or through other means such as screen scraping or the internal APIs banks built for their own mobile apps. Another name for this is the connectivity layer, and its robustness determines how well the "value add" (or data enrichment) and application layers above it can operate.

Since Enable Banking operates on the connectivity layer, we wanted to describe some of the issues that come up when people try to integrate it. We won't cover alternative approaches to getting programmatic access to banking, such as screen scraping or reverse engineered internal APIs, since open banking APIs are becoming mainstream and the old ways are on their way out. That said, the old ways deserve some credit: even though they're now seen as the bad ways, they're part of why open banking gained the traction it did.

In Europe, which is leading the movement, regulation gets most of the credit (Open Banking in the UK and the PSD2 directive from the European Commission in the EU). Still, that regulation likely wouldn't have happened if the old ways hadn't already proven there was demand for this kind of access. We expect the trend to expand beyond regulated markets too, since, at its core, it's about giving customers the service they need while also protecting them.

What APIs are available

Before you can start using Open Banking, it helps to know what APIs are available, and which banking API providers support them. Alongside the standard individual (private customer) account information and payment initiation APIs, there are usually similar APIs for business accounts, and sometimes more specialised ones built for corporate users. Banks operating under PSD2 often combine individual and business account functionality under the same API endpoints and authentication flows.

This might sound strange, but in most markets there's a real lack of information about the APIs banks provide, even where regulation is already in place. In the UK, the most developed market for open banking, there's an official directory of Account Servicing Payment Service Providers (ASPSPs) (essentially, banks), but it's only accessible to verified entities that are already part of it. Several independent projects have tried to build an open banking tracker covering the APIs available, and some do a solid job, but none are complete. So as a user of open banking APIs, you'd mainly have to rely on whatever your solution provider has managed to gather.

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

Using open banking APIs, like any other non-public API, always starts with onboarding. In theory, under PSD2, banks (ASPSPs) can identify third-party providers (TPPs, entities authorised by a local regulator to use certain PSD2 API functionality) through their eIDAS certificates, specifically the QWAC and QSealC certificates that verify who they are. In practice, only a minority of banks allow direct access with just a valid eIDAS certificate. Most still require some form of onboarding first, after which API client keys or similar credentials are issued to the accessing party.

Onboarding can be automated through an API or developer portal, or handled manually, where you'd contact the bank's support team and wait for access to be granted. Onboarding through an API is often called dynamic client registration. The Open Banking UK standard, for example, adopted the OAuth 2.0 Dynamic Client Registration protocol, which made automation possible on the API consumer's side too. Onboarding through a developer portal is harder to automate, and onboarding that runs through a bank's support team is effectively impossible to automate.

As the number of banks you need to integrate grows, managing onboarding becomes just as important as the integration work itself, especially when you're juggling both automated and manual processes. This is why connectivity solution providers are expected to help their clients through onboarding, ideally with a self-service toolkit.

From sandbox to production

As has been widely discussed, banks often don't provide sandbox environments to the standard set by Stripe and similar companies. You might expect a sandbox to be a fully functional copy of the live environment, but banks usually don't see the ROI in building one to that standard.

Even so, a working sandbox is crucial for building the upper layers of the open banking stack. The connectivity layer needs a reliable way to repeatedly, and ideally automatically, invoke open banking functionality that behaves realistically without touching any real data or live APIs. This can be done either by mocking the APIs (and the UI interactions) within the connectivity technology itself, or by guiding users toward existing open banking sandboxes. Both approaches have their own tradeoffs, and the right choice depends on the goal.

A smooth transition from sandbox to production matters just as much as how well each environment functions on its own. This sits entirely within the connectivity layer, but it's worth noting that because banking is such a heavily regulated industry, access to live open banking APIs tends to be regulated too, even in markets where open banking itself isn't yet formally regulated. In some cases, a connectivity solution provider can help clients who aren't regulated get access to live APIs, particularly when a client only needs access to its own data.

Harmonization

When the connectivity layer provides enough abstraction, handling secure access to the APIs, harmonising data and flows, and presenting everything in a clean, simple format, it becomes much easier to build the upper layers of the stack on top of it. Value add and application layers usually have to work with multiple data sources and systems outside the banking ecosystem, so how usable the connectivity layer is matters a lot, since it's what keeps unnecessary complexity out of everything built above it. One way to simplify open banking integration is to offer solutions tailored to the target platform, such as libraries, middleware, or microservices.

Although the connectivity layer sits at the bottom of the open banking stack, it isn't necessarily the lowest layer in the technology stack used to build an end customer solution. This is especially true when a connectivity solution runs on premises, or when an intermediate security component is needed for secure bank integration with the target banks. In practice, this means a connectivity solution needs to offer enough integration options, or be programmable enough, to fit into that stack.

Monitoring the changes

As mentioned earlier, open banking is a living environment, and API changes are something to expect rather than be surprised by. That's why monitoring announced changes and downtimes matters so much. Open Banking UK does a decent job consolidating announcements from banks operating in the UK, while Europe, under PSD2, is still working out how to handle this consistently. PRETA, for instance, is building similar functionality into its regulatory directory.

Connectivity solution providers need efficient ways to track this kind of open banking news, analyse the changes, make the necessary adjustments, and migrate from retiring APIs to their replacements on time. On top of that, continuous testing of the APIs is needed, so an unexpected disruption doesn't break the connectivity without warning.

In his blog post, Rolands split connectivity layer providers into two categories: technology providers and service providers. As he describes it, the first group provides a piece of software that lets you connect to bank accounts and doesn't store or process the data, while the second ensures bank connectivity as a service.

In his blog post, Roland 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”. This classification holds up, but it doesn't matter much at a higher level, at least not until specific solutions are being compared. Open banking is such a living environment that, to offer an adequate solution, technology providers end up doing everything service providers do anyway, effectively delivering connectivity as a service even when the software itself runs on the client's own infrastructure. That's why the two approaches aren't treated as fundamentally different here: either way, users need the same things.

And if you'd rather not solve that plumbing problem yourself, you know where to find us.

---

Explore More: