Over the last four months, I've been working with one of our clients on their Open Banking Programme. During this time, I learnt a lot more about Open Banking, identifying its benefits, whilst also formulating an opinion on how areas that lack focus due to meeting regulatory requirements could be improved. 

I've now decided to cut my teeth in the blogging world and share that opinion.

A bit of background into Open Banking

Open Banking is the secure way to give providers access to your financial information.

In 2016, the UK Competition and Markets Authority (CMA) issued a ruling that requires the nine biggest banks (CMA9) to allow licensed startups/third party providers (TPPs) access to their data, down to the level of transaction-account activity.

In order to facilitate this, the Open Banking Implementation Entity (OBIE) was setup. Their role is to work with the UK’s largest banks and building societies (as well as challenger banks, financial technology companies, third party providers and consumer groups) to enable competition, open up personal information and to empower an individual with choice of vendor.

What is good about Open Banking?

  • in-depth documentation
  • enables new ways for consumers to make purchases via the Payment Initiation APIs
  • unlocked data

    • enables innovation from TPPs
    • empowers consumers to have a holistic view of their financial situation

What has not been so good?

  • high implementation cost for CMA9 
  • regulatory change is prioritised which has the potential to stifle innovation
  • inconsistency between which types of accounts information is available from each provider (credit card, current accounts, savings)
  • unlocked data

    • moved GDPR responsibility to TPPs
    • duplicated data is now in multiple data centres
    • consumers now have multiple locations to manage their authorisations
  • the forgotten customers

Who are the forgotten customers?

Traditionally when creating APIs, the consumer of those APIs is considered the customer. The developers are utilising a service that has been provided and their experience of doing so should be considered as part of the process.

The way that Open Banking has been delivered leaves numerous areas for improvement when it comes to the Developer Experience (DX).

App registration per provider and environment

There are two environments provided by each CMA9; Sandbox and Production.

Sandbox provides the same APIs, except there are a number of personas defined and the data is read-only.

As a TPP, you are required to register your application with each provider and environment. This involves uploading the public certificate provided by the OBIE via that provider's APIs or UI if provided in Sandbox.

For the CMA9, this means that a single application requires the TPP to register their app 18 times (once per provider/environment combination). Therefore, the credentials will need to be stored and maintained for these 18 registrations.

No offline development

Currently, there is no solution provided to enable offline development. In the modern development environment, it's critical to be able to develop without internet access or relying on a remote service. At present, there is a dependency here.

Providing containerised versions of the APIs would solve this as the developer(s) would have the simple process of needing to only download those images once. After this has been done, they would be able to develop without network dependency/latency.

What needs to change?

The CMA9, TPPs and OBIE need to have a conversation around DX in order to:

  • improve the app on-boarding journey and credential management
  • enable offline (containerised) APIs for POCs/innovation

Ultimately, the barrier to entry is still quite high. It shouldn't matter whether it's a single developer or a team. The process needs to be looked at and ultimately streamlined. 

Why should the CMA9 care?

The main reason the CMA9 should look to improve the DX is that inevitably, a proportion of the developers who will be creating applications against the APIs will be their staff/colleagues.

As they move to push competitive and innovative offerings utilising the Open Banking APIs, it's key to be able to iterate quickly and enable the developer(s) to flow in a local environment for their day-to-day feature development. The added benefit is that the cost to implement competitive solutions will be reduced due to development time, which in return reduces the time to market.


In my opinion, Open Banking is a great initiative, and the hardest part of opening up legacy systems to these common APIs has already taken place. Moving forwards, the focus really needs to be on servicing "forgotten customers" and the DX. This will create a more enjoyable flow, maximising the capability to fail fast, quickly iterate and produce innovative solutions.