The UK open banking API framework - more questions than answers?

This week the Open Banking Working Group (OBWG) published its framework for the UK Open Banking Standard. The framework seeks to create:
• An open API for data that is shared, including, but not limited to, customer data, and
• An open data API for market information and relevant open data

Secure, publicly accessible Web APIs have been around for more than ten years in the financial services sector. Many popular eCommerce platforms employ APIs to increase adoption by exposing various features of the underlying platform to third-party application developers. These include PayPal, Stripe, Authorize.Net and LevelUp. Payment APIs have grown by almost 2,000% since 2009, with Financial APIs growing at more than 470% during that time.

Banks embrace APIs to modernize and streamline back-office connectivity, especially for customer-facing digital channels. However, except for a smattering of bank API hackathons featuring mock customer account data and the well-publicized external APIs made available by digital bank Fidor, banks are reluctant to publish open, external APIs for customers or third-party to access financial data. Two major government initiatives are forcing their hands.

The account access provisions of PSD2 require Euro Area banks to open access to customer information where third-parties have the explicit consent of the customer. The UK HM Treasury Open Banking initiative strives to improve competition and consumer outcomes by giving customers the ability to share their transaction data with third party providers (3PPs) using an open API standard for UK treasury.

The UK government established the Open Banking Working Group in August 2015, giving it the remit to design a detailed framework for the development of an open API standard in the UK. The detailed framework was published this week after review by the HM Treasury.

Sifting through the 128-page report, several key issues remain to be addressed:

Governance: The report recommends the creation of an independent authority to oversee the development and deployment of the Open Banking Standard. As co-chair of the OBWG, is the Open Data Institute vying to become that independent authority? IMHO, the banking industry doesn’t need yet another standards body. Why not engage the expertise of an existing organization like the International Organization for Standardization (ISO), the governance body of the popular ISO 20022 standard, to ensure an internationally agreed upon approach with the involvement of a diverse group of stakeholders?

Data Standard: The report recommends that existing standards, datasets and structures be reused where possible but also mentions further investigation as to whether the Open Banking Standard will need a separate reference data model. I hope that the OBWG examines the widespread adoption of the ISO 20022 financial industry message scheme and its contribution to standardizing and simplifying financial data exchange worldwide.

Data Protection: The report states that banking customers (individuals and businesses) need to understand their responsibility for informed customer consent and ensuring their data is protected. This is problematic in light of continued social engineering banking losses, an emerging global fraud threat. The report acknowledges that it is likely that cyber-criminals will specifically focus on the open API as a new attack vector. Consumer education needs to be the responsibility of the Open Banking ecosystem: Banks, 3PPs, government agencies, and consumer watchdog groups.

Developer Resources: The recommendation that a central developer hub be created to support developers is a seemingly practical idea. However, there are a number of leading API platform providers and no universally accepted RESTful API design methodology, which will lead to a scramble by the proponents of RAML, SWAGGER and Apiary.io to be the provider (and language) of choice for creation of common open APIs and developer sandbox.

Implementation Schedule: The report outlines a multi-year release schedule with the first release to be completed within 12 months of the report’s publication—February 2017. This seems to be very aggressive considering that detailed design specifications are not yet complete, nor has an independent authority been selected to oversee development of the standard.

Monetization: Respondents to the February 2015 Call for Consultation estimated the cost of developing an open API standard would range from “negligible to tens of millions of pounds.” At first glance the Open Banking initiative seems to provide all of the benefit to fintech firms with all of the cost shouldered by UK financial institutions. Celent anticipates acceleration of bank/fintech partnerships aimed at creating differentiated value propositions.

Interoperability: Banks and solution providers are closely watching the intersection of the UK Open Banking initiative and the account access provisions of PSD2. There is significant overlap between the two initiatives and industry participants hope that they will be joined up, but for now the HM Treasury is actively seeking to take the lead with its aggressive implementation schedule. Interoperability across geographies and sectors fosters sustained innovation and broader participation by third parties, contributing to the UK Treasury’s goal of improving competition and consumer outcomes.

The recommendations for implementing the Open Banking Standard will be carried out by the Open Banking Implementation Entity. Celent analysts are watching developments closely and assessing their impact across our coverage areas. We welcome your feedback—what are your thoughts about opening up customer banking data to third-party providers?