The European Banking Authority (EBA) published clarifications to a fourth set of issues that had been raised by participants of its Working Group (WG) on APIs under PSD2. The clarifications respond to issues raised on the confirmation of payment execution, biometrics and authentication on mobile apps, access to non-payment account information, stress testing, qualified eIDAS certificates for Account Servicing Payment Service Providers (ASPSPs), the 4 times per day access by Account Initiation Service Providers (AISPs), and the Sharing of payment account number with Payment Initiation Service Providers (PISPs).
Topic: Biometrics and authentication on mobile apps
Description: Several participants raised concerns that the APIs currently offered or being developed by many banks do not support app-to-app redirection or so-called decoupled authentication (which allows the customer to authenticate using a dedicated authentication application of the ASPSP, such as a banking app on a mobile phone) when the customer is using a TPP, although some of those banks allow their customers to authenticate via the ASPSP’s mobile app or use biometrics to authenticate in the online channels of the ASPSP in order to access account information and/or initiate payments directly.
These participants stressed that ASPSPs should allow AIS and PIS providers to rely on all the authentication procedure(s) provided by the ASPSP to its PSUs. In particular, they highlighted that ASPSPs supporting the use of biometrics in their mobile/online channels should also support authentication via biometrics in their dedicated interfaces. TPPs highlighted that this is essential in order to ensure a seamless customer experience and not to create obstacle to the provision of AIS and PIS.
EBA response: In accordance with Article 97(2) of PSD2 and Article 30(2) of the RTS, ASPSPs should ensure that their dedicated interface does not prevent PISPs and AISPs from relying upon the authentication procedure(s) provided by the ASPSP to its PSUs.
As clarified in paragraph 50 of the EBA Opinion on the implementation of the RTS (EBA-Op-2018-04) and the Final report on the EBA Guidelines on the conditions to benefit from an exemption from the fall-back mechanism (EBA/GL/2018/07) (feedback table, page 68, comment 75 and page 75, comment 89), ASPSPs’ dedicated interfaces should support all authentication methods made available by the ASPSP to its PSUs when an AISP or PISP is used.
Accordingly, the method of access, or combination of methods that the dedicated interface should support, will depend on the authentication procedures that the ASPSP offers to its own PSUs, and whether security credentials are transmittable (such as a passwords) or not (such as biometrics).
This means that, ASPSPs that have implemented a redirection approach and that enable their own PSUs to authenticate via the ASPSP’s mobile app when the PSU directly accesses his/her account should also support app-toapp redirect when the customer uses a TPP. App-to-app redirection should allow the TPP to redirect a PSU from the TPP mobile application to the ASPSP’s mobile application, 3 installed on the PSU’s device, where PSUs can then authenticate using the same credentials/methods as normally used for accessing their account directly. This should not involve additional steps than would be the case when the PSU authenticates with the ASPSP directly (such as being redirected first to the ASPSP’s mobile website).
Finally, ASPSPs that support authentication using biometrics in their direct customer channels should also support these authentication methods when the PSU is using a PIS or AIS provider. In such case, given that biometrics are not transmittable credentials, ASPSPs should support decoupled or app-to-app redirect to the ASPSP authentication app and secure transmission of the ASPSP’s app authentication status to the ASPSP (e.g. using a signed proof that the biometric validation has been performed successfully).
Download the full document here: EBA responses to issues XIV to XX raised by participants of the EBA Working Group on APIs under PSD2