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.
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.
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
2024-11-19
12 min read
From authentication to authorisation: Navigating the changes with eIDAS 2.0
Discover how the eIDAS 2.0 regulation is set to transform digital identity and payment processes across the EU, promising seamless authentication, enhanced security, and a future where forgotten passwords and cumbersome paperwork are a thing of the past.
Read more
2024-10-08
6 min read
Lending essentials: how enriched data solutions help lenders tackle constraints
Enhancing your affordability assessment with Tink’s data-enriched solutions helps you put an end to inaccurate data, prevent fraud in loan origination and stay compliant – read on to explore the benefits.
Read more
2024-09-24
4 min read
Why Pay by Bank fits luxury retail like a glove
Pay by Bank offers a solution that addresses the potentially higher transaction fees and fraud risks while enhancing the customer experience for luxury retailers.
Read more
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.
