Open Banking in the UK; a disaster in the making?

02 July 2018


Adoption of open APIs by TPPs (third party providers) and the development/implementation of compelling customer facing services is not happening due to poor authorisation journeys implemented by banks, and the limited data available on their API platforms. The hype generated by a range of speakers pointing to a utopia where these factors don’t exist increases the likelihood of disappointment when the reality is understood.

Payment Initiation / PISP

When the the CMA Order went live on 13/1/18, aside from the banks, there were no PISP authorised TPPs, there remain very few today, and there is no sign of a customer (PSU) facing service using APIs available on the open market. The question is why, the answer is simple - the authorisation journeys.

Under the OAuth2-based API flow which forms the basis of the Open Banking Ltd (OBIE) design, once a consent is formed between a PSU and a TPP, the PSU is redirected to the bank (and whatever solution they provide) where they must authorise consent. The API design is standardised, but the authorisation journey that the PSU then goes through is not. Some banks (e.g. Starling) have taken a minimal approach, relying on their own app and (quick and easy) biometric authentication, followed by a display of the consent object with the option to authorise. This journey is automatically invoked, familiar to the PSU, highly secure, and (most importantly) simple to follow. It adds minimum friction but not at the expense of security and control.

Conversely, the implementations of the redirect authentication by the CMA9 have shown poor customer experience (UX). TPPs have no control, but this will impact the view customers have of their applications by association. Multiple steps, requirements to recall opaque user IDs and static passwords / memorable words, needless repetition of the consent object, reliance on web journeys and the like all feature. These are worse for the customer than the biometric approach, and are far more vulnerable to phishing and other security risks. The idea that increased friction in the journey means a reduced likelihood of fraud is a fallacy.

From the TPPs’ perspective they are faced with a choice; do they adopt API-initiated payments in the knowledge that there will be significant customer drop off due to the increased friction versus using a digital card journey as in Apple or Google pay, or do they err on the side of caution, and assume that the loss in customers will outweigh the fees of card-based payments? Every TPP spoken to so far has taken the latter approach.

One response to this has been to benchmark drop off rates on banks’ API platforms against drop off rates on similar journeys which rely on screen scraping, or on payments initiated through their web portals. This is a fool’s errand. In both cases the banks have a captive audience, with no option but to accept whatever UX is put in front of them, otherwise they won’t be able to access the banks’ services. The banks care little for the drop off rates experienced by TPPs, and if anything will be happy to see them, as it will increase the likelihood of customer retention on their own channels, and the continuation of their market dominance that the CMA Order sort to address. If the status quo continues, both aims of payment initiation services developing, and an increase in competition as a result will have failed, partially as a result of design decisions taken by the very organisations subject to the Order.

Account Information / AISP

A previous post explained challenges faced as a result of the back of immutable transaction IDs. The points remain, but in the meantime, a survey of current and prospective third parties has taken place. Responses to the challenge vary from the application of proprietary (to the TPP) IDs, to acceptance of the likelihood of issues, to a refusal to use any service without this essential feature.

The issue is challenging from both technical and business standpoints. If the TPP is offering an accounting application, the danger of transactions appearing twice (pending and booked) or changing means that the user could see wildly different account balances. If this data is to be used to offer lending products, a very high level of surety is required around balances and cash flow, so the consequences of a lack of reliability and traceability kill the business case. This is also the case with prospective credit rating generation, and risk analysis. One respondent stated that the lack of reliability of the data necessitated an increase on the risk rating to be applied by an algorithm and a consequent additional margin, meaning a direct impact to the customer in increased cost of product.

Common to the feedback has been significant concern, a recognition of the need for potentially unreliable workarounds in the short term, and of the potential inefficiency of consistently having to pull and analyse complete data sets to perform any business function. Additionally, feedback was given that the absence of immutable IDs would prevent the use of an API using this design for some, if not all of the respondent’s business cases. A change request has now gone to the CMA9 for review, so this very unfortunate feature of the AISP implementations may yet change. In the meantime it is severely limiting development of compelling use cases..

Combatting the hype

Anyone with a LinkedIn account will see several articles a day extolling the virtues of open banking, and the potential it has to revolutionise behaviour in retail banking. Here are some examples from the past week;

There is no coverage online or in print, of the challenges elucidated above, which dictate whether open banking will take off. If these barriers are not overcome, then those building services argue that they simply won’t adopt the open APIs which are mandated under the regulatory regimes. Focussing on comment from traditional spokespeople - high level execs, columnists and consultancies - is part of the problem. Most of these have no direct experience of the ecosystem, but all will recognise that speaking positively about utopias which may never exist will have a positive effect on the market’s impression of them and the organisations they represent. They are just building hype around possibilities that may never result, and, should open banking turn into a white elephant, the disappointment will be even greater as a result of the hype they’ve built.

For example, PwC recently delivered a report on open banking - Open Banking market could be worth £7.2bn by 2022: PwC - PwC UK. Some notable points raised;

  1. The principle growth areas are projected as account aggregation, analytics of expenditure and financial product comparisons. This is difficult to understand given that none of these areas is new - in fact the information is being delivered differently - that is all that has changed. And in most cases (relative to challenger banks) the data delivered is very limited, preventing innovation on these pre-existing services. The major market comparison engines pull richer data through a combination of private means and screen scraping, and have made clear that open banking APIs will not replace this in their current form.
  2. ‘The consumers most likely to share data tend to be young, urban-dwelling, high earners who are comfortable using technology and multibanking’. - sort of stating the obvious - most people in the UK are urban-dwelling, and open banking can only be accessed using some form of tech platform. PwC think account aggregation is important - you can’t use this unless you ‘multibank’.
  3. “Open Banking is a potential game changer for individual and corporate consumers. It provides an opportunity to transform the public’s interaction and everyday experience with the financial services industry. But there are still many ‘hard yards’ to travel. Few disruptive propositions have been developed so far. This is unsurprising given that since the launch of Open Banking in January it remains unclear who needs to get an account information licence or a payments handling licence and how these licences may change in the future.”

It would be interesting to know whether the API specifications were reviewed for this report. The lack of disruptive propositions has nothing to do with confusion around who needs an AISP/PISP licence - its due to factors such as;

  1. A lack of rich data or functionality on the account information APIs,
  2. A regressive method coupled with very poor authorisation journeys on the banks’ platforms,
  3. Technical challenges such as that posed by a lack of immutable transaction IDs’
  4. The absence of any bank-provided, data rich testing environments.

These have been pointed to on this blog, but none of them have changed. PwC would do well to look at the integrations available on the Monzo and Starling API platforms, which are truly disruptive, particularly in cross currency payments where they undercut the retail market by several percentage points. They might consider that this functionality has been built voluntarily by these challenger banks and integrated third parties, but is in stark contrast to what the incumbents have done. Their focus remains the regulatory-mandated bare minimum. Given these misunderstandings / lack of knowledge, it isn’t a great leap to challenge the predictions of PwC of a £7.2bn market worth, and the value of their entire report. It’s just another example of unhelpful hype, which distracts from the really important issues. These need immediate engagement if anything positive is going to happen over the next 6-12 months.


PwC are right in one respect - open banking is a potential game changer. If this is to be realised, then there are significant challenges that the ecosystem needs to address immediately or open banking may not live up to its potential (at best), or may not develop at all. The aim of the CMA Order was to increase competition in the retail banking market, but there is evidence of decisions aimed at thwarting adoption of open banking, and entrenching a non-competitive market. Commentators who talk up potential future ecosystem development are complicit in this, as the column inches they generate, and speeches given at endless conferences, serve only to distract audiences from important issues which need addressing immediately. Open banking has been live in the UK for 6 months but there is little evidence of improvement, and OpenWorks’ recent report showed poor performance levels on the current implementations, even in the context of very limited use. Something must change very soon, or the only response to a GET request will be disappointment.