PSD2 and OpenBanking

The Payment Service Directive 2 (PSD2) is a EU regulation which came about in January 2018. This directive was created with the vision that banking in Europe should be open, as to allow third parties to interact with financial data and thus provide beneficial services using this data. Open Banking is the United Kingdoms version of PSD2 and can be considered synonymous with PSD2. I will just refer to both as PSD2.

The key objective of the PSD2 directive is to help provide guidance for European financial institutions, to build a universally understood framework for handling banking data. By having a set standard for financial data handling, all payment service providers can be united in sharing customer financial data, via their own API, in the same way as any other EU financial institution.

The benefit to a universally understood API is firstly, greater security due to a wider number of eyes viewing how the API specification is implemented. Secondly, it allows third parties to ingest all banking data in the same way. This allows third parties to build applications based on ingesting the PSD2 API specification, rather than having to cater for each banks independent API, which would cause far more work.

When taking a high level look at PSD2, it is simply a set of API specifications. These APIs are defined in the OpenBanking development zone: https://openbanking.atlassian.net/wiki/spaces/DZ/overview

PSD2 Third Party Usage Examples

As previously mentioned, the purpose of PSD2 is to allow Third Party Providers the ability to interact with financial institutions and gain access to user banking data, with a users consent, importantly. A few example scenarios could be:

  1. An mobile application which helps monitor spending habits and then advises on money saving methods. To view a users spending habits, the Third Party Provider would connect using the OpenBanking API.
  2. A web application that provides the best credit solutions based on a users spending. To view a users spending habits, the Third Party Provider would connect using the OpenBanking API.
  3. A global business payments application which ingests all business accounts and includes the ability to see spending analytics or conduct payments across accounts in one central place. To access a users accounts, the Third Party Provider would connect using the OpenBanking API.

These are just three examples of why the OpenBanking API has been introduced.

API Weaknesses

No solution is void of attack vectors. Although a specification exists for Financial Institutions to follow, this does not make human error disappear. If an API endpoint is built in an overly permissive way or some how does not ask for a users consent, this could lead to a disastrous situation, especially when you consider finances are involved. Various API Weaknesses can be found within the OpenBanking API, as it can with any API. Some of these include:

Broken User Authentication

The OpenBanking API relies on oAuth2 and JSON Web Tokens for authentication. It’s a complex authentication mechanism and easy to potentially get wrong. If an organisation does get this wrong, that could mean unapproved Third Party Providers or attackers could access the API.

Authorization (Mass Assignment)

If the OpenBanking API specification is not followed exactly, an organisation could find themselves presenting too much data via one or more of their Endpoints. This may allow for a Third Party Provider to view too much data or view data they should not be able to see. An example would be providing a users entire banking data (balances, accounts, credits, etc) via one API endpoint, rather than being granular as per individual consents, as specified in the OpenBanking documentation.

Lack of Resources & Rate Limiting

A usual afterthought within API development is how much resource may be used by any connecting Third Parties Providers. Rate limiting is an important factor to help prevent accounts being brute forced by attackers for their credentials, but also to stop server resources being unnecessarily used, potentially causing Denial Of Service. This may even be accidental where developers from Third Parties Providers build code loops without realising, which may inadvertently cause sever stress.

Injection

Injection attacks are usually a large issue when they occur. These attacks may allow malicious users or unknowing Third Party Providers, the ability to see far more information than should be permitted. As mentioned in Mass Assignment above, this could be gaining the ability to access the entire banking accounts database due to database injection.

Security Assessments

The main onus for being secure when it comes to PSD2 is on the Financial Institutions. They are the ones creating the APIs and thus they are responsible for ensuring appropriate security testing has been conducted.

Of course, Third Party Providers will be integrating these APIs into their platforms and these integrations will equally need security testing to be performed. However, the biggest issues will come from the Financial Institutions, as these are the entities who provide the ability for users to consent to their data being used and provide the bulk of the data.

Third Party Providers merely ingest this data, although as mentioned previously, it is possible to also initiate payments using the OpenBanking API. Therefore, if the Third Party Provider is compromised and an attacker is able to gain access to user consents. This could mean a very bad time for customers accounts.

This is slightly worrying when you commonly see potential flaws which could allow attackers to access this API. One very common example is overly permissive mobile applications:

I would wager that 99% of users just allow this prompt. This is common throughout various areas of computing, Terms and conditions especially. However in this case, if an attacker steals the mobile phone, maybe it would be possible to modify the application and then access the API. This is only one example, flaws such as Cross-Site Scripting in a TPP web application may lead to API access too. The point is, vulnerabilities exist all over the place and security assessments are a vital part to the development process.

Defining a Scope

You may be wondering where you should start when it comes to having your API tested. As shown above, the specification tells Banks to use the following API definitions to create their API:

  • Account and Transaction API
  • Payment Initiation API
  • Confirmation of Funds API
  • Event Notification API

When forming a security assessment scope, this is where you should start, your APIs.

Ideally, as a financial institution you will be able to provide the security tester with your TPP on-boarding platform, where they may sign up as a TPP and gain access to the API. The tester will also need a banking user whom is able to provide consent for their data to be accessed. This access will provide a tester with ability to assess the whole solution for a full API assessment.

The above is the very minimum you should be testing. However, you should also consider having the whole solution assessed. This means adding the supporting infrastructure into scope as well as supporting mobile applications, web applications and so forth.

Hopefully this provides a general idea of what the PSD2/OpenBanking standard is all about and what you should consider when thinking about conducting a security assessment. As there are a few common terms to know when discussing OpenBanking, I’ve included a list of the need-to-knows below.

Common Open Banking Glossary

  • Account Information Service Provider (AISP)
  • Account Servicing Payment Service Provider (ASPSP)
  • Strong Customer Authentication (SCA)
  • Payment Service User (PSU)
  • Payment Service Provider (PSP)
  • Payment Initiation Service Provider (PISP)
  • Third Party Provider (TPP)

See my other blogs here: https://mrturvey.co.uk/blog/