Towards an Open Banking API Standard

with 2 comments

Disclaimer: I am a member of the Open Banking Working Group (OBWG) and was involved in drafting the OBWG report. However, the thoughts and opinions presented here are strictly my own.

The OBWG’s report was published yesterday with the somewhat misleading title The Open Banking Standard. We’re a long way from a standard but this report is a significant step along that path. Its purpose is to lay out a roadmap for defining an Open Banking API standard that can achieve widespread adoption, and to put forward some strawman proposals, intended to generate discussion of their merits and weaknesses, with the objective of generating new and better proposals.

The OBWG’s work follows on from the Fingleton report, which looked at the potential benefits of banking APIs and open data, and HM Treasury’s public consultation on data sharing and open data in banking.

The OBWG was convened with three core objectives:

  • Deliver a framework for the design of an open API standard in UK banking focussing on personal and business current accounts;
  • Evaluate how increased levels of open data in banking can benefit consumers, businesses and society; and
  • Publish recommendations in a paper by end of 2015 outlining how an open API standard can be designed, delivered and administered, alongside a timetable and implementation roadmap for achieving this

It’s important to note that this initiative is separate from – and has a wider scope than – PSD2. However, I would predict with a high degree of confidence that the functionality required to fulfil PSD2’s requirements will form part of the Open Banking API Standard, and I would not be surprised if the UK implements PSD2 by mandating compliance with the Open Banking API Standard.

One of the key challenges in coming up with such a standard is to figure out how banking APIs can be opened up to third parties while ensuring that consumers are adequately protected against fraud and banks aren’t unreasonably held liable for third parties’ failings. Currently, banks control the technology channels that their customers use to access their accounts electronically. Online banking is through the bank’s own website; mobile banking is through the bank’s own app. Liability for any losses rests with either the bank (if their security proves inadequate) or the customer (if they fail to take the necessary security precautions). Opening up banking APIs and granting access to third parties complicates that picture and banks are understandably wary.

The proposals presented in the report comprise a combination of provisions (including an OAuth-based authentication and authorisation model, and vetting and licensing of third parties) that represent a compromise somewhere between completely open access that would allow even hobbyist programmers to create apps that connect to banks’ APIs, and a overly-restrictive regime with requirements or costs that are too onerous for finch innovators and startups. One aspect that I’m a particular fan of is the idea that API functionality should be permissioned atomically, and that the security standards to which the third party will be held and the scrutiny to which they will be subjected should be commensurate to the level of access they wish to obtain. For example, a startup wishing to offer a personal financial management solution, which requires “read-only” access to accounts would be subject to less onerous requirements than a company seeking access to instruct payments from their customers’ accounts.

I have set up a mailing list to facilitate discussion of the report and future developments in this space. Instructions on how to join the list can be found here.

Fundamentally, I believe that the UK fintech sector will benefit hugely if we can make rapid progress towards an Open Banking API standard, and I believe that there’s an opportunity for the UK to take a leadership role, in the same way that it did in information security standards, with the adoption of BS7799 as ISO27001.

It’s entirely possible that neither the banks nor fintech innovators will be entirely happy with the report’s proposals. If so, then I think we’ve done a good job. Personally, I think it’s a significant step forward and I hope to remain involved at the next stage of establishing an implementation entity to take the concept forward.

Written by jackgavigan

February 10, 2016 at 5:28 pm

2 Responses

Subscribe to comments with RSS.

  1. This is certainly welcomed news as a smaller fintech app developer. The current workflow depends on a combination of third parties to provide the missing banking plumbing.

    I’ve used Plaid as a read API for ACH credentials and access to end users’ transaction streams and Stripe for payment processing.

    I look forward to a future of native, reliable APIs. It simply seems to valuable to never exist.

    Ben peress

    February 10, 2016 at 8:37 pm

  2. Reblogged this on aainslie.


    March 25, 2016 at 12:04 pm

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: