Working with the Open Banking APIs

Jan 23 · 3 min read

Open Banking has been up and running for a year now, and while there’s plenty of discussion about how many businesses are (or aren’t) building for it, few talk about what it’s actually like trying to build something using its APIs. We asked Andrey, one of our developers integrating the Open Banking APIs, to let us in on its secrets.

What is using the Open Banking APIs like for a developer? Well, having spent some time playing with model banks (ones that mimic the behaviour of real institutions), I can say it’s no cakewalk.

There are two types of Open Banking APIs. The Open Data API provides information about branches, ATM locations, and bank products. The Read/Write APIs, in turn, include ‘Account and Transaction’ and ‘Payment Initiation’ APIs. While these names tell you what to expect, it is confusing that there are already several versions of the Accounts and Transactions API (from 1.0 to 3.1).

It’s worth saying at this point that if you’re a developer who wishes to start using Open Banking APIs, you won’t be able to do so unless you’ve obtained a license from the Financial Conduct Authority. This is a long process on its own and could take several months.

Once you have a license, you can’t start using the banks’ APIs right away. First, you must get access to Open Banking Directory and create your first ‘software statement’, which includes two pairs of security credentials, a private key and a certificate, and a redirect URI. The pairs are called ‘transport’ and ‘signing’, and serve different purposes. Then you must use that software statement to go through the onboarding process with the bank you want to use. The result is that you get another set of security credentials to access the bank authentication server. Finally, you use these new credentials to request an access token with a certain scope — whether that’s accounts or payments — that you get from a user once you’ve obtained their consent to access their financial data. You then receive a second access token, which internally we call an ‘access token with consent’ for clarity. Only at this point are you ready to query the resource server.

For a conventional developer, your usual API consumer, this is an overwhelming process.

Using the Open Banking APIs is further complicated by the fact that all the responses from Open Banking resource servers are paginated, and you don’t have a control over how many items are present on a page. Having looked at other online banks’ APIs, it seems to me that such pagination is not typical. This matters because it affects how you structure your code. Consider, for example, retrieving transactions for a large period of time. The Open Banking standard doesn’t guarantee the atomicity of the operation, meaning that while you’re retrieving some middle page, new records could have been inserted into the first. The data is not guaranteed to be sorted, so you have to do this on your end. Trickier still is that any request for the next page could result in an error for a wide range of reasons, from an expired access token to exceeding a rate limit.

From spending some time with the Open Banking APIs, it’s clear to me that they are significantly different from those of new, online-only banks such as Monzo or Starling. In many ways, the Open Banking APIs reflect the incumbents from which they’re drawn. Using them is complex and complicated, and if you’re a regular software developer, you probably won’t want to go to those lengths. If we want developers to help Open Banking achieve its goals by building new products, they need something easier to work with. This is what Banked will provide.