UK open banking needs a new home, a new mandate and a new roadmap

null
Jack Wilson, VP Policy & Research
7 Feb 2023
Document with abstract UI elements

Open banking is going through some changes. Five years after its establishment, the Open Banking Implementation Entity (OBIE), responsible for UK open banking API standards, is in need of a new home, a new mandate and a new roadmap.  

At the end of January, Charlotte Crosswell, the Chair and Trustee of the OBIE published a transition report, giving detailed recommendations on those three things. In this blog post, we sum up what she said and share our feedback.


A new home 

The OBIE is housed in an independent company (Open Banking Limited), funded by the nine biggest UK banks and overseen by a Trustee who ensures that it progresses the aims of the Competition and Markets Authority (CMA) Order, to promote competition through open banking.

Open Banking Limited employs technical experts to develop and maintain standards which help UK banks and third party providers (TPPs) to deliver open banking and monitor its implementation. 

But the OBIE isn't a permanent body and its future is now the subject of much discussion, following the end of the Open Banking Roadmap. The decision about OBIE’s future ultimately falls to a committee of regulators called the Joint Regulatory Oversight Committee (JROC). In her report, the Trustee recommends:

  • a ‘continue as is’ approach until a decision from JROC, followed by: 

    either transfer of functions to a new legal entity/ entities or moving certain functions to other existing organisations.

Our take

TrueLayer has worked closely with the OBIE since it was set up. We believe it has been critical to making UK open banking a success.

  • It’s important that the OBIE continues to be well funded and resourced in the interim, while we wait for a decision from JROC. That will ensure that UK open banking APIs can continue to enable competition and innovation in retail banking. 

  • Open banking standards for both payments and data should continue to be developed by a single, independent body. Splitting payments and data into new or existing organisations would lead to inefficiencies (eg additional regulatory requirements, different certification regimes, incompatible standards). Much of the value of open banking is built on being able to use data and payments seamlessly together, so standards should be developed together. 

A new mandate 

The OBIE's narrow mandate has constrained the development of open banking in the UK. The CMA Order empowered the OBIE to develop standards for both payments and data APIs, which have supported a huge amount of innovation and competition. 

But it hasn’t been possible to go beyond what was prescribed by the Order. Variable Recurring Payments (VRP) is one example of this. 

The Order requires banks to provide VRP APIs that enable sweeping between accounts in the same name, to enable better ways to save or pay off credit. But the Order falls short of requiring banks to enable these same APIs to be used for payments to businesses

This means open banking can't yet compete in areas like subscription or utility payments, or as an alternative to card on file and direct debit payments. 

In her report, the Trustee recommends that:

the future body has adequate resourcing to support standards development, ecosystem support and strategy that fall outside of the Order. This could be funded and provided for by non-CMA9 funding.

Our take

We strongly support that the successor to OBIE has a mandate to develop API standards beyond current rules or regulatory requirements. The future body should be able to focus its delivery broadly around objectives to enhance innovation and competition for the benefit of businesses and consumers. 

We acknowledge that funding of such a body should be shared between more ecosystem participants (beyond the CMA9) and we’re committed to working with industry and regulators on ways to achieve this.

A new roadmap 


The OBIE has focused on delivering core functionality, such as APIs to access data and payments, and more recently VRPs, but in her report, the Trustee describes ‘fundamental issues’. These are shortcomings in the way these APIs have been implemented or designed, which continue to hold back the adoption and development of open banking. 

We encourage JROC to set in motion a new roadmap for open banking that prioritises these challenges. Below, we give our views on each of the issues the Trustee describes:  

Ecosystem reliability 

One measure of the success of open banking is conversion rate. This measures the proportion of people that successfully make it through an open banking customer journey.  

The Trustee notes that "conversion rates ... are inconsistent and/or low" and:

A possible way to resolve this would be for the Financial Conduct Authority or other authorities to have the power to set out clear Management Information (MI) requirements from both banks and TPPs to help determine conversion rates. [They could also] ... interrogate this MI and take appropriate enforcement action if conversion rates fall below a set figure.

Our take

Conversion rates are the key metric when considering the success of open banking. An important part of OBIE’s work has been to develop Customer Experience Guidelines to improve the overall open banking customer journey (how many screens are involved, how clear and user friendly the language is). 

This has been particularly important because part of any open banking user journey involves authentication steps which take place at a customer’s bank, and are outside the control of a TPP like TrueLayer.  

We also agree that an authority is needed to develop the reporting of conversion rates and we’re committed to working with industry and regulators on ways to achieve this. 

Fraud interventions by banks

A pressing challenge for open banking is the dependency that TPPs have on each individual banks’ approach to fraud risk. The Trustee describes: 

unnecessary (ie false positives) friction (eg warnings and additional screens), payment failures (eg payment declines), and the lack of information provided to TPPs when things don't work as they would expect. This is linked to the current Contingent Reimbursement Model (CRM) Code which has led many banks to adopt blanket (not risk-based) warnings, and to apply low payment limits, as a result of the PSD2/PSRs principle of channel parity, whereby banks apply the same limits to TPPs that they do in their direct channels, irrespective of the risk levels.

Our take

Fraud interventions are a major issue for open banking. Low payment limits in particular impact TPPs’ ability to offer cost effective payment methods in high-value ecommerce. This prevents important competition that could benefit merchants and consumers, especially during the cost of living crisis. 

We agree with the Trustee’s recommendations to: 

  • Remove equivalence: meaning the payment limits banks have for manual bank transfers would not automatically be the same limits that banks apply for open banking payments. As we've highlighted before, open banking is a solution to both unauthorised payments and scams. 

  • Develop whitelists: whitelists shouldn't be limited to payees that are government departments. Regulated open banking providers should be able to add beneficiaries to the whitelist based on meeting due diligence conditions. 

  • Implement transaction risk indicators: these will be an important mechanism for TPPs to share information with banks about payments being initiated. They have useful application for sharing risk information and beyond, such as for facilitating gambling blocks. But we need an industry approach to ensure that enhanced information sharing doesn’t result in new types of ‘de-risking’, where, as the Trustee highlights, banks apply blanket (not risk-based) approaches and block certain categories of beneficiary. 

Customer transparency

Although technical in nature, this issue boils down to: how does a customer see their open banking services within their banking app?

TPPs should be able to pass the information we want customers to see in their banking apps in a simple and scalable way. This information should also be presented in a user-friendly way. That means:

  • presenting open banking payment mandates for recurring payments, alongside other types of mandates such as standing orders and direct debits 

  • presenting open banking payment transactions in bank statements in a consistent way that focuses on who has been paid, not who facilitated the payment (the latter is the case at present)

  • presenting open banking data sharing in terms of who the data has been shared with, not just who enabled the data sharing (the latter is the case at present)

Levelling-up and error codes

Only nine UK banks are required to implement the API standards developed by the OBIE. While others have voluntarily adopted these standards, there are gaps and inconsistencies. 

The Trustee notes:

there is a strong case to enforce the same requirements on the entire ecosystem … rather than continue to only make such [open banking] demands on the CMA9.

Our take

We agree that open banking will be significantly improved if more standardisation is applied beyond the CMA9.

As the Trustee also notes, one area lacking standardisation within and beyond the CMA9 is error codes. This ultimately leads to poor user experiences because it prevents TPPs from resolving issues in a timely manner. It should be a priority focus in the new roadmap. 

Next steps 

This transition report provides an important summary of issues facing UK open banking and provides real food for thought for Government and regulators (especially JROC). It’s now up to them to act on the report's recommendations at pace to regain the momentum of UK open banking. 

We look forward to working with the new Chair and Trustee of OBIE, Marion King, the wider industry and JROC on this important transition. 

Insights straight to your inbox
Join 10,000+ subscribers getting the latest open banking news.
Latest
checkout
6 Dec 2024

3 tipping points for change within ecommerce payment experiences

Cart abandonment
2 Dec 2024

How to reduce ecommerce cart abandonment

dev sec ops shared responsibility
27 Nov 2024

Devising a delegated alerts model for SecOps

Categories to explore