The UK’s Competition and Markets Authority (CMA) has published its report on the retail banking market. It says, that “the timely development and implementation of an open API banking standard has the greatest potential to transform competition in retail banking markets”. I can’t say that I read all 766 pages, but given that I think that account switching is waste of time and money, this did strike me as the most important “remedy” (as they call it) in the report.
One of the CMA’s key measures is to make high-street banks adopt a digital standard called “open banking” by 2018.
From Competition watchdog’s high-street banking probe disappoints — FT.com
By 2018? I can hear your jaws hitting the floor from here. That’s 15 months from now, which is a dog decade but a core banking weekend. 2018?? This is correct. I heard the chap from the CMA talk about this on Radio 4. I got to talk about it on Radio 2 because I’m all about the mass market and the man using the Clapham ISP.
Vanessa discusses the Open Banking Programme, witnessing the birth of a sibling, life after the London riots and the man who buried himself underground for three days.
From BBC Radio 2 – Jeremy Vine, Open Banking and London Riots
I was in the first segment, about Open Banking. The second segment, about a celebrity chef’s wife giving birth made me feel sick and so I didn’t listen to the last segment about riots. Anyway, on Radio 4, the head of the CMA was saying (and I’m paraphrasing from memory) that consumers will be able to use a currently non-existent mobile phone app to connect with a currently non-existent interface at their bank according to some currently non-existent standards in order to get recommendations from some currently non-existent big data cloud thingies that will slurp up currently non-existent standard format bank transaction data and analyse it to suggest a more cost-effective current account. By 2018.
I think that in order to understand what might actually happen on the ground in the UK, you need to imagine what will happen at the crossing of three streams.
The first stream is the PSD2 provisions for APIs access to payment accounts. As you may recall, these include a set of proposals that are due to come into force in 2018. A group of those proposals are what we in the business call “XS2A”, the proposals which force banks to open up the aforementioned APIs to permit the initiation of credit transfer (“push payments”) and account information queries. Even at a pure compliance level these PSD2 regulations pose significant questions for the structure of the existing payments industry. Straight off, an open payment API allows a third-party – let’s say a giant internet retailer at a browser near you – to ask consumers if they’d mind permitting direct account access for payment. It won’t be too hard for these organisations to find some incentive for customers to do this and once permission is granted then the third-parties can bypass existing card schemes and push payments directly to their own accounts. Meanwhile the account information API allows third-parties to aggregate consumer financial data and provide consumers with direct money management services. It’s not hard to imagine that these services will be able to disintermediate existing financial services providers to identify consumer requirements and directly offer them additional products such as loans and mortgages.
This, you might think, could be a bit worrying for banks and payment schemes – and you’d be correct. Unless they take action the banks will see their customers intercepted and a great deal of their cross-selling opportunities will disappear. End of the world stuff? No. Generally speaking these changes (which are all about more competition) are good for the banking industry and for end consumers, and it doesn’t have to be carnage among the existing incumbents, if they’re smart enough to embrace the opportunity. One way of thinking about this change is that it breaks up existing payment workflows. No longer is a payment simply a request in and a response out; now bits of the internal payment workflow – authentication, risk management, authorisation, tokenisation, rewards programs, key management, etc, etc – can be externalised through APIs. And one thing we know about APIs is that when they’re made available the generations of smart developers out there can do things we can’t even imagine, let alone build. The roadmap to the PSD2 APIs is in the hands of the European Banking Association (EBA) which has been tasked with developing the Regulatory Technical Standards (RTSs) for that access. They have just published the RTS on strong authentication, which you might see as a prerequisite to practical API use.
As expected, the RTS do not provide us with technical specifications that one can actually implement. Additional work by ‘the industry’ is required
From EBA RTS: Three key business implications for bank decision makers
So, as our good friends at Innopay note here, RTSs are not really technical, and for that matter they’re not really standards in the sense that I would mean either, but suffice to say that there is a framework for open banking coming together at the European level.
The second stream is Her Majesty’s Treasury’s push for more competition in retail banking. This led to the creation of the Open Banking Working Group (OBWG), which published its report earlier this year. 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”. So it’s not really standard either. I thought the document might set out some actual APIs (preferably in line with the EBA RTS) 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.
I’m not that interested in open data (e.g., ATM locations) and not that excited by being able to download my bank account as a spreadsheet that I can upload it to Money Supermarket . What I’m interested in is transactions and transaction data, especially through 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 OBWG access to customer transaction data that can also be used for XS2A transaction initiation and account information services. Despite the title, then, the OBWG report is a holding document, setting us on a path to allowing access to the open data held by banks while leaving proprietary data alone. 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. But let’s move on and assume that my transactions are considered open data and that I want to share them with third-party service providers. Since the report did contain any APIs or even a framework for APIs, we can’t use it to start planning services right now, but we can focus on the positives and look at what the document did.. What it did set out was a four part framework, comprising:
- A data model (so that everyone knows what “account”, “amount”, “account holder” etc means);
- An API standard.
- A security standard.
- A governance model.
None of these currently exist, so they need to be created. If we focus on the APIs, the document does say that, as I have noted, that because of PSD2 (and the General Data Protection Regulation, GDPR), many of the APIs will need to be built anyway. Hence co-ordinating the APIs will be a near-term priority.
The third stream is the CMA report that triggered this blog post. This envisages APIs to improve competition in retail banking by focusing on the use of APIs to obtain access to personal data that can be shared with third-parties to obtain better, more cost-effective services. Hence the comments about the mobile app that will get you a better current account. Now, I identity these APIs as being congruent with, if not actually being the same as, the PSD2 AISPs. So if we gather to together these streams and try to integrate a picture of where we might go next, and we draw the mandatory consultant’s 2×2 matrix to hep us think through the possibilities, I think we end up with a rather interesting and useful way of thinking about the cross of the three streams. I’m particularly drawn to it because it gives me a way to locate the digital identity APIs that I think are so crucial to the future of banking.
I think this is a useful diagram. The Digital Identity APIs will not be mandatory, but they may be the key way for banks to stay in the loop in the new economy as the mandatory APIs allow banking services to be provided by third parties. Interesting, and I’d appreciate your view on this. Anyway, there’s one obvious point to mention here and that’s security. Since banks do not currently offer these APIs and they are going to have to knock them up pronto, the potential for error is vast. Yet banks simply cannot take any risks with these interfaces.
APIs (application protocol interfaces), which are a major cornerstone of the CMA’s plan for banks to share consumer data, can also provide an easy route for attackers if not properly secure.
From Funny story, this. UK.gov’s ‘open banking app revolution’. Security experts not a fan of it • The Register
Word. But since neither the APIs, nor the security architecture, nor the practices, procedures and audit mechanism have been defined, it is simply impossible to say whether the UK OBWG implementation is secure or not. Hence I suspect that the way forward for most banks will be to expose a limited set of APIs to begin with by focusing on a manageable customer segment (not the general public) and then get working on stress testing and penetration testing. In fact, some banks have already begun to experiment in this area.
Wells’ tiptoeing into open APIs by offering them to commercial customers is typical of banks, which see such clients as the test case. Consumer applications hold the greater opportunity, but also carry more risk given cybersecurity and data issues.
From The Drumbeat for Open APIs Is Getting Louder | American Banker
I can tell you from personal experience (Consult Hyperion runs a very big penetration testing programme for one of the world’s biggest banks) that it takes a fair amount of time and money to get these kind of interfaces to the point where they can be exposed to the public, hence I am somewhat sceptical that they will be ready for action a mere 15 months from now.
