Question ID
2025_7675
Legal act
Directive 2015/2366/EU (PSD2)
Topic
Other topics
Article
n.a.
Paragraph
n.a.
Subparagraph
n.a.
COM Delegated or Implementing Acts/RTS/ITS/GLs/Recommendations
Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication
Article/Paragraph
36(1)(b)
Type of submitter
Other
Subject matter
Provision of rejection reasons for payment orders initiated via PISPs.
Question

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?

Background on the question

Article 36(1)(b) of Commission Delegated Regulation (EU) 2018/389 requires account servicing payment service providers (ASPSPs) to provide payment initiation service providers (PISPs) with “the same information on the initiation and execution of the payment transaction as that provided or made available to the payment service user (PSU)”. This requirement gives effect to the principles of transparency, non-discrimination and functional equivalence enshrined in Directive (EU) 2015/2366 (PSD2).

In redirection and decoupled authentication flows, the PSU temporarily interacts within the ASPSP’s environment. In this context, the ASPSP should display to the PSU specific and explicit information on the reason for the rejection of a payment order, in a manner equivalent to that which would be provided if the payment order had been initiated directly through the ASPSP’s own online banking channels.

However, in practice, while PSUs typically receive clear and specific information on the reasons for the rejection of a payment order through those channels (for example, “insufficient funds” or “transfer limit exceeded”), PISPs lack visibility as to whether the same information is actually displayed to the PSU via the interfaces made available for payment initiation. Moreover, some ASPSPs limit their communication to PISPs to a generic rejection status (such as the RJCT status code or similar), while refraining from providing PISPs with the specific reason for rejection that is communicated to the PSU through their online banking channels.

Submission date
Final publishing date
Final answer

Article 36(1)(b) of the Commission Delegated Regulation (EU) 2018/389, which largely reproduces Article 66(4)(b) of PSD2, states that the account servicing payment service provider (ASPSP) shall, immediately after receipt of the payment order, provide payment initiation service providers (PISPs) with the same information on the initiation and execution of the payment transaction that is provided or made available to the payment service user (PSU) when the transaction is initiated directly by the latter. These provisions relate to information that must be provided by the ASPSP to the PISP, not by the ASPSP to the PSU.

As regards information provided by the ASPSP to the PSU on the reasons for refusal of a payment order, Article 79(1) PSD2 provides that “[w]here the payment service provider refuses to execute a payment order or to initiate a payment transaction, the refusal and, if possible, the reasons for it […] shall be notified to the payment service user, unless prohibited by other relevant Union or national law. The payment service provider shall provide or make available the notification in an agreed manner at the earliest opportunity, and in any case, within the periods specified in Article 83”.

Therefore, the manner in which the ASPSP provides this information to the PSU and the timing of the notification need to comply with Article 79(1) PSD2. This means that it may not always be the case that the PSU receives such information immediately after receipt of the payment order. In addition, PSD2 does not impose that such information be provided to the PSU through the interface used for the payment initiation order itself, whether in a redirection or decoupled flow. Furthermore, in practice, the refusal of a payment order and the notification of the reasons for refusal will typically occur after the authentication of the PSU, as the ASPSP can generally determine whether to execute or refuse the payment order only once the authentication procedure has been completed.

As regards information provided by the ASPSP to the PISP, in accordance with Article 36(1)(b) of Commission Delegated Regulation (EU) 2018/389 and Article 66(4)(b) of PSD2, the ASPSP must, immediately after receipt of the payment order, provide the PISP with information on the reason for the rejection of a payment order if such information is provided to the PSU when the transaction is initiated directly by the latter. This is without prejudice to Q&A 2019_4601 which clarified that where the ASPSP is not aware, immediately after receipt of the payment order, whether the payment will be executed or not, it is not necessarily required to provide such information to the PISP at a later stage.

Status
Final Q&A
Answer prepared by
Answer prepared by the EBA.

Disclaimer

The Q&A refers to the provisions in force on the day of their publication. The EBA does not systematically review published Q&As following the amendment of legislative acts. Users of the Q&A tool should therefore check the date of publication of the Q&A and whether the provisions referred to in the answer remain the same.