With the Australian Government pushing forward with Open Banking in the wake of the Farrell Report, and that report having recommended adopting the UK’s standards as a starting point for Australia, the learnings from this journey are especially relevant for Australian financial institutions and technologists.
Open Banking has huge potential to deliver significant value to retail banking customers, by enabling secure/reliable access to third-party apps (e.g. accounting and budgeting tools) and offering payments direct from any bank account.
Banks across Europe are required by law (the second Payment Service Directive or PSD2) to allow customers to use a regulated third party to access their bank account (with their permission) using a secure interface (e.g. a secure API).
The nine largest current account providers in the UK have been mandated by the Government to follow the UK Open Banking Standard. The Open Banking Implementation Entity was founded in late 2016, and my role is to lead the technical teams to design and deliver this standard.
The story so far
Back in March 2017, the first phase went live. The UK’s nine largest retail banks and building societies launched their Open Data endpoints. This allowed any third-party developers to access information about ATMs, branches and products (e.g. features, benefits, fees and charges).
Then, in August 2017, we published version 1 of the Read/Write API standard. This included specifications for accessing account and transaction information (the read API), payment initiation (the write API), and a security model to ensure that third parties can only have access with the explicit consent of the customer.
Version 1 of the standard started to go live on a managed roll-out basis in January 2018, and since then we have been seeing gradual adoption by a number of ASPSPs and third parties, following on from these parties receiving regulatory status by the Financial Conduct Authority (FCA).
We published a version 2 of the standard in February 2018, which extended the scope to cover all PSD2 accounts for the Read API. And we are now working to publish a version 3 in August 2018, which will cover all PSD2 requirements for both Read and Write. This should then allow any banks who adopt the UK standard to implement a PSD2-compliant interface by the deadline of September 2019.
Over the last 18 months, we achieved a lot. The UK banking industry has started to adopt the standard, and we are leading the way globally. But this has not been an easy journey and there is still a long way to go. Here are some learnings to date.
Regulations are open to interpretation
PSD2 sets the ground rules and overall scope for Open Banking in Europe. This is further extended by the Regulatory Technical Standards (RTS), which were finalised and published in March 2018. The RTS sets out more detailed rules for how and when customers should authenticate with their bank account to give access to regulated third parties, and also how these third parties and banks should communicate with each other in a secure manner to share data.
There is additional legislation coming into effect in May 2018 across Europe – the General Data Protection Regulations (GDPR) - which gives rights to individuals about their personal data and puts a number of obligations on how organisations collect, store and use this data.
This is all great, as it creates a more level playing field for new payment service providers to enter the market, while at the same time protecting the customer. However, there are quite a few potential gaps and overlaps, and different legal experts often have different views as to what is required for both banks and third parties.
The biggest challenge this raises is that many third parties are expecting rich APIs which unlock new and innovative business models. Yet in many cases, the regulations only hint at this and do not require banks to be quite so open. And many banks are not quite ready to be so forthcoming, and in some cases are looking to do the bare minimum, not least because opening up multiple legacy back-end systems in an API world is a big technical challenge.
A good example of this divide is in the application of Strong Customer Authentication (SCA) exemptions.
Under PSD2/RTS, all payments require the customer to undertake SCA to confirm that the payment should be made. However, there are a number of exemptions where SCA is not mandatory, one of these being payments to a trusted beneficiary. Many third parties would like this to enable a ‘One Click’ type scenario, so that for any merchant/recipient who is set up as a trusted beneficiary, the third party can process payments without the customer having to authenticate (or even be present) each time.
One can see how this can enable innovative new scenarios and ultimately replace less secure and opaque methods such as ‘card on file’ or ‘continuous payment authority’. However, under PSD2/RTS, it is optional for banks as to whether they allow SCA exemptions. And, even if they do, they can reject a payment and require that the customer undergoes SCA again. So, unless there is clear regulatory guidance, there is a risk that banks will not fully meet the needs of the market in such areas.
The UK Government has done a number of smart things to address some of these ‘contradictions’ and help get the Open Banking ecosystem off the ground. Firstly, they created the Payment Services Regulations (PSRs), which define how PSD2 is to be implemented in the UK. And secondly, the Competition and Markets Authority (CMA) created the CMA Order, which required the nine largest UK banks and building societies (the CMA9) to be live in the market over a year in advance of the PSD2 requirement for the rest of Europe.
The CMA Order has been particularly useful in three key areas.
Firstly, it requires that the CMA9 all adopt a single API standard, rather than each interpreting the regulations in their own way. This is essential to reduce barriers for third-party developers.
Secondly, it defines several more granular requirements. In some cases (e.g. Open Data), these have gone beyond the requirements of PSD2.
Lastly, and perhaps most importantly, it gives some example end customer use cases which are expected to be enabled, including, for example, use cases which assume SCA exemptions.
Transparency and collaboration are essential to effective governance
The UK Open Banking programme has always been much more than a compliance programme, and is overseen by an independent trustee, Imran Gulamhuseinwala. The Steering Group, and indeed the entire programme, is made up of stakeholder representatives from the CMA9, other ‘challenger’ banks, FinTechs, third parties, consumer organisations, consultants, technology providers and regulators (including the CMA, FCA and Her Majesty’s Treasury).
In total we have over 2000 individuals representing these groups, and run a large number of regular meetings and events to ensure that everyone has an opportunity to contribute. However, there are often conflicting views and it is not easy to reach consensus. And it would be fair to say we have had a few ‘bumps’ along the way, trying to get agreement in a timely manner. So, over the last few months, we have been updating our governance process.
One of the key principles of the UK Open Banking programme has been transparency. So we use Confluence as a collaboration tool, and regularly share draft and pre-release versions of documents (proposition papers on scope, API specifications and guidelines) in a ‘collaboration’ space. Here we seek comment and feedback in an open forum—so everyone can see everyone else’s comments. Overall this helps get higher quality feedback and reduces the time to iterate these documents to a state where they can be agreed.
Standards alone are not enough
There are several emerging Open Banking standards across Europe, and many banks are some way down the road to building out their APIs. But what marks the UK out is that we are not only creating a standard, but also running a national implementation programme to get the ecosystem off the ground. We have a duty to ensure the banks implement the standard consistently and that third parties can adopt this and build out their propositions as effectively as possible.
Something we knew at the start, not least because it was part of the CMA Order, was that we needed a ‘whitelist’ to ensure that regulated third parties and banks know at all times who can access what APIs. So we created the Open Banking Directory, which has three main functions:
All regulated entities are granted an Open Banking Certificate which confirms their regulated status. Third parties and banks can also create more granular software statements and certificates for each brand and/or application. Certificates can be self-revoked by entities, but Open Banking will also revoke certificates from entities who lose their regulatory status.
This service will be extended to be compliant and inter-operable with the PSD2 eIDAS standard when this is finalised. But there is still a need from both third parties and banks to have additional certificates. And allowing users to self-manage these provides a vital service.
The identity component of the platform delivers a searchable marketplace of all third parties and banks, which allows discovery as new players enter the market.
It includes a service which validates the identity of both organisations AND individual contacts, and covers regulated and pre-regulated entities. The platform can thus be used by banks as a trusted Identity Provider for registration with their developer portals. This saves time for both banks and third parties, and significantly reduces barriers for smaller players.
The service also supports (near) real-time updates of the regulatory authorisation status for each entity, which is checked at least daily across all European markets. This allows banks to check this status from a central source, rather than having to check with each market’s national authority, significantly reducing the risk of trading with an unregulated party.
The Directory is fully interoperable with the Open Banking API standards and security profile. However, it can also be used with any APIs a bank offers to the market, and for any third parties who wish to access these APIs.
Furthermore, the Directory supports the dynamic client registration standard, which automates the on-boarding process between third parties and banks, and further reduces barriers, especially to smaller players.
There are also a number of additional services which have emerged as essential components to getting an ecosystem like this off the ground:
Liability cover: to protect against trading with un-regulated entities (e.g. in case entities are not revoked within one working day of removal from national authority registers).
Dispute resolution: a managed service to resolve issues between ASPSPs and TPPs.
Support services: training, service desk, access to sandboxes, testing tools and a certification service.
Many of these additional services were not envisaged nor planned a year ago. But they provide essential value which further reduces costs and risks for all participants and speeds up market entry and adoption. It is hard to see how a financial API ecosystem can thrive without a platform and services like these.
Open Banking has the potential to transform banking, not only in Europe but across the world. Over the next year or so, I personally expect to see accounting platforms and budgeting tools being the earliest adopters, as APIs are much more secure and reliable than credential sharing and screen scraping.
But what excites me the most is the potential to replace cards for many payment scenarios. This may well require some creative thinking and/or commercial models over and above the core regulations in Europe, but I believe it will happen eventually.
In summary, it will take time for Open Banking to reach its potential in the UK and Europe. So here are my top three tips for speeding this up in other markets.
Tip 1: Regulations are easier to understand and much easier to implement if they have a strong rationale. The more each requirement can be based on a desired end user outcome or use case, the less likely it is that people will disagree about the scope, and the easier it will be for regulators to measure compliance which in turn will speed up adoption and deliver the intended benefits earlier.
Tip 2: Old school process and technology are too slow and clunky. Getting people to feedback via email and storing documents in closed file systems isn’t good enough. Using smart online tools (like Confluence and Slack) to allow real-time collaboration provides transparency and helps with governance, as it allows more people to contribute and can be used to show evidence that people have been listened to.
Tip 3: Having a trust framework and identity platform is essential. There are also a number of other key support services needed to help third parties and banks implement and adopt any standards. While not a regulatory requirement outside the UK, it is hard to see how Open Banking can work effectively in any market without this.
Chris is a Chief Technology Officer with 30 years’ experience building high performance teams, platforms and products for global brands, across many sectors - including Retail, Consumer Goods, Travel, Leisure, and Financial Services. He has managed multi-million pound budgets and generated hundreds of millions in benefit for many of these brands.
Chris is currently leading the API teams at Open Banking, defining the API standards to meet the CMA remedies for Open Banking in the UK.
Open Banking Implementation Entity was set up by the CMA in 2016. We are governed by the CMA and funded by the UK’s nine largest banks and building societies: Allied Irish Bank, Bank of Ireland, Barclays, Danske, HSBC, Lloyds Banking Group, Nationwide, RBS Group and Santander.
We work with these banks and building societies as well as challenger banks, financial technology companies, third party providers and consumer groups. Our role is to:
Design the specifications for the Application Programme Interfaces (APIs) that banks and building societies use to securely provide Open Banking
Support regulated third party providers and banks and building societies to use the Open Banking standards
Create security and messaging standards
Manage the Open Banking Directory which allows regulated participants like banks, building societies and third party providers to enrol in Open Banking
Produce guidelines for participants in the Open Banking ecosystem
Set out the process for managing disputes and complaints