PSD2 Memo: Opinion of the European Banking Authority on obstacles under Article 32 (3) of the RTS on SCA and CSC
Since the application date of the RTS on 14 September 2019, a number of TPPs have reported issues regarding redirection approaches offered by ASPSPs, where the customer is redirected to the ASPSP in order to authenticate when using AISPs/PISPs services. The issues that have been raised in this context refer in particular to the scenario where redirection is the sole method of carrying out the authentication of the PSU supported by ASPSPs.
Thus, the EBA has published an opinion on obstacles to the provision of TPPs services under PSD2, responding to a number of queries and issues that had been raised by market participants with the EBA and National Competent Authorities. This opinion is based on Article 29(1)(a) of Regulation (EU) No 1093/20101, as part of the EBA’s objective to “play an active role in building a “common Union supervisory culture and consistent supervisory practices, as well as in ensuring uniform procedures and consistent approaches throughout the Union”. It aims at supporting the objectives of PSD2 of enabling customers to use new and innovative payments services offered by TPPs.
As Finologee is both an API service provider and an aggregator of Third-Party Fintech components dedicated to providing you with the best customer experience, we believe that this PSD2 memo can help you understand the issues raised with the EBA and keep you up to date on this subject.
Redirection/authentication that ASPSP’s should support
The EBA clarified in the final report on the above-mentioned Guidelines that, in a redirection or decoupled approach, where the PSU is redirected to the ASPSP to authenticate, the interaction between the PSU and the ASPSP should be minimised to what is necessary in order for the PSU to authenticate. The authentication procedure with the ASPSP as part of an AIS/PIS journey should not include unnecessary steps or require the PSU to provide unnecessary information compared to the way in which the PSU can authenticate when directly accessing their payment accounts or initiating a payment with the ASPSP. The EBA deems such unnecessary steps or information required as obstacles. If the interfaces provided by ASPSPs do not support all the authentication procedures made available by the ASPSP to its PSUs, this would be a breach of Article 30(2) RTS and an obstacle under Article 32(3) RTS.
App to app
ASPSPs that enable their PSUs to authenticate using the ASPSP’s mobile banking app or a dedicated/decoupled app, as one of the two-SCA factors categorised as possession, in line with paragraph 26 of the EBA Opinion on the elements of strong customer authentication under PSD2 (EBA-Op-2019-06), when directly accessing their payment accounts or initiating a payment with the ASPSP, and that require PSUs to authenticate with the ASPSP to use the AISPs/PISPs services, should also enable their PSUs to use the ASPSP’s authentication app as one of the two-factor SCA elements in an AIS or PIS journey.
Multiple authentications
AISP should not require more SCAs, or add unnecessary friction in the customer journey, compared to the authentication procedure offered to PSUs when directly accessing their payment accounts with the ASPSP.
In a PIS-only journey, the EBA came to the conclusion that ASPSPs should support a single SCA for a single payment initiation via a PISP, if the PISP transmits to the ASPSP all the information necessary to initiate the payment, including the account number/IBAN of the account to be debited. Requiring two SCAs in such a case, namely one SCA for accessing the account data, and a separate SCA for initiating the payment, is not necessary and is, therefore, an obstacle, unless the ASPSP has duly justified security arguments why two SCAs would be needed in such case.
90-day re-authentication
PSUs are still required to re-authenticate at least every 90 days in order to confirm that the AISP can continue accessing their payment accounts data without SCA. “The EBA sets the 90 days re-authentication requirement as a rule” to reach an appropriate balance between the competing objectives of PSD2 of ensuring consumer-friendliness and ease of use, on the one hand, and increasing security, on the other hand. The 90-days requirement itself is therefore not an obstacle. As regards the question of who can perform the renewal of SCA, the EBA is of the view that the obligation and responsibility under PSD2 to perform SCA lies with the ASPSP.
Account selection
The EBA clarifies that interface implementations that require PSUs to manually input their IBAN into the ASPSP’s domain in order to be able to use AISPs/PISP’s services are an obstacle, as it is considered as an additional step.
Berlin Group release update
Berlin Group has recently published a new version of its API file (version 1.3.6). The standard APIs used between the TPPs and the ASPSPs and managed by Finologee have been updated – from version 1.3.3 to version 1.3.6. There are several categories of updates:
- Changes supported by Finologee as part of the Service Agreement – with no impact for the ASPSP
- Changes supported by Finologee as part of the Service Agreement – with potential impact for the ASPSP (when mandatory): The Client has to provide a decision to Finologee on the implementation of the optional changes.
- Optional changes – subject to Change Request (implementation at the discretion of the Client)
Please note that for the items, identified as “Changes supported by Finologee as part of the Service Agreement – with no impact for the client (and free of charge)”, developments have been performed and a go into production is planned after July 15th.
