PSD2 and Open Banking
My thoughts on Open Banking (PSD2)
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 Kingdom's 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 Open Banking 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:
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 Open Banking API.
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 Open Banking API.
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 Open Banking API.
These are just three examples of why the Open Banking 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 Open Banking API, as it can with any API. Some of these include:
Broken User Authentication
The Open Banking 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 Open Banking 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 Open Banking 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 server 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 Open Banking 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/Open Banking 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 Open Banking, 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)
Last updated
