Articles 66(4)(c) and 67(3)(b) of Directive (EU) 2015/2366 (PSD2) require Account Servicing Payment Service Providers (ASPSPs) to treat payment orders and data requests transmitted through the services of payment initiation service providers (PISPs) and account information service providers (AISPs), respectively, “without any discrimination other than for objective reasons” compared to those transmitted directly by the payment service user (PSU).

Q&As 4141, 5516 and 4783 clarified that, when initiating a payment within the same session in which strong customer authentication (SCA) was performed to access account data, one of the authentication elements used during account access may be reused in accordance with Article 4 of Commission Delegated Regulation (EU) 2018/389 (the Delegated Regulation). This is permitted provided that the second element of SCA is applied at the time of payment initiation and the dynamic linking requirement under Article 97(2) PSD2 is fulfilled.

The submitter refers to a specific scenario involving a combined AIS and PIS journey using redirection, where the account is chosen on the third-party provider (TPP)’s domain and not on the ASPSP’s domain.

In the scenario where the PSU first authenticates with the ASPSP to give access to the TPP to the list of accounts, the PSU then selects the account on the TPP’s domain, and is subsequently redirected to the ASPSP to authenticate the payment, requiring two SCAs (one for granting access to the TPP to the list of accounts, and the other for initiating the payment) would not constitute an obstacle under Article 32(3) of the Delegated Regulation. This is in line with the clarifications provided in paragraph 28 of the EBA Opinion on obstacles under Article 32(3) of the Delegated Regulation (EBA/OP/2020/10).

In this case, if the ASPSP permits reuse of one SCA factor, such as a possession element or a knowledge element as envisaged for example in the scenario described in the Q&A 2018_4141, in its direct customer interface, it should, in principle, offer equivalent functionality when the PSU uses a TPP, in accordance with Articles 66(4)(c) and 67(3)(b) of PSD2, provided that it is technically feasible to maintain the session established by the ASPSP with the PSU across both AIS and PIS steps. Conversely, if maintaining session continuity is not technically feasible or would conflict with Article 35 of the Delegated Regulation, this may constitute an objective reason under Articles 66(4)(c) and 67(3)(b) of PSD2 for requiring full SCA twice in a combined AIS and PIS journey, even if reuse is allowed when the PSU accesses their payment account directly. Such objective reasons must be demonstrable and assessed on a case-by-case basis.

In a different scenario where the TPP has already obtained from the ASPSP the list of accounts, the PSU selects the account on the TPP’s domain to initiate a payment and the TPP sends the payment order to the ASPSP with all the required details, including the IBAN of the payer, only one SCA should be required to initiate the payment. As clarified in paragraphs 24-26 of the EBA Opinion on obstacles under Article 32(3) of the Delegated Regulation (EBA/OP/2020/10), in a PIS-only journey, 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, would constitute an obstacle under Article 32(3), unless the ASPSP has duly justified security arguments why two SCAs would be needed in such case, such as suspicion of fraud for a particular transaction.