Question ID
2019_4854
Legal act
Directive 2015/2366/EU (PSD2)
Topic
Strong customer authentication and common and secure communication (incl. access)
Article
66
Paragraph
4
Subparagraph
c
COM Delegated or Implementing Acts/RTS/ITS/GLs/Recommendations
Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication
Article/Paragraph
32
Name of institution / submitter
Banca d'Italia
Country of incorporation / residence
Italy
Type of submitter
Competent authority
Subject matter
Account Data required by a ASPSP to execute a payment order via a PISP
Question

In the context of Payment Initiation Service (PIS) where a Payment Service User (PSU) payment order is to be carried out, the Payment Initiation Service Provider (PISP) accesses the PSU e-banking account to require a payment. The PSU may: a) hold a single payment account to be debited or b) hold multiple payment accounts where only one of them is to be debited to finalize the payment order (in this case PSU has to select a payment account).

With reference to both use cases and in the presence of an Account Servicing Payment Service Provider (ASPSP)’s dedicated interface, may the PSU be obliged to digit the IBAN of the account to be debited each time she/he initiates a transaction? Is the PISP always required to report the account number to be debited in the payment request or may this parameter be managed bilaterally among ASPSP and PSU (e.g.: default payment account, drop-down selection menu during the strong customer authentication (SCA) procedure, communication over Out-of-Band (OOB) channels, etc.)?

Background on the question

In order to carry out a single payment, a PISP has to submit a payment initiation request with the payment data. Such a request, based on some current market standards, foresees at least the following mandatory parameters: amount, payee account number (IBAN) and “payer account number” (IBAN). As a consequence, the PSU have to digit her/his own payment account IBAN number (to be debited) in the PISP web page (or APP) in order to request the payment. This results in a user experience poorer and more complex than in the case of using the direct internet banking services. The impact is even worse in case of PSU accounts with multiple payment accounts: if a pure PISP is not allowed to request account details and the payment accounts list (see QA 2018_4188) it cannot propose to the user to make a selection from a drop-down menu (as in the case of direct Internet banking services). This function could be only supported by a combined Third Party Provider (TPP) (Account Information Service Provider (AISP)/PISP) that is allowed to request account details as AISP and then to initiate the payment as PISP.

This scenario could lead to a kind of discrimination of PIS against direct PSU payments, since in a normal online banking service the PSU is not required to digit the IBAN number of the payment account. Even in comparison with card payments,  the user experience would be worse, since the PSU would be obliged to digit her/his bank account number (IBAN) that is longer and more difficult to remind or retrieve than the card number (PAN).

In this scenario we can identify possible obstacles to the PIS services:

a) single payment account: in case of a PSU account with a unique payment account, the payment account number information is a redundant information, because the payment required by the PSU has to be debited, with no choices, on the unique payment account; this required but useless redundancy is to be interpreted as an obstacle.

b) multiple payment accounts: in case of a PSU account with multiple payment accounts, there is no objective reason to not make available the list of PSU’s IBANs in order to facilitate the selection.

Submission date
Final publishing date
Final answer

The EBA clarified in paragraph 34 of the EBA Opinion on obstacles under Article 32(3)of the RTS on SCA and CSC (EBA/OP/2020/10) 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”.

In addition, as clarified in paragraphs 35 and 36 of the Opinion, there are different ways to avoid payment service users (PSUs) having to input manually their account details in a payment initiation service journey.

Paragraph 35 specifies that one option is for the account servicing payment service provider (ASPSP) to enable payment initiation service providers (PISPs) that have also an authorization to provide account information service and that have obtained the consent of the payment service user (PSU) as required under Article 67(2)(a) of Directive 2015/2366/EU (PSD2), to retrieve the list of all the PSU’s payment accounts via the interface, thus enabling the PSU to select the account on the PISP’s domain.

Further, paragraph 36, clarifies that if the ASPSP has implemented a redirection or decoupled approach, and the PISP does not transmit to the ASPSP the relevant account details, the ASPSP could enable the PSU to select the account(s) on the ASPSP’s domain during the authentication procedure with the ASPSP, in a way that is no more complicated than the way in which the PSU can select the account(s) when directly initiating a payment with the ASPSP. For example, ASPSPs may consider offering a drop-down list for the PSU to select the account(s), or prepopulate the account details if the PSU has only one account with the ASPSP.

Accordingly, ASPSPs should not reject the requests received from PISPs in a redirection or decoupled approach, simply because the PISP has not transmitted to the ASPSP the relevant account details.

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.