EBA publishes new clarifications on customer authentication procedures

European Banking Authority (EBA) has just published three final Q&As and the interpretation it adopted mirrors the very argumentation MO.one put forward.

Jakub Koudelka – CEO @ Mo.one commented: „We submitted these questions as Mo.one a.s. (formerly ZNPay a.s.), and the EBA’s answers confirm what we, as a TPP, have long argued in practice on what does – and does not – constitute an “obstacle” under Art. 32(3) RTS”:

✅ “Authentication procedure” is the whole user journey, not just the final SCA step. Extra steps that exist only in the TPP flow – clicking a QR code, manually typing a username – don’t belong there.

Subject matter – Clarification of the scope of the term „authentication procedures” in the context of the RTS and the EBA Opinion on obstacles.

Question: Does the term „authentication procedures” in the context of the EBA Opinion on obstacles (EBA/OP/2020/10) refer only to the final SCA method, or does it encompass the entire end-to-end user journey required to complete the authentication? Does this mean that any additional steps in the TPP flow, such as the need to click on a QR code image or manually enter a username to invoke the authentication app, which are not present in the direct channel, constitute a failure to support the same „authentication procedure”?

Background on the question
Paragraph 14 of the EBA Opinion on obstacles (EBA/OP/2020/10) states that „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”.

In practice, there is ambiguity as to the scope of the term „authentication procedures”. Some ASPSPs appear to interpret this term narrowly, referring only to the final method of applying SCA (e.g., using biometrics or a PIN). However, these ASPSPs often prepend this final SCA method with a series of additional, cumbersome steps that are only present in the TPP journey. These steps can include requiring the PSU to click on a non-obvious QR code image on a web screen to invoke the app, or forcing the PSU to manually enter their username to trigger an authentication push notification.

These intermediary steps are not part of the authentication journey when the PSU accesses their account directly via the ASPSP’s native mobile app. It is therefore unclear whether a journey containing such additional steps can be considered the same „authentication procedure” as the more seamless one in the direct channel.

Final answer
Article 30(2) of the Commission Delegated Regulation (EU) 2018/389 provides that for the purposes of authentication of the payment service user (PSU), the interface referred to in Art. 30(1) of that Regulation must allow account information service providers (AISPs) and payment initiation service providers (PISPs) to rely on all the authentication procedures provided by the account servicing payment service provider (ASPSP) to the PSU.

Article 4(29) of Directive (EU) 2015/2366 (PSD2) defines authentication as ‘a procedure which allows the payment service provider to verify the identity of a payment service user or the validity of the use of a specific payment instrument, including the use of the user’s personalised security credentials’.

Paragraph 7 of the EBA Opinion on obstacles under Article 32(3) of the RTS on SCA and CSC (EBA/OP/2020/10) clarified that 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 or superfluous information compared to the way in which the PSU can authenticate when directly accessing their payment accounts or initiating a payment with the ASPSP. In the same vein, paragraph 15 of that Opinion further clarified that the authentication of the PSU with the ASPSP in an AISP/PISP journey, in a redirection or decoupled approach, should not create unnecessary friction or add unnecessary steps in the customer journey compared to the equivalent authentication procedure offered to PSUs when directly accessing their payment accounts or initiating a payment with the ASPSP.

The reference in the Opinion to the authentication procedure covers all actions required to verify the identity of PSU or the validity of the use of their specific payment instrument.

✅ When the user starts in a TPP’s mobile app, the benchmark is the ASPSP’s mobile banking app – not its less user-friendly mobile web. A bank can’t hide its smoother native channel behind the browser.

Subject matter – Definition of „equivalent authentication procedure” for journeys initiated from a mobile application

Question: When a Payment Service User (PSU) initiates a service from a Third Party Provider’s (TPP) mobile application, what is the correct „equivalent authentication procedure” of the ASPSP that should be used as the benchmark for assessing whether „unnecessary steps” have been added? Is it the ASPSP’s mobile web browser authentication journey, or is it the ASPSP’s native mobile banking application authentication journey?

Background on the question

Paragraph 15 of the EBA Opinion on obstacles (EBA/OP/2020/10) prohibits ASPSPs from adding „unnecessary steps” to the customer journey compared to the „equivalent authentication procedure” offered in their direct channels.

There is a significant ambiguity in practice as to what constitutes the „equivalent authentication procedure” when a service is initiated from a TPP’s native mobile application. Many ASPSPs possess both a mobile web browser interface and a native mobile banking application, with the latter typically offering a much more seamless and user-friendly authentication experience (e.g., using biometrics without additional steps).

When a PSU initiates a journey from a TPP’s mobile app, these ASPSPs often redirect the user to their mobile web browser journey. They then argue that any additional steps in this journey are compliant as long as they mirror the steps in their direct mobile web channel. This ignores the existence of their superior native mobile app channel. It is unclear which of the ASPSP’s direct channels should serve as the correct benchmark for comparison in a mobile-to-mobile context.

Final answer

Article 32(3) of Commission Delegated Regulation (EU) 2018/389 requires account servicing payment service providers (ASPSPs) that have implemented a dedicated interface to ensure that the interface does not create obstacles to the provision of payment initiation and account information services.

As clarified in paragraphs 6, 7 and 15 of the EBA Opinion on obstacles under Article 32(3) of the RTS on SCA and CSC (EBA/OP/2020/10), the authentication procedure with the ASPSP as part of an AIS or PIS journey should not include unnecessary steps or require the payment service user (PSU) to provide unnecessary or superfluous information compared to the way in which the PSU can authenticate when directly accessing their payment accounts or initiating a payment with the ASPSP.

Paragraph 16 of that Opinion also clarified that if the PSU is using an AISP or PISP’s services via the AISP/PISP’s mobile app, ASPSPs that have implemented a redirection or decoupled approach and that enable their PSUs to authenticate using the ASPSP’s authentication app (a mobile banking app or a dedicated/decoupled app) to directly access their payment accounts or initiate a payment should enable that:

(i)      the PSU is redirected from the AISP/PISP’s app to the ASPSP’s authentication app, without any additional and unnecessary steps in-between (such as the PSU being redirected first to the ASPSP’s mobile browser environment); and that

(ii)    after authentication with the ASPSP, the PSU is automatically redirected back to the AISP/PISP’s app, without, for example, the PSU having to manually reopen the TPP’s app, which would be an obstacle.

The assessment of whether unnecessary steps have been added must be based on a comparison with the way in which the PSU can authenticate when directly accessing their payment account or initiating a payment with the ASPSP. Accordingly, where a PSU uses the services of an AISP/PISP via an app provided by the AISP/PISP, and the ASPSP enables direct authentication via its mobile banking application, the relevant point of comparison is the ASPSP’s mobile banking authentication procedure. In such circumstances, introducing additional steps in the AIS or PIS journey that are not part of the ASPSP’s mobile app authentication procedure may constitute an obstacle within the meaning of Article 32(3) of the RTS.

By contrast, where the PSU initiates AIS or PIS in a mobile browser environment, and the ASPSP’s authentication procedure available to PSUs is also performed via a mobile web interface, benchmarking against that mobile web authentication procedure would be appropriate.

✅ A mandatory “retail vs. corporate” segment-selection screen that the user never sees when logging in directly is unnecessary friction – and therefore an obstacle.

Subject matter – Obstacle assessment of a mandatory client segment selection screen in a redirection journey

Question: Does a mandatory step in a redirection journey, where a Payment Service User (PSU) must manually select their client segment (e.g., retail or corporate) on an intermediary screen (web interface) before being redirected to the ASPSP’s authentication app, constitute an obstacle under Article 32(3) of the RTS, if such a step is not present when the PSU accesses their account directly via the ASPSP’s native mobile application?

Background on the question
Article 32(3) of the Commission Delegated Regulation (EU) 2018/389 (RTS) requires Account Servicing Payment Service Providers (ASPSPs) to ensure their dedicated interface does not create obstacles. The EBA Opinion on obstacles (EBA/OP/2020/10), specifically paragraph 15, clarifies that the authentication journey in a redirection approach should not „create unnecessary friction or add unnecessary steps in the customer journey compared to the equivalent authentication procedure offered to PSUs when directly accessing their payment accounts”.

In practice, some ASPSPs implement a redirection journey where the Payment Service User (PSU) is presented with an intermediary screen. On this screen, the PSU must manually select their client segment (e.g., „Retail Banking” or „Corporate Banking”). ASPSPs justify this step by claiming they cannot decide for the client which profile to use. This selection step is not present when the PSU logs directly into their native mobile banking application.

It is unclear whether this mandatory selection constitutes an „unnecessary step” and therefore an obstacle under the current RTS. This ambiguity is particularly acute in subsequent journeys, such as a Payment Initiation Service (PIS) from an already-linked account, where the context of the client’s segment is already established, or in situation where the client only has one segment (eg. retail), making the selection screen entirely redundant and illogical.

Final answer

Article 32(3) of Commission Delegated Regulation (EU) 2018/389 requires account servicing payment service providers (ASPSPs) that have implemented a dedicated interface to ensure that the interface does not create obstacles to the provision of payment initiation and account information services.

As clarified in paragraphs 6, 7 and 15 of the EBA Opinion on obstacles under Article 32(3)of the RTS on SCA and CSC (EBA/OP/2020/10), in a redirection or decoupled approach the interaction between the payment service user (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 or PIS journey should not include unnecessary steps or require the PSU to provide unnecessary or superfluous information compared to the way in which the PSU can authenticate when directly accessing their payment accounts or initiating a payment with the ASPSP.

In circumstances where, when PSUs access their accounts directly via the ASPSP’s customer interface, authentication is performed without requiring the PSU to manually select a client segment, such a step introduced in a redirection journey does not appear necessary for the purpose of authentication. As such a step does not appear necessary and results in additional friction in the AIS or PIS journey compared to the way in which the PSU can authenticate when directly accessing their payment accounts or initiating a payment with the ASPSP, this constitutes an obstacle within the meaning of Article 32(3) of the RTS. 

Cosmin Cosma, President of the Romanian Fintech Association (RoFintech), welcomes these clarifications, which he considers highly important because they explain how banks should handle payment flows:

„These clarifications are extremely important, as they provide much-needed guidance in a field that is crucial for creating an alternative payment experience comparable to card payments, through modern payment methods based on open banking.”