At the back end of 2016 I was approached by the Open Banking Implementation Entity (OBIE) as an independent contractor to take on the task of building the UK open banking standard.
The initial scope was to meet the requirements of the UK’s Competition and Markets Authority (CMA) Order, which required the CMA9 (AIB, Bank of Ireland, Barclays, Danske, HSBC, Lloyds, Nationwide, Natwest and Santander) to provide open APIs for their retail bank accounts. Specifically, the CMA9 were mandated to implement their APIs in accordance with the standard which was being defined by the OBIE.
Whilst the CMA Order set out several requirements, it was not prescriptive and left much to interpretation. It did however specify that the standard had to be aligned with the PSD2 Regulatory Technical Standards (RTS), which was still in draft at the time.
Turning challenges into opportunities
The overall intent of both the CMA Order and PSD2 was clear – to provide a secure framework which allowed regulated Third Party Providers (TPPs) to offer innovative new financial products and services, thereby giving personal and business customers a better deal than they were currently getting.
However, when we started drafting the standards, we encountered several challenges, some based on circumstance and some on perceptions and fears (many of which have proven to be unfounded):Firstly, the requirements were unclear, since the regulations were either not sufficiently specific or still themselves in draft.
Secondly, banks and TPPs had opposing views of the scope of these APIs. Banks wanted to do the bare minimum, as they were concerned about the cost and complexity of building their APIs and feared that TPPs could be competitors who were being given a ‘free ride’. TPPs, however, wanted the richest possible functionality, so they could deliver even more innovative and valuable services.
Thirdly, there was very little time. The standards had to be published in August 2017 and the CMA9 were due to have their APIs live by January 2018.
Lastly, this had never been done before and there was no template for running a programme like this. We had to design everything from scratch, including the processes and tooling used to draft, consult and publish the standards.
Rather than trying to design the standard behind closed doors, I realised the best way to address these challenges was to co-create it, as an industry, with the people (banks and TPPs) who were going to build it and build on it. This would also realise a massive opportunity to get their buy-in from the start, which would in turn incentivise and speed up implementation.
Co-creating the standard
I started by setting up and running a series of workshops, inviting product managers, architects, engineers, and regulatory specialists from across the industry – banks, TPPs, technology vendors and trade bodies.
We leveraged existing standards (e.g. ISO20022) and worked collaboratively with other standards bodies (e.g. the OpenID Foundation) to help define the Financial Grade API (FAPI) security profile.
The initial focus of the workshops was to define the use cases and requirements which would enable these use cases. We were then able to turn the requirements into either design decisions or product features.
Design decisions were written up, with a description of each option and the pros, cons and implications of each option. Product features were turned into draft specifications. Decisions and drafts were tabled at the next workshop to get feedback from the industry and inform the next iteration.
When the decision/draft was ready for a final decision, these were tabled at the Technical Design Authority (TDA) which I chaired. The TDA had clear terms of reference which defined the membership (a mix of banks and TPPs) and rules around voting. Once approved by TDA, each version of the standard was then tabled at the OBIE steering group (IESG) for final approval.
This was a massive collaboration effort and we worked very hard to remove politics and self interest from any discussions. Whenever I brought the conversation back to ‘what is the right thing to do to enable this customer use case’, it became much easier to get consensus.
I also fought very hard to leave any ‘mandate’ for implementation to the regulators (i.e the CMA and/or FCA). My mantra here was that the standard should be an enabler and not a limiting factor. So, for example, if there was a useful field in the API response, but there was no clear regulatory requirement, this would be added to the standard as ‘optional’.
Open by design
Between January 2017 and March 2021 I chaired over 200 workshops, attended by over 2,000 individuals across the industry. Each workshop was free to attend (either in person or online) and most of them were recorded, with the recordings made publicly available.
Every decision and every draft specification was published in Confluence, and all stakeholders were encouraged to provide feedback on the same platform. All of this, including all feedback, was also made freely and publicly available. This was deliberately to ensure complete transparency and remove the chance for any one firm or person to influence the standard to suit their own agenda.
Critically, this approach also gave everyone in the industry (banks, TPPs and technology providers) a level playing field and as much time as possible to develop their solutions.
In the same timeframe, I chaired over 200 TDA meetings. The TDA membership and voting process, which was set at IESG, consisted of a mix of banks (CMA9 and challenger banks) and TPPs, where each firm had one vote. When design decisions or draft specifications were tabled at TDA, I always sought to gain consensus. If not, then the majority decision was carried. While I held a deciding vote, not once in over 200 meetings did I ever exercise this. All TDA voting on decisions and drafts was also made public, as were the final IESG approvals of each version of the standard.
Lastly, all final versions of the standard have been published under the MIT open licence – the most open version of an open licence available – to reduce any possible obstacles for firms looking to build their solutions using these standards.
In summary, I cannot think of a more open and transparent process to design and approve a standard.
What’s next
I’m incredibly proud of everything I have accomplished over the last 4 plus years in leading the development of this standard. But mostly I am proud of all the individuals who have together built this – from the OBIE, the banks, the TPPs, technology vendors, trade associations and other standards bodies (and even the regulators). You know who you are, and you should also be proud.
The best testament to all of you is that almost all other markets looking to implement open banking, or indeed open finance, are copying what we have created together.
Thank you!
