Placing the UK at the heart of the fintech revolution

13^th May 2015

In the Budget the Chancellor announced that the Government intended to “deliver an open API standard in UK banking”. For politicians and economists dissecting the 125 page report, this sentence probably didn’t stand out a great deal. But for those of working in the fintech space, these were potentially the most significant 8 words amongst them all.

What is an API?

API stands for Application Programming Interface. A developer will build out an API to allow one piece of software to communicate with another – like a pipe that other developers can plug into. They are integral to the way we experience the Internet and what powers the apps on our phones. For example APIs enable YouTube videos and Facebook “like” buttons to be embedded on third party websites. They are also how apps like Citymapper pull in real time transit data from Transport for London.

Its important to understand that APIs are built with controls, like valves in the pipe, to restrict access – for example by requiring user consent when personal data is involved. Across almost every sector APIs are proliferating as consumers demand greater control of their data and as innovators are able to deliver better experiences using it.

Why should banks build APIs?

When I log onto my bank account I can see all my transactions in one place. That data could be incredibly helpful to me. Today if I want to understand my spending habits better and budget more efficiently, there are plenty of apps out which could help. Similarly if I’m a small business managing my finances, reconciling what my bank already knows I’ve spent with my business accounts saves me a lot of time and work. Both experiences rely upon the software having direct access to the raw transaction data.

Some banks have built out APIs to enable this but they are not the norm and it is the banks, not the consumer, who decide which apps can use them. Instead most apps that do offer the ability for the consumer to upload their transaction data normally do so through a process called “screen scrapping”. This is a little like an automated screen shot where the consumer gives the software permission to log into their account without the banks’ involvement.

This process is not without its critics. Banks don’t like that it requires consumers to share their security credentials in order to work. The user experience can break down when the banks change the layout of their webpages. And finally there is a limit to what screen scraping delivers for the consumer: the user can’t vary the access the app has to her data, nor can she allow the app to send instructions back to her bank, for example to make a payment.

That last point is very significant. There are many more consumer problems, which an open API uniquely allows innovators to solve. Take mortgage and loan approvals. If there was a secure way for consumers to share specific elements of their transaction data (for example average monthly income) it could speed up the process and improve lenders’ ability to fairly judge risk. Take savings and investments. If data on the their performance wasn’t locked away and controlled by the bank in formats that are hard to use, alternative providers could offer consumers the opportunity to see precisely how their products compared.

Simply put open APIs would mean more choice for consumers as to the apps they can use to manage their money and provide a platform for new innovative services that make banking better for everyone.

What happens next?

The Budget was a little vague on next steps: the Treasury will work “closely with banks and financial technology firms to take the design work forward and will set out a detailed framework for an open API standard by the end of 2015”. I would offer four pointers for those discussions.

• Firstly, and mostly importantly: consumer protection. Our transaction history is sensitive personal data. Consumers must have control over who has access to this and how it will be used.

• Second: governance. Developers must meet high standards on security and privacy to even begin to offer these services to consumers. Similarly, banks must guarantee high standards for how their APIs will be maintained and the data which will be available.

• Third: access costs. Once built the marginal costs of access to an API for the bank will be low. However banks choose to recoup the costs of building their APIs that should incent innovation and not prevent consumers from benefiting from the value of their data.

• Fourth: competition. All banks should deliver against a minimum specification but should be free to offer enhanced services through their own API to drive innovation.

Note there is nothing technically challenging here, but success is dependent upon continued political will as well as all parties around the table focusing upon the ultimate consumer benefit. Indeed, whatever the UK decides to do, a new Payment Service Directive from Brussels will most likely enshrine the need for something like this in the coming years. This is an opportunity for UK consumers, banks and fintech companies to get ahead of the curve.