Standard approach

OK, so fair enough, I was a little disappointed. The Open Banking Working Group published its Open Banking Standard.

The Open Banking Working Group, which undertook a review last year at the request of the Treasury, is calling for information on banks’ products and customers to be more easily accessed by digital services, including comparison sites.

From Banks urged to share data so customers can shop around - FT.com

Right underneath the heading "Open Banking Standard", the document says that its goal "in publishing this Framework today is to enable the accelerated building of an Open Banking Standard in the UK". Wait, what? We went from a “standard” to “a framework to accelerate the building of a standard"? This is why I was disappointed, to say the least. I thought the document might set out some actual APIs so that that both banks, fintechs, regulators and entrepreneurs could plan new products and services but the truth is  it reflects the political realities of the pending complex “settlement” between banks, the regulators and others. It’s a holding document.

Here’s what I mean. Many people thought the document was going to say something along these lines…

The EBA DCSI three-part framework for PSD2 XS2A looks good so we’ll use that. The EBA can set the mandatory payment APIs. We will define a minimum set of non-mandatory payment APIs specific to the UK (to use, for example, PayM). We will also define a minimum set of non-mandatory non-payment APIs (i.e., the Treasury standards for Open Banking) specific to the UK but in consultation with relevant European bodies.

Now, I am particularly interested in the non-mandatory non-payment APIs, including those for Open Banking, because that’s where I think that the banks have an opportunity to become an essential platform. I was expecting to see a list of proposed APIs along the lines of…

DCSI_NMNP_UK_Adult ( Service Provider, Customer ) returns { YES, NO, INVALID_PROVIDER, INVALID_ACCOUNTHOLDER }

I'm not that interested in open data (e.g., ATM locations). What I'm interested in is customer transaction data, especially as it supports the more transactional APIs envisaged under PSD2. It would be crazy for banks to have to implement multiple infrastructures, so it's logical to create an infrastructure for access to customer transaction data that can also be used for transactions. To use an obvious example, working out how to get the Service_Provider token and the Customer token is actually pretty complicated. If we can figure out how to do it (evolving the security standards as we go, in line with SCA) so that customers can access their own transaction data to start with (and, of course, to grant that permission to third-parties) then we can have an enabling platform in place for PSD2 that ought to turbocharge the fintech sector, as well as the banks (as I wrote earlier this week, banks will be users of these APIs as well as providers of them).

Anyway, let’s move on, since the Standard did contain any APIs or even a framework for APIs, we can’t use it to start planning services right now. Let’s instead focus on the positives and look at what the document did. What it did set out was a four part framework, comprising

1. A data model (so that everyone knows what "account", "amount", "account holder" etc means);
2. An API standard.
3. A security standard.
4. A governance model.

None of these currently exist, so they need to be created. If we focus on the APIs, the document does note that thanks to the requirements of the Second Payment Services Directive (PSD2) and the General Data Protection Regulation (GDPR), many of the APIs will need to be built anyway. Hence co-ordinating the APIs in this way will actually save the industry time and money and obviously we all agree with this. But it looks as if we’re going to have to wait before we start prototyping and testing any actual apps for this stuff.

Of particular interest to me (and to many of our clients, I imagine) is the relationship between token provision and strong customer authentication (SCA). What are the flows going to be? So the document didn't really get interesting for me until page 48, where Figure 7c.1 sets out the authorisation flow: third-party requests access to data, customers authenticates with bank (under provisions of SCA, presumably), customer is returned to third-party provider. Sounds easy, doesn't it? It isn't. As the Standard explains, there a significant risks around this. I can paraphrase them easily as:

1. Grandma sees a page from Age Concern asking for access to her bank account;
2. Grandma grants access to Eastern European fraudsters or, worse still, investment bankers;
3. Eastern European fraudsters or investment bankers loot Grandma's account.

How does Grandma or, for that matter, anyone else know that who they are granting access to and what they are granting access for actually corresponds to what is on their computer screen? Well, as Figure 7c.3 indicates, they can't. Hence requests for access can only come from organisations that have been registered previously with someone, in some way. I guess they are thinking about registering with an Open Banking Authority or something like? I might also point out that where the document talks about Grandma giving “informed consent” I automatically shiver. Having been involved in a couple of previous projects for the European Commission to try to explore what “informed consent” actually means and how the general public might be supported in giving it, I can tell you that it is a minefield (I can imagine the lawsuits might make Payment Protection mis-selling look like a walk in the park.)

I agree very strongly with the document about contextual limitations. The tokens granted to third-parties should be circumscribed. They should be for a fixed time, for a fixed purpose, for a fixed provider. So if I give Saga permission to look at my bank account, that permission should be for (say) 7 days maximum, read-only and only for transaction data.

There is some technical detail in the Standard. It says that APIs should use JSON/REST, for example.

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.

From Celent Banking Blog » The UK open banking API framework – more questions than answers?

xxx

The data accessed via an open API may be closed, shared or open data.

xxx

Permission to access data will only be granted on the basis of informed customer consent,

The document calls for the launch of, in a year's time, of a

tightly scoped Open Banking API, enabling select, read-access, open data use cases

Now, let me stress that I was not party to any of the discussions, and I am not breaking any confidences by saying this, but I imagine the discussions about what data the banks consider "proprietary" and what data the banks consider "open" must have been rather convoluted.