PSD2 APIs: what the EBA Opinion on obstacles really means

The EBA has shared its thoughts on the obstacles facing licensed third-party providers using PSD2 APIs. With this publication, the EBA hopes to cure some of the biggest headaches, and establish a foundation that enables open banking to thrive across Europe. This is Tink’s summary of the most significant implications.

TL;DR – Quick summary

  • The EBA has documented its opinion on the RTS for PSD2 APIs.

  • The aim is to significantly reduce obstacles for those leveraging open banking technology.

  • Implications include authentication for TPPs being as smooth as the user’s own banking app.

  • Manual input of IBAN details is also seen as a barrier and no longer allowed.

  • The EBA is levelling the playing field between banks’ own apps and TPP services.

What's the EBA Opinion on obstacles for PSD2 APIs?

The European Banking Authority (EBA) Opinion on obstacles follows repeated requests for clarification from Tink and other fintechs, but also banks and the national financial authorities. The document reflects on how banks should design their dedicated interfaces (PSD2 APIs), to allow licensed third-party providers (TPPs) to access checking account information and initiate payments. 

The regulatory technical standards (RTS) for strong customer authentication (SCA), and common and secure open standards of communication (CSC), specifies that banks building PSD2 APIs must do so without creating obstacles for TPPs.

To date, in the assessment of whether the PSD2 APIs are compliant, the financial authorities across Europe have largely been left to their own interpretation on what is or isn't an obstacle. 

Banks all over Europe have been building PSD2 APIs with only a handful of pointers on the features that need to be supported. As a result, the look and feel of APIs across Europe vary wildly, and there are features (or the lack thereof) that have been considered an obstacle in one country, but not in the next.

Here are some of the most significant points raised by the EBA - and what they mean.

1. Authentication needs to be smooth

The SCA flow – where users authenticate towards their banks and allow licensed TPPs to retrieve account information or initiate a payment – must be as smooth as the interface on the bank’s mobile banking app. 

This means PSD2 APIs should not redirect a user through an inferior or more cumbersome authentication process. It’s quite common for PSD2 APIs to enforce authentication exclusively through web redirect, which means that mobile users would need to complete the SCA flow on an internet browser, to access the services offered by licensed TPPs. This is considered an obstacle when the user would typically authenticate within their bank’s mobile app already installed on the phone. The EBA hopes this will help to improve the experience when TPPs use PSD2 APIs.

2. Supporting payments at point of sale

The EBA has made clear that banks offering customers the option to perform instant payments at the point of sale (POS), or anywhere else for that matter, should design PSD2 APIs that let licensed TPPs do the same. It clarifies that banks don’t have to develop new authentication methods for that, but must support all their existing ones.

In practical terms, this means that TPPs can offer POS solutions, for example using NFC or QR codes, either by relying on a bank’s specific POS authentication method if they have one, or using another existing authentication to initiate the payment.

3. Account selection should not require manual input

For payment initiation services from licensed TPPs, the user needs to identify and select the payment account for money to be transferred from. Currently, there are many PSD2 APIs that require the user to manually input the international bank account number (IBAN) details to allow the TPP to initiate a payment. 

The EBA has now said this is an obstacle that should not be allowed. 

Instead, banks should design PSD2 APIs that let a licensed TPP collect a user’s available payment account and IBAN details by accessing the account information, or offer an authentication flow (redirection or decoupled) that lets the user select which account the licensed TPP can initiate a payment from.

4. One SCA flow is more than enough 

The EBA has clarified that in nearly all scenarios, one SCA flow is sufficient for the user to authenticate towards their bank when using the services of licensed TPPs. 

Many banks have designed PSD2 APIs where the user needs to authenticate more than once, to allow a licensed TPP to retrieve information the user has already given explicit consent for. Some banks argue that by applying multiple authentication flows in the PSD2 APIs, they are enforcing an even stronger authentication protocol. 

The EBA has clarified that this creates unnecessary friction in the user journey, especially when compared to the authentication procedure the bank itself offers online or on a mobile phone. 

This makes a lot of sense, because the strength of an SCA lies in the fact that it requires two independent credentials, and not in entering the same ones multiple times.

5. Consent is given to the licensed TPP

The PSD2 states it is the obligation of a licensed TPP to ensure it has obtained the user's explicit consent for its services. Although these licensed TPPs are regulated businesses, under the supervision of the financial authorities, many banks have designed PSD2 APIs that only work when the user has given up-front consent to the bank to enable such services, or where the bank requires the user to confirm or check the consent that has already been provided to the licensed TPP. 

Double checking consent is seen as a significant obstacle to a smooth user experience by not just the EBA, but by the European Commission too.

Looking ahead

Although the EBA Opinion on obstacles also addresses a number of other topics, the five above should help clear up some misconceptions, and harmonise the current PSD2 API landscape. It’s exciting to see the progress of the open banking landscape since the RTS was enforced on 14 September 2019.

We’re looking forward to seeing what new opportunities, innovations, and great customer experiences will be enabled in the next generation of financial services.

More in Open banking

What is open banking, and what is it good for?
2020-10-15·4 min read

What is open banking, and what is it good for?

We’re always on about how great open banking is, and how it’s ramping up innovation and competition in the financial services industry. But what is it, exactly? And why does it matter? Here’s a (very simple) rundown.

Lydia and Tink partner for open banking
2020-10-08·2 min read

Lydia and Tink partner for open banking

The news is out. We’re teaming up with Lydia as its open banking technology partner across Europe, to streamline the app’s bank connectivity and create new services for millions of  customers.

3 tips for staying ahead of the curve in the open banking shift
2020-10-07·3 min read

3 tips for staying ahead of the curve in the open banking shift

To stay ahead of the curve and master the open banking transformation, bankers need to start looking beyond compliance, and be smart about where to invest.

Get started with Tink

Contact our team to learn more about what we can help you build – or create an account to get started right away.

Contact our team to learn more about our premium solutions or create a free account to get started right away.