EBA E-mail alert 12 June, 2026

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?

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"?

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?

Under PSD2, when a PISP initiates a standing order on behalf of a PSU, the ASPSP generally communicates only the result of the standing order setup (i.e. whether the standing order has been accepted or rejected).

In practice, PISPs typically do not receive information on the execution status of each individual payment transaction carried out under that standing order, even though each execution constitutes a separate payment transaction under PSD2. This creates uncertainty as to whether ASPSPs are required to make this information available to PISPs in the same way it is made available to PSUs in online banking channels.

Should ASPSPs provide PISPs with information on the execution status (e.g. executed or rejected) of each individual payment transaction executed under a standing order initiated by a PISP?

In the context of Article 32 of the RTS (Commission Delegated Regulation (EU) 2018/389), are ASPSPs required to provide PSUs with access to support channels (e.g., helpdesk, chat, telephone) within redirected authentication and authorisation interfaces for payment initiation, at a level equivalent to that in their standard online banking interfaces?

Additionally, could you please clarify whether the absence of such support channels in the redirected payment initiation interface constitutes a functional obstacle under paragraph 3 of Article 32?

When an ASPSP provides a PSU, through its online banking channels, with specific information on the reason for the rejection of a payment order, in accordance with Article 36(1)(b) of Commission Delegated Regulation (EU) 2018/389, should that same information also be provided to the PSU via the interface made available for a payment initiation order, whether through a decoupled or redirection flow? Furthermore, should that information also be communicated to the PISP through the dedicated interface?