You'd be forgiven for thinking this long awaited and highly revered era of 21st Century 'Open banking' that's just been ushered into the UK with a spirited shove-in-the-back by its Competition & Markets Authority (CMA) hasn't exactly captured the public's interest.

Open Banking is the central plank of the second most significant payments directive to come out of Europe this Millennium (PSD2). Like its forerunner nearly a decade before, its principal aim is to loosen the vice like grip large retail banking giants hold over their customers and perhaps more specifically their customers financial doings, by fostering an ecosystem in which new young FinTechs can not only land but be given an adequate share of the oxygen for long enough to potentially thrive.

Two key enablers here. First to make sure that old boys play fair with the new kids and then provide the big banks' customers with the freedom to safely engage: to try and test out the spectrum of compelling ideas brought to market by the young breed of FinTechs, whilst the seasoned custodian bank keeps watchful eye.

So, it hasn't started well.

That is to say, putting aside the delayed start by the significant majority of the so called CMA9 (Allied Irish, Bank of Ireland, Barclays, Danske, HSBC, Lloyds, Nationwide & Santander) the way the UK's Open Banking Implementation Entity or OBIE has devised the 'Consent Model' (that's the process by which the customer gives the FinTech permission to access their bank account) will have the conspiracy theorists spinning and the scammers working nights.

Let's look at the 'Open Banking Consent Model' (source: openbanking.org.uk)

New FinTechs that want to engage in Open Banking: either for the purposes of delving deeply into a customer's account information (AIS) or to make and take payments on their behalf (PIS) are collectively known as Third Party Providers (TPPs). The process by which the bank account holder gives consent to one of these new TPPs in order for them to access their account starts in the TPP's own domain.

When the customer clicks the consent box and indicates which of their bank accounts they wish to permit TPP access to they are handed off (digital auto-redirect) to their bank login page by the TPP's own application. Next thing they see is their bank's website which should look broadly familiar. It's not their usual login screen (which for a significant proportion would be their bank app) it's a new landing page on the banks online banking website that has been specially built for the purpose of Open Banking 2018.

An illustration is provided on the Open Banking Consent Model. In the example on page 5 (included at the bottom of this blog) 'Treequote' is the FCA Authorised AIS looking to access the customer's financial doings from 'Greenview Bank'. Having selected their bank account and confirmed consent, the next thing the account holder knows they're at their bank's website. Figure 2.3 depicts the Greenview bank's mobile web page.

Next the customer enters their sensitive bank login credentials to prove they're the account holder (referred to in Fig 2.3 as 'the authentication step'). Once authenticated the bank then serves up a list of the various consents the TPP has told the bank the account holder has given them and asks the account holder to confirm this. After that the same mechanism that got them there delivers the customer back to the TPP's domain (in this example they are returned to Treequote).

According to OBIE these new landing pages (URLs) created by each of the CMA9 replicate the current online banking login routine of each account holder. So depending upon the bank you use this login (authentication step) may be knowledge-only based (using a User-ID and password as in the Greenview Bank example) or may require a SecureKey or some other physical token which arrived on the scene in the last Millennium. However, a significant amount of online browser logins in the UK , such as NatWest, still use the single factor knowledge-only approach known as One Factor Authentication (1FA).

A scammer's delight

Not only does this consent flow include two session breaks which are ideal phishing attack vectors but there's a greater scamming opportunity created here …

Now please shout out in the Comment box if you know of any other use cases where a third party organisation redirects the account holder to his/her own bank login page and asks them to verify themselves by logging into their bank account before being transported back to the third party's domain. Since I'm not aware of any I'm keen to hear as fostering such behaviour, which puts customers login credentials at risk seems plain irresponsible.

It would be trivial for scammers using a lure and having ghosted up a suite of exact replicas of each of the banks login pages to capture customer login credentials. Although it feels like and looks like you've been securely taken to your bank's login site, you of course hadn't actually left the scammer's domain. A few keystrokes later and they're away with your login credentials. This kind of scam using false website links to click on or bank fraud hotline numbers to ring (which present as the real thing) have been around a while because they've been successful. Haven't we learnt from this? People unfortunately fall for this stuff.

In attempts to combat such a risk, banks state: "you are urged to first establish that the TPP is authorised by the FCA by checking the register". Despite such alerts typically being unhelpfully buried in up-issued T&Cs, have you actually tried checking the FCAs register to see if the supposed TPP is 'Authorised' as an AIS or PIS? Have a go here if you like.

You fall deep into the dark vaults of the FCA where you're expected to use their vast corporate catch-all registry and left to make some assumptions. Logic would suggest a separate 'Open Banking' registry might have been created but this is all there is and from the public's perspective it's as clear as it is user-friendly (hint: not fit for purpose).

Adding to the confusion: in their recent customer advisories on Open Banking banks are suggesting that Authorised TPPs may actually ask for your bank login credentials. I kid you not: Barclays wrote to customers recently on Open Banking advising "an alternative option is to share your bank account details directly. This is where any company can request your personal login details. If you give them your login details the company will then log into your bank account as if they were you in order to use your data". In their updated T&Cs on 13 January (the day Open Banking went live in the UK) RBS advises: "Some TPPs might ask for you for your digital banking login details and passwords to provide their service to you."

Whatever their rationale it seems totally irresponsible for such misinformation to be circulating on any 'Open Banking' informers as the Implementation Entity (OBIE) has confirmed to me this week: "none of the TPPs has a use case under the new Open Banking Standards to ask a customer to share their login credentials".

Whilst that's great to hear the public are being recklessly misinformed ... by their own banks.

Looking at the Consent Model itself it's a woefully low-tech design for what's supposed to be the bleeding edge way forward. The all-important customer journey (user experience) will inevitably be frustrating and it will wholly underwhelm the significant proportion of would be customers that bank-by-app and log in using smartphone sensors. They will feel like they've be teleported back to a dark age when bounced back to their old online banking login URL which was never their friend. I expect many may struggle to even remember their online login routine and just drop out.

So why has it been designed like this?

Inevitably that cursed blend of time, cost, inertia and apathy. The CMA's timeline for UK banks was just unrealistic. Furthermore, the Open Banking Standards that OBIE produced was completed before even the 'transition period' for PSD2.  Even though the law is in place, the important Regulatory Technical Standards (RTS) for 'Open Banking' are not: they are essentially still in flux and don't apply until officially approved by the European Parliament & Council (EPC) and published in the Official Journal of the EU. That's 18+ months away.

These are the key standards that govern the way in which secure communication between the new TPPs, the account holder and their bank is managed and the manner in which the customer authenticates themselves: the new system's blood and oil if you like.

With so much of the workings still in the air and subject to change (at least until 2019) it's no great surprise that banks have managed to adopt a minimum viable product approach.

Okay, let's look at possible alternatives?

Governed by the same imposed pressures from the CMA, I'm sure the good folks at the Implementation Entity (OBIE) are in a tight spot and have been working very very hard. That said they need to rethink their Consent Model pretty soon.

I'm going to field an alternative, but the Comment box is ready waiting for yours!

The bank account provider authenticating its own customer is a sensible plank of the RTS, but that doesn't mean it has to be done in the same flow and the sequencing's wrong. The first establishment of trust in the tripartite is the customer verifying themselves to their bank (whilst the TPP stands by) when the new and most untrusted party in the transaction is the TPP.

It would be more sensible, more secure and more scam proof for the CMA9 to build and maintain a drop-down list of the FCA authorised AIS and PIS companies in their apps and websites and keep the TPP out of the authentication flow.

When a customer hears of a compelling new TPP service they want to try they login to their bank account (themselves) using their normal routine. Then they select the TPP from the dropdown box of 'Authorised TPPs'; click the activities they wish to permit the TPP to carry out (another drop-down: one each for AIS and PIS) and they're done. Their bank then runs an algorithm which spits out a unique code: which is profiled to the TPP, the customer and all the personalised mix of consents they've just granted. This Consent Code let's call it can then be passed by the customer to the Authorised TPP (useless to others should it fall into the wrong hands).

When the TPP presents the code to the bank's API, the bank can compare the access rights they're requesting to their records from the Consent Code the bank generated and stored on the customer's account. This securely removes any involvement of the TPP in the customer login process (authentication) and should the customer wish to revoke any aspect of the consent they've granted they know exactly where to go to remove it. The account holder has much greater control.

Clearly this alternative model would be a fair bit slicker again on the smartphone app scenario (mirroring common verification loops using 2FA and OTCs delivered by App Notifications not SMS). By the time the TPP Consent Code arrives on the customer's screen (via Bank App Notification service) the customer has closed their bank app and opened up the TPP app and it's there ready to copy and drop.

[ worth reminding that Open Banking isn't available to those that don't bank online. It's a separate debate: but there's a strong argument backed by considerable advantages for all stakeholders to make Open Banking a feature that's only available App-to-App ]


Is the current Consent Model even PSD2/GDPR compliant?

It's questionable whether the current consent model is even compliant to PSD2 Article 97(5): "protecting the confidentiality and integrity of an account holders personalised security credentials". Beyond that, the extent to which the customer's sensitive customer login credentials are endangered by the model might also fail scrutiny of new GDPR regulations which come into force in May 2018, where the leading mantra there is "data integrity by design". By design.

We'll have to see how those play out.

Where do we go from here?

The overarching claim here is that CMA has been too hasty in propelling UK banks into Open Banking (as part of their retail banking sector remedies) and before the environment was actually ready. This is the CMA's doings and critics would say they've pushed UK banks under the bus. In bringing Open Banking to the UK they should have understood the wider relevance of having PSD2's RTS in force.

Due to the highly complex nature of devising all the necessary components around the secure communication between the customer, the new FinTech and the incumbent banks; including the obvious need to set up a new API interoperable platform and the sensible requirement (now that everyone has a smartphone) for online transactions to be authenticated to a higher standard, the RTS doesn't come into force in Europe (including the UK) until the end of next year. Even 18 months is challenging to build, test, and refine all the components.

The customer authentication piece within the RTS is known as 'Strong Customer Authentication' (SCA). Frequently also referred to as 2FA (two factor authentication) and replacing its weaker alternative of 1FA (described earlier) it's designed to prevent anyone other than the account holder(s) from accessing their account as login must include either 'something they have' (possession: token, smartphone, digikey etc) or, better still: 'something they are' (Inherence: biometric or behavioural biometric etc).  It's a requirement of PSD2 that all bank account logins use 2FA when the RTS goes live. 

This lets the bank know the account holder, the human, is present (AHP) and since it removes any risk of a third party logging in it essentially kills off screen scraping activities at that point. This is an example of how the RTS has been carefully compiled to include a number of changes choreographed to work in unison.

In forcing UK banks to go live with Open Banking before the RTS goes live the CMA has not just turned the UK into a nursery for the rest of Europe but has unwisely opened the show with a consent model which has the potential to put the UK public off the idea of Open Banking for a very long time.

Let's hope they use the premature entry, the delayed start, the low public awareness and the remaining transition period to their advantage and redesign the consent model very soon.