Earlier this year we were delighted to be part of the Consult Hyperion webinar on Request to Pay. A common thread in post-event conversations that followed was an interest in the parallel developments of the UK and European flavours of Request to Pay and how they might work together. With the launch of the European version on June 15th, we thought it an ideal time to signpost the bigger differences.
I recently had the pleasure of “attending” the LendIt Fintech – Europe 2020 virtual event. Now, much of the content covered banking services for Small and Medium Enterprises (SMEs), an area that personally I’m not particularly familiar with, but one that is gaining more focus in the news of late. One thing that struck me was the potential disruption of traditional business banking brought about by open banking.
In his new book “Digital Human“, Chris Skinner sets out a straightforward vision of the bank of the future. He says (I paraphrase slightly) that the back office is about analytics, the middle office is about APIs and the front office is moving to smart apps on smart devices. I was thinking about this in an open banking context, and it gave me an idea for a useful way to help people think about the impending change in retail financial services in general and retail banking in particular. Let’s start from the traditional manufacturing/distribution model of retail banking that we are all familiar with and remember the broad economics of that model. On a global basis (these are the McKinsey version of the figures, but others are similar), it is distribution that takes the lion’s share of the profits and makes the better return on equity (ROE).
So now let’s rebuild that model for an open banking world using Chris’ back, middle and front office structure and think about the key technologies that will be transforming the businesses. I’ve invented the word “packaging” to describe the additional essential process that is needed to complete what we call the “Amazonisation” of banking, whereby products are manufactured as API services and distributed throughout the consumption of API services. This gives the three part model that Chris describes a practical technological backbone to make it work.
What we don’t know, of course, is how this model will redistribute ROE. How will banks and “challenger banks” (we prefer the term “niche banks”), non-banks and neo-banks respond to the split of manufacturing and distribution that the new “packaging” layer (again, not sure if that’s the right term, I just couldn’t think of a better one) brings? That’s obviously a key question and one that is pretty important for organisations who are planning any kind of strategy around financial services in general or payments in particular. Since this includes many of our clients, we spend a lot of time thinking about this and the connection between technological choices that are being made now and the long-term strategic options for organisations.
Consult Hyperion took part in a recent American Banker Open Banking “Bootcamp” (a two-part webinar) on the topic. My colleague Tim Richards and I were able to explore some of our ideas and draw on some of our practical experiences with bankers, suppliers and other practitioners. It was fun to take part in it and we really enjoyed it because we were able to learn as well as to share. I mention that webinar here because as part of the bootcamp, Mark Curran from CYBG (The Clydesdale Bank, Yorkshire Bank, “B” Bank Group and now also Virgin Money) set out a very clear high level view of the three strategic options available to retail. We think it’s useful to share them here: the “traditional” bank, the banks as a platform (think Starling) and the bank as an aggregator (think HSBC and Citi).
If, as many people think, it turns out that ROE will remain higher in distribution then the commoditisation of the manufacturing function (as it turns into a “utility”) may well threaten some of the incumbents, because they will not be able to adjust the economics of their manufacturing operation quickly enough to stay in business! This may sound like a radical prediction, but it really is not.
The reality for many banks will, of course, be more of a mixture of these approaches, but you can see the point. The decoupling of the manufacturing and distribution means that banks will have to make some important decisions about where to play, and soon. We’ve already seen how some banks (eg, HSBC) have moved to exploit the aggregator strategy and how some banks (eg, Starling) have moved to become platforms with rich app stores. But what we think may be under-appreciated is the extent to which the traditional bank can develop the packaging process not to shift to one of these strategies but to make itself more efficient and to improve the time-to-market for new products and services while keeping the costs of IT infrastructure under control.
In other words, it makes sense for banks to amazonise themselves.
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:
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.
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.
Subscribe to our newsletter
