Open Banking APIs: The Holy Grail for Developers?

This article was first published in AltFi

So, I’m guessing you’ve heard of this thing called Open Banking. Its proponents often paint a vivid picture of financial utopia where lending decisions, mortgage approvals, payments and other financial services are more personalised and data-driven.

Almost three months have passed since the Revised Payment Services Directive, or PSD2, was scheduled to be implemented into national law by EU member states. PSD2 provides the framework for registered non-bank third-party providers, or TPPs, to provide new payment initiation and account information services by opening access to customers’ bank account information.

“The work isn’t finished,” says Myles Stephenson, CEO of B2B payment API provider Modulr. “No one can say we’ve created this thing yet and it’s been enabled through Open Banking.”

What is needed for a lot of these new, more personalised, data-driven payment initiation and account information services to emerge are APIs (Application Programming Interfaces).

The ease with which registered TPPs can integrate their APIs with customer account data held by the banks is central to Open Banking’s success. 

Suffice to say, APIs are the engine room of Open Banking, powering a lot of the new and innovative customer-facing applications that are expected to emerge around initiating a payment from a customer’s account to pay a bill or make peer-to-peer transfers, for example, or aggregating account information to make enhanced lending decisions.  

In the UK, the entity charged with implementing Open Banking, conveniently named the Open Banking Implementation Entity (OBIE), has developed Open Banking Read/Write API standards, which the “CMA9” (the UK's nine largest personal and small business current account providers) are meant to adhere to when developing API endpoints for TPPs to integrate with. 

In theory, these standards should make it easier for registered TPPs that offer payment initiation (PISPs) and account information services (AISPs) to connect to the banks to retrieve account data based on the customer granting their consent. 

The 13th January 2018 was the deadline for the UK’s nine largest banks to demonstrate that they had Open Banking APIs available for authorised TPPs to access. Some banks, however, missed that deadline. As part of a managed roll-out phase, banks are testing the robustness of their APIs with a limited number of TPPs. During the managed roll-out phase, the number of requests to the banks’ APIs from TPPs are limited. 

The Holy Grail from a TPP developer’s perspective is to have a single API, which will significantly cut down on development timeframes and the ongoing work required to manage and maintain interfaces with all the UK banks. “That’s the hope and aim in the longer term, but we’re not there yet,” says Ritesh Tendulkar, chief software architect at Modulr.

Beyond the UK, a European-wide API standard for Open Banking would be ideal, says Stephenson, Modulr’s CEO. But before that can happen, he adds, there needs to be better EU or country-level organisation around Open Banking APIs. 

Co-ordination is starting to emerge at the EU level with the formation of The Berlin Group, “a pan-European payments interoperability standards and harmonisation initiative.” 

“Other similar groups are forming across Europe,” says Stephenson pointing to STET, a payment network owned by six French banks, which has a“PSD2-compliant API.” There is also the CAPS initiative, which describes itself as a “multi-stakeholder coalition-of-the-willing that aims to make PSD2 work safely, in practice and at scale for all,” although it does not appear to have issued its own API specs. PRETA, a subsidiary of EBA Clearing, is developing a “centralised PSD2 directory for TPPs. 

Meanwhile, we’ve put together a list of things that we believe make for a killer API.

To find out more about how APIs work, click here.