We all know that “Open Banking”, by which I mean a regulatory environment that enables third-parties to have access to banks’ accounts (with the informed consent of the account holders, of course) is on the way. Regulators around the world are looking at what is going on in Europe (where the regulators are forcing banks to open up to third party service providers) and what is going on in the U.K. (where the government has decided that open data in banking and open access to bank accounts is the best way to bring competition and innovation into the sector) and beginning to formulate similar strategies. Whether it will involve the security standards of the European Union or the access structures of the U.K. is beside the point: whichever jurisdictions you are in, open banking is on the way and you should begin formulating your open banking strategies now.
Why? Well, what sort of things might you learn about somebody if you have access to their bank account? All sorts of things, actually. For one thing, you would learn that they exist, assuming that stringent and expensive know your customer (KYC) regulations have been effective. If you are match.com then merely knowing that I am a real person and actually exist might be the most important thing you need to know about me. For another thing, you would learn how much they earn. If you are Nationwide thinking about granting the customer’s mortgage applications, then this could save an awful lot of form filling and delays and mistakes. For another thing, you might learn how much they pay for gas and electricity and car insurance and a great many other utilities paid for by direct debit. If you are a comparison website, a consumer organisation or a rival utility, then this information is incredibly valuable to you and my even result in a better deal for the consumer.
This is all going to happen. When it comes to open banking, the U.K. is a global case study. Within a few months, open banking will be a reality and there will be mass-market players with millions of customers participating in a radically new financial services industry. No more bilateral agreements to obtain the rights to screen scrape to aggregate consumer data and no more have to have customers log in to execute transactions.Allowing third parties to have access to bank accounts is what we now call “open banking”. We are talking about direct access here: not “screen scraping” by getting hold of usernames and passwords to masquerade as the account owner but through Application Programming Interfaces (APIs) that give access to bank systems. Just as when I log into a website and it asks for permission to access my Facebook account now, I will log into Facebook in the future and it will ask me for permission to access my bank account.
To understand how this is going to come about in the U.K. you need to understand the the U.K.’s unique open banking landscape, which I have to say is advanced by comparison to other jurisdictions. Way back in 2014, the Treasury published rather a good report on open data in banking. Then, in February 2015, they began a consultation process about the next steps and the chosen next step was to create an Open Banking Working Group (OBWG) to bring together relevant stakeholders through the Open Data Institute (ODI). These stakeholders, including industry bodies such as Payments UK and the British Banking Association (BBA) as well as representatives from a variety of financial services organisations, were expected to look at how to implement open banking in practice and come up with recommendations for the industry.
The OBWG report was published in 2016. It was really a holding document, setting us on a path to allowing access to the open data held by banks while leaving proprietary data alone. (I imagine the discussions about what data the banks consider "proprietary" and what data the banks consider "open" must have been rather convoluted.) The document set out a four part framework, comprising
- A data model (so that everyone knows what "account", "amount", "account holder" etc means);
- An API standard.
- A governance model.
- A security standard.
That last part, security, is critical. If people are going to start fiddling with each others’ bank accounts then we’d better be pretty sure that the identification, authentication and authorisation of the fiddlers is up to scratch. There are significant risks around this. I can paraphrase them easily as:
- Grandma sees a page that she thinks comes from from Age Concern asking for access to her bank account;
- Grandma clicks OK and accidentally grants access to Eastern European fraudsters or, worse still, investment bankers;
- Grandma’s account is looted.
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 the report pointed out they cannot. Hence requests for access can only come from organisations that have been registered previously with some sort of database or directory (we’ll come back to this point later on).
(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 Uninformed Consent lawsuits might make Payment Protection Insurance mis-selling look like a walk in the park, hence the comment from y good friend Izabella Kaminska at the Financial Times that “API is the new PPI”!)
A sound way forward on security is what the OBWG reported called contextual limitations. The permissions granted to third-parties (you can think of them as “tokens” given to the 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. Then if someone steals it, and they are not from Saga, they won’t be able to use it. And if they are from Saga, it’s only good for a few days.
Now on to the APIs.
Last year, the Competition and Markets Authority (CMA) published their “remedy” for more competition in the British banking sector. This included a requirement for the nine largest current account providers to make available to authorised third parties (i.e., TPPs):
Standardised product and reference data (by 31 March 2017);
With customer consent, secure access to specific current accounts in order to read the transaction data and initiate payments (by January 2018).
What’s more, as the remedy requires the access to transaction data and payments to be implemented using an open API framework, the U.K. had the banks fund “The Open Banking Implementation Entity” to develop the necessary APIs. These are called the “read-only” APIs as described in the OBWG framework and the “read-write” APIs that the CMA wanted in addition so that third-parties can instruct transactions.
Meanwhile… on 17th July, the U.K. Parliament ratified Statutory Instrument no.752 (2017) to transcribe the European Commission’s Second Payment Services Directive (PSD2) into U.K. law. In a rational world, there would be no need to develop Open Banking APIs for the U.K. because we would just use the APIs developed for use across Europe to implement PSD2 in a cost-effective and safe way. PSD2, however, does not contain any standards or standardisation process and there are no national competent authorities linked to PSD2 (note; competent doesn’t mean what you think it means in this context). However, there are other bodies who are working on standardisation to support implementation and the EBA is probably the place to start to try to understand what is going on since they were tasked with creating the Regulatory Technical Standards (RTS) on strong customer authentication (SCA) and secure communication (which isn’t really technical and isn’t a standard).
Regulatory Technical Standards on strong customer authentication and secure communication under PSD2
The SCA-RTS is not an API specification. Actually isn’t a specification of any kind. Oh, and it’s important not to confuse the EBA with the EBA, by the way. This is the European Banking Authority (EBA) based in London. The EBA based in Brussels is a different organisation.
"The Euro Banking Association (EBA) is a practitioners’ body for banks and other service providers supporting a pan-European vision for payments."
So let’s call that EBA-Brussels to distinguish it from EBA-London from now on (although the Commission is looking to move EBA-London to EBA-somewhere-else following Brexit). Last year, EBA-Brussels published a report on PSD2 and it’s impact that made some interesting observations about the practicalities of PSD2 implementation for Account Servicing Payment Service Providers (AS-PSPs), noting the need for at least a minimum standard for APIs in order to avoid a fragmented approach and that also that such a standard could enable value-added Open APIs with additional information and functionality available for TPPs. This makes sense. But who will actually do this?
The European Retail Payments Board (ERPB) has three expert subgroups working in the field. There is the ERPB-WG on APIs (i.e., the TPP to AS-PSP interfaces), the ERPB-WG on the identification of TPPs (since as noted earlier some form of directory will be needed) and another ERPB-WG on general issues. As I understand things, the identification is being built on eIDAS but I think I’m right in saying that there is only one “notified” eIDAS scheme at the moment so there may need to be some alternatives. I suppose the participants could put the directory on a blockchain but at the moment they are thinking about some form of centralised repository. Blockchain or database, none of this exists and I don’t know that anyone knows how it will all work.
"The Berlin Group, a-European payments interoperability coalition of banks and payment processors, is pushing a single standard for API access to bank accounts to comply with new regulations on freeing up customer data under PSD2."
Meanwhile, the Berlin Group API standardisation initiative set up by the major players in the payments industry has been putting together a framework for access to accounts to deliver the functions for confirmation of availability of funds, payment initiation service (PIS) and account information service (AIS) as set out under PSD2 (what is generally referred to as XS2A). The group is liaising with OBWG as well as CAPS, W3C and so on and its “NextGenPSD2” task force will be publishing its API standard (well, set of standards: the AS-PSPs will choose which of them to support) sometime soon so that payments industry participants can begin building new systems and services. There are, naturally, a few issues to be resolved around service definitions, data models, event handling, security levels, participant identification, authentication, messaging, architecture and so on but I’m sure these are minor details. Who knows what will emerge, but some people envisage REST APIs with ISO 20022 messaging (standardised by the Berlin Group).
Though there are differences in scope between the two regimes, consideration is being given to how open application program interfaces (APIs) being developed under the open banking initiative could be used to support access to payment accounts and data by PISPs and AISPs under PSD2.
Right now, then, in the U.K. we have the “read APIs” that are broadly equivalent to the APIs that will emerge from PSD2 to support the AI-PSPs implementing the AIS and the “read-write APIs” that are broadly equivalent to the APIs that will emerge from PSD2 to support the PI-PSPs implementing PIS. The read-only APIs were put out for public trial a while back and the first read-write API has just been released. It would be great if the European banks would just use the same APIs.
We are also building our own UK TPP directory separate from the TPP directory under development in Europe although these will presumably have to interoperate as some point (I did think that the TPP directory might actually be a valid use case for a shared ledger of some kind but in the UK the Implementation Entity is building database). So, to summarise: in a few months the U.K. will have all of these APIs in place for millions of customers. You can go to github and download the APIs to play with them already if you want to. This combination of regulatory framework, practical implementation and new competition is why it makes senses for bankers, regulators and technology providers in many different countries to take the time out to look at the European environment (which is separating banking and payments regulation) and the U.K. environment in particular.
I’ll finish by noting another recent U.K. development. The Bank of England has decided to allow non-banks to have settlement accounts and therefore obtain access to the payment infrastructure, meaning that PSPs that qualify for these new accounts will not have to use API access via a bank to instruct transfers because they will be able to do it themselves.
The widely-trailed move is expected to open up a competitive space which has long been the preserve of the UK's biggest incumbents, providing non-bank PSPs with direct access to the UK’s sterling payment systems that settle in central bank money, including Faster Payments, Bacs, Chaps, Link, Visa, and, once live, the new digital cheque imaging system.
This adds another dimension, and more vigour, to the U.K. financial services sector and I am hardly alone in thinking that it will lead to an incredible variety of products and services that will change the banking sector for good.