It’s been four months since the FCA enacted Open Banking in the UK.
So far, you may not have felt a seismic shift in financial services – but Open Banking’s supporters envisage a utopia where services like payments, lending and mortgages are more personalised and data-driven, giving consumers greater control of their money and financial wellbeing.
In January, the Revised Payment Services Directive (PSD2) – designed to bring this Open Banking vision to fruition – established the legal infrastructure for registered non-bank third-party providers (TPPs) to access customers’ bank information – with the permission of the individual in question, of course.
The result will see innovative new account information and payment initiation services available to consumers and businesses alike.
Banking will no longer be a closed shop
Realising the Dream
However, there is still a long way to go before this dream is realised.
For the vision to flourish, and for the new world of data-driven payment initiation and account information services to grow, effective integration points for Application Programming Interfaces (APIs) need to be established. These play a central role in allowing TPPs to integrate with the customer account data held by the major banks.
It goes without saying that APIs are the motor that is driving Open Banking. They have the potential to power emerging customer-facing applications that initiate payments from customer accounts. These can be used to pay bills, make peer-to-peer transfers, or to aggregate account information to enhance the decision-making process around lending to consumers.
Content from our partners
Laying the API groundwork
The entity leading the implementation of Open Banking in the UK – imaginatively called the Open Banking Implementation Entity (OBIE) – has created and published “Open Banking Read/Write API standards.” These are intended to provide benchmarks to be met by the so-called “CMA9”, the UK’s nine largest current account providers, when developing API endpoints to integrate with TPPs’ technologies.
Such standards ought to streamline the process for TPPs offering payment initiation (PISPs) and account information services (AISPs) to connect to the banks and retrieve account data. That is the theory, anyway.
The deadline for the CMA9 to demonstrate that they had working APIs for registered TPPs was the 13 January 2018. Inevitably, some banks missed the cut-off. Nevertheless, those that made it are now undertaking a managed roll-out, testing the robustness of their APIs with a small cohort of TPPs. During this phase, the number of requests from TPPs to banks’ APIs is restricted.
According to Mitul Sudra, CTO at Openwrks, one of the seven TPPs involved in this managed roll-out: “One of the reasons banks are late, is that they’re not set up to deliver third-party integrations. Most FinTechs would build APIs first – it’s at the heart of what they do. However, banks don’t have that mind set.”
Banks don’t have an API mindset.
The Holy Grail
From a TPP developer’s perspective, the end goal is to have a single API.
This 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 Holy Grail, but it is still some way off.
For Myles Stephenson, CEO of B2B payment API provider, Modulr: “A European-wide API standard for Open Banking would be ideal. But before that can happen, there needs to be better EU or country-level organisation around Open Banking APIs.”
At the EU-level, co-ordination is starting to emerge, thanks to the foundation of The Berlin Group, a pan-European initiative aimed at creating payments interoperability standards and harmonisation.
Other similar groups are forming across Europe. STET, for instance, is a payment network owned by six French banks, which has a “PSD2-compliant API.” The CAPS initiative is another example. It 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 also getting in on the act. It is developing a centralised PSD2 directory for TPPs to achieve that all-important harmonisation of standards.
Modulr’s take
The process of harmonising API standards is vital to ensure that TPPs and banks can integrate seamlessly across the continent. But, as yet, there is no complete agreement as to what that harmonised standard should be, or what an effective API should look like.
At Modulr, we’ve highlighted a few key things that we believe make for a strong, effective API:
- In-depth developer documentation
- Quick-start guides about simplified use cases
- A seamless process to sign up to a test system to try out the API
- Consistent data labelling, as well as consistent and informative error messages to support developers in navigating the API
- All product features should be supported through the API, and the API should evolve as the product changes
- Sample code and a software development kit to help developers get started quickly
- The use of industry standard security/authentication, such as the Transport Layer Security and Hash Message Authentication Code used by Modulr
Creating an Open Banking world
It’s still early days for Open Banking, but it certainly has the potential to transform the sector, and the way consumers think about and access banking services.
For this potential to be realised though, more needs to be done to develop a solid framework for API endpoints. The bare bones are already there, in the form of PSD2 and, with more collaboration between organisations at the EU-level and nationally, we should see the development of API standards that can foster real change.
