A day in the life of Open Banking

A new regulation came in on January 13th within the UK called PSD2, otherwise known as “Payment Services Directive 2”. This directive states that all banks in the United Kingdom will have to share its customers financial data via an API.

Essentially anything that a bank knows about you, will be readily available to third parties, if you authorise it. This means information will be freely available such as:

• Your regular incomings and outgoings
• Your Direct Debts
• How much debt you have
• How much are you saving

The idea behind this is to create a more driven and innovative banking space. For example, we are likely to see banking customers connect with third party websites to review their spending habits and recommend changes based on lifestyle habits.

Oh! You shop in SupermarketZ and spent £150? Did you know that the average weekly shop in SupermarketA is only £80? This is a saving of £70

One might connect their bank with another bank. For example, you are a credit card holder with HSBC and pay your debt monthly with no exception. By linking your account to Natwest, you may be offered a better Credit APR or maybe an overdraft without affecting credit score.

In my opinion, the idea is very good and by using the right third party could really help those customers that struggle to budget and save money live a better life.

However, I also foresee a dark side to Open Banking.

Welcome to the Dark Side?

I believe the first point to look at here is the API, if you don’t know what an API is it stands for it is an Application Programming Interface.

In simple terms an API creates the interface for a third-party entity to communicate with another entity. In the case of Open Banking, it will be a Bank providing an API so Third-Parties can read customer banking information.

The Open Banking API specification in which Banks will have to follow can be found here:

https://openbanking.atlassian.net/wiki/spaces/DZ/pages/5785171/Account+and+Transaction+API+Specification+-+v1.1.0

Looking at this specification, given a customer’s permission, third-parties can view several pieces of data regarding a customer including; Accounts and Balances, Beneficiaries, Standing Orders, Products and Transactions.

This is a fair amount of personal confidential data to know about a person, however the API extends further to Payment Initiation. This allows third parties to send money to other accounts, or even create direct debts!

What can possibly go wrong?

Authorised Vs Unauthorised third-parties    

I mentioned above that it is the customer whom will have to allow third-parties to access information. These Third Parties will be regulated by two people

• The Financial Conduct Authority who will give authorised status to compliant third-parties.
• Open Banking who will approve a Third Party to use APIs

This does give some security in the way that an attacker cannot simply hook into a Banks Open Banking API and create a phishing website, whereby they trick users into allowing access to their bank. But I do feel like this opens a beautifully decorated door for an attacker to use in other ways though!

Overly permissive applications

Web applications will start to be made in a rapid fashion to try and get in with this new trend of the public using Third Parties for innovative banking.

You know what they will also do? Ask for your permission to see your banking information, obviously.

These web applications are going to ask you for varying levels of permission, from very basic “read your bank statements” to full payment access.

You may think that you won’t give these websites full payment access unnecessarily as they do not need it, but there are certain people in this world will just accept things like this:

Or more specifically, like this:

The above are examples of items that the general population will just “accept” without really thinking or caring. Looking at the second image specifically, you are giving Starbucks the ability to see your files/photos, contacts and more. Firstly, why do Starbucks need this? But we give them the permissions because we want to use the application.

The same principle is going to exist here. You have a fancy well-built web application that asks for your banking permission in return for something, such as a better credit score. Realistically, this only needs to read your bank statements. However, it may ask for full permission and like giving Starbucks all of the above, you oblige because you really want that better credit rating.

Going back to what I said earlier, full Open Banking permission is going to allow this website to SEND MONEY. This one mistake of giving a third-party web application the ability to view your banking could potentially cost you a lot of money! This example refers more to a Third-Party employee being malicious with your account, this may be farfetched so let’s see another example:

Weak third-party security

It’s a known fact that banking institutions spend millions on security and penetration testing. This makes a customer feel a bit safer using their web application to conduct banking needs.

If a customer does choose to use a real third-party, it’s likely the same level of security won’t be applied on their Web Applications as a Bank would have.

For example, the 2-Factor Secure Key a customer uses with a HSBC account to authenticate won’t be needed for a third-party application, this already removes a barrier to enter a customer account.

A third-party user won’t be logging in with their account number anymore, for these websites its back to the standard username approach. This means if you’re compromised on one website, you may well have your bank account compromised too through username/password reuse. This is not usually an issue with Banking because you have a personal ID to sign in.

To back up my theory here I considered some web applications that use Open Banking.

Number one, InvestGlass. First page you get in a Sign In prompt using Username and Password authentication as I previously mentioned, paging Mr.Hunt – https://haveibeenpwned.com.

Number two, HouseUp. First page you get is a FACEBOOK authentication. Not only do you give your Banking detail to this web application, you also give Facebook the privilege to access it.

What’s so bad about this you ask? Well, let’s say we have a customer that has registered to HouseUp.

Most people leave their Facebook pages logged in, in fact I don’t know anyone who logs their Facebook out.

Let’s say their computer is stolen or compromised and an attacker can now use it. The attacker looks at the browsing history, they see HouseUp…. JACKPOT! Facebook is still logged in and they can now login to HouseUP via Facebook! Cya later Banking data.

Oh, we’re all doomed!

No, you’re not. The example above is potentially very dangerous and poor third-party security extends to many other attack vectors, such as mobile applications. However, luckily, you don’t have to share your data if you do not want to do so.

Common sense is going to have to prevail here because we know very well that security is hardly ever done right and trusting your banking data is a significant risk. There needs to be a strict standard of security set upon Third Parties using the Open Banking API. If an entity doesn’t meet the standard, they shouldn’t be able to use it.

The Open Banking Specification does mention some security considerations, such as only using TLS1.2 encryption and various other snippets like “The entity should be penetration tested and comply with ISO27001”.

It also specifies the Third-Party must provide the last time a customer logged in and their IP Address. This is easily spoofed and wouldn’t provide much in the way of finding out who attacked a user. As for having a penetration test, this is fine IF the organisation acts upon its findings.

I feel there needs to be a solid standard in place and if a third party does not comply, there is consequences. The standard needs to include customer web or mobile application security, OWASP TOP 10 style.

I believe Open Banking is going to create a whole new world of issues and so many more cases of fraud, so the question is: “What can you do to help yourself not become a victim?”

Using Open Banking, the safe way…

First and foremost, I believe a lot of websites are going to start using this for payment or to perform certain tasks. The example I gave above “HouseUp” is a very good use of the Open Banking technology, it reads your bank statements and suggests affordable houses to buy on Zoopla.

The answer is not to run away from Open Banking, it may well help you in your day to day life.

Regulation

It’s important to check if a third party is regulated before using it. This means the FCA have deemed the entity complies with standards and means you are somewhat protected from fraud. Using an unregulated entity won’t give the same protection against fraud, you may lose your money!

Protection

Understand what level of financial protection the authorised third-party or your own bank gives for Open Banking fraud. If you notice payments from your accounts which you did not make, will it be refunded? The answer is yes unless you have been very negligent.

Personal thoughts

Think about what you are doing. Is the web application necessary enough to warrant accessing your bank? Does the web application use 2-Factor Authentication and other common security methods?

Most specifically, is the web application asking you to allow access to the Open Banking Payments API? Allowing access to read your accounts is one thing, but allowing a Web Application to process payment is a whole other ball park. Does the application really need that access?

My fianl thoughts on the matter of Open Banking are:

• It does drive innovation, many good ideas are already out there
• It can allow attackers to cause serious financial damage to a person
• A security standard should exist and must be abided by for all Third-Parties, like PCI DSS.