Search for Q&As

Enquirers can use various factors to search for a Q&A:

  • These include searching by the Q&A ID; legal reference, date submitted, technical standard / guideline, or by keyword if known.
  • Searches can be extended to more than one legal act, topic, technical standard or guidelines by making multiple selections (i.e. pressing 'Ctrl' on your keyboard, and selecting the relevant ones from the drop-down lists by left mouse-click).

Disclaimer:

Q&As refer 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.

Please note that the Q&As related to the supervisory benchmarking exercises have been moved to the dedicated handbook page. You can submit Q&As on this topic here.

List of Q&A's

Obstacles to the payment initiation service

Can the impossibility for a Third Party Provider (TPP) to add new beneficiaries for payment initiation, coupled with the impossibility to initiate payments for unregistered beneficiaries, be considered as an obstacle? Besides, as a subsequent question, are delays up to 48 hours in the registration of new beneficiaries an obstacle?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

Account Data required by a ASPSP to execute a payment order via a PISP

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.)?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

Compliance of (1) card data (2) SMS OTP and (3) EMV 3DS behaviour-based inherence as an authentication information with the requirements of PSD2 and RTS on SCA

Could the use of (1) card data (2) SMS One Time Password (OTP) and (3) Europay, MasterCard, Visa (EMV) 3-D secure (3DS) behaviour-based inherence information as an authentication solution be considered compliant with the PSD2 and RTS on strong customer authentication and secure communication requirements?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

TPP access only with PSU involvement

Can a Payment Service User (PSU) allow a Third party provider (TPP) the access to his account only if he is involved?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

Usage of SMS for dynamic linking

Please clarify whether payment information and an authentication code sent via SMS to a mobile phone complies with the requirements for Dynamic Linking as defined in Article 5 of the RTS, and in particular paragraph 5.2.

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

Exemption of secure corporate payment processes and protocols

Is the exemption of applying strong customer authentication, in respect of legal persons initiating electronic payment transactions through the use of dedicated payment processes or protocols that are only made available to payers who are not consumers applicable to both payment initiation and account information services? Or, is it solely applicable to payment initiation service?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

Perform SCA by reusing an element used in an authentication exempted from SCA

When an element is used to access the payment account online, in the case the Payment Service Provider (PSP) is allowed not to apply Strong Customer Authentication (SCA) (only applying a single-factor authentication : login + password), is it possible to reuse this element to perform SCA to authenticate a transaction ?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

Transport and parking exemption for parking and electric vehicle charging

Does the transport and parking exemption under Article 12 of Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication apply to transactions at unattended terminals for the payment of a parking fee that includes electric charging?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

Payment Initiation Scope and Trusted Beneficiaries

Should non-payment accounts be listed as trusted beneficiaries where they are exempted from Strong Customer Authentication (SCA) as Beneficiaries of a Payment Transaction?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

Using Trusted Beneficiary Lists to Auto Reject PISP Transactions

Is an Account Servicing Payment Service Provider (ASPSP) able to block a Payment Initiation Services Provider (PISP) transaction before attempting Strong Customer Authentication (SCA) if the beneficiary account does not appear in the Payment Services User (PSU)'s regular payee list/trusted beneficiary list?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

Strong Authentication

Is one time passcode (OTP) Mail considered as a "Strong Customer Authentication" under Regulation (EU) 2018/389 – RTS on strong customer authentication and secure communication?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

Ability of static card data to be considered a possession factor?

Can static card data (Card number PAN + cardholder name +Exp. Date + static CVV2/CVC2) be considered a as a possession factor, and if so: is it strong enough to be a valid factor in a 2-factor Strong customer authentication (SCA)?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

SMS OTP and credit card as a two authentication factor

Can we consider Credit card and One Time Password (OTP) SMS as a two authentication factor ? 

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

Authorisation for the provision of PIS and AIS on behalf of other legal entities belonging to the same corporate group / Autorizzazione ad offrire servizi di PIS e AIS per conto di altre Legal Entity appartenenti allo stesso Gruppo societario

In a corporate group which is not listed in the register of banking groups and in which there is both an electronic money institution and a credit institution, can the electronic money institution offer payment initiation services (PIS) and account information services (AIS), including on behalf of the group’s credit institution that also provides the same service? Must the electronic money institution as a service provider offering PIS and AIS to clients of the group’s credit institution provide its own certificate, the group certificate, or the credit institution’s certificate to the other account servicing payment service providers (ASPSPs)? Or, as it is merely a service provider, is it the credit institution’s certificate that should be displayed? Can a corporate group request a group certificate to provide to the other ASPSPs and/or third party providers (TPPs)? *** IT:  In un Gruppo societario, che non è iscritto al registro dei Gruppi Bancari e al cui interno sono presenti sia un Istituto di moneta elettronica che un Ente creditizio, l’Istituto di moneta elettronica può offrire i servizi di PIS e AIS, anche per conto dell’Ente creditizio del Gruppo in qualità di fornitore del servizio stesso? L’Istituto di moneta elettronica che offre i servizi di PIS e AIS ai clienti dell’Ente creditizio di Gruppo, in qualità di fornitore del servizio, si deve presentare verso gli altri ASPSP con il proprio certificato, con il certificato di Gruppo oppure con il certificato dell’Ente creditizio? O in quanto mero fornitore del servizio, il certificato da esporre è quello dell’Ente creditizio? Un Gruppo societario può richiedere un certificato di Gruppo per presentarsi alle altre ASPSP e/o TPP?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

Losses due to fraud per liability bearer / Perdite dovute a frode per portatore di responsabilità

Please clarify the requirement in guideline 1.6 (b) of the EBA Guidelines on fraud reporting under PSD2 with regard to recognising losses due to fraud per liability bearer. *** IT: Si chiede cortesemente di chiarire il requisito espresso all'interno dell'orientamento 1.6(b) in materie di obblighi di segnalazione delle perdite dovute a frode per portatore di responsabilità

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: EBA/GL/2018/05 - Guidelines on fraud reporting under PSD2 (amended by EBA/GL/2020/01)

SCA profiles and multiple-use of devices

Can multiple users use the same device (i.e. smartphone) and have different strong customer authentication (SCA) profiles on the same device?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

Relying on vendor mechanisms processing the biometric data for strong customer authentication; Multiple fingerprint samples stored on a mobile device and used for purpose of user authentication.

Are the obligations of a payment service provider (PSP) laid down in the Article 8 of RTS on strong customer authentication and secure communication fulfilled in case the biometric credentials of customer are stored at the device level and the strong customer authentication itself is processed by the mobile device? In this context, are the obligations of the PSP laid down in Article 8 and 24 of RTS on Strong Customer Authentication fulfilled in case the mobile device stores multiple fingerprint samples for user authentication?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

Delayed or deferred PIN for wearable devices

Is the PIN entered when the cardholder takes on wearable device on, still valid as a knowledge element for one or several transactions later the same day, if it can be ensured that the device has not been taken off?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

Whitelisting

Will a clearing house for distribution be enabled to facilitate the on-going maintenance of the whitelisting process?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

Failed Authentication Code

Please clarify under what circumstances Article 4 Paragraph 3(a) of the Regulation (EU) 2018/389 – RTS on SCA and SC might it be impossible to apply in remote authentication where SMS based One time passwords (OTPs) are used as the authentication method.

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication