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

The definition of payment services and in particular the definition of execution of payment transaction in relation to netting centers

1. Is an (international) non-profit association, acting as netting centre in the framework of a multilateral netting agreement entered into between its members, that receives and forward funds to and from its members through a bank account opened in its name deemed to carry out payment services falling within the scope of Article 4(3) of Directive (EU) 2015/2366 of the European Parliament and of the Council of 25 November 2015 on payment services in the internal market, amending Directives 2002/65/EC, 2009/110/EC and 2013/36/EU and Regulation (EU) No 1093/2010, and repealing Directive 2007/64/EC ('PSD2') (e.g. the execution of payment transaction or money remittance)?2. If the netting center is deemed to carry out payment services, can the netting centre rely on exclusion of Article 3(n) of PSD2, i.e. 'payment transactions and related services between a parent undertaking and its subsidiary or between subsidiaries of the same parent undertaking, without any intermediary intervention by a payment service provider other than an undertaking belonging to the same group'?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Not applicable

Exclusion of cash withdrawal services from PSD2

If a provider offers cash ATM withdrawal services, not acting on behalf of one or more card issuers but rather through an agreement with the main payment circuits, shall this type of provision be considered exempt from the PSD2?  

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Not applicable

Revocation of ASPSP's Exemption from the Contingency Mechanism due to Prolonged Service Disruption

In a scenario where an incident lasting more than two consecutive weeks preventing Payment Service Users (PSUs) from initiating their payments through a dedicated interface, considering that the Account Servicing Payment Service Provider (ASPSP) has an exemption from the contingency mechanism under Regulation (EU) 2018/389, and the National Competent Authority (NCA) has been notified about the incident: Should the National Competent Authority (NCA) revoke the ASPSP's exemption from the contingency mechanism?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: EBA/GL/2018/07 - Guidelines on the exemption from the contingency mechanism under Regulation (EU) 2018/389

Criteria for selecting the operations to be included in the calculation of fraud rates for the transaction risk analysis (TRA) exemption

Which of the following would be the correct temporal criterion for selecting the unauthorized transactions to be included in the numerator of the fraud rates calculated for the transactions risk analysis (TRA) exemption? a) the transaction date, i.e., the date on which the transaction was executed regardless of the date on which it is classified as unauthorized or fraudulent b) the registration date, i.e., the date on which the transaction is registered as unauthorized or fraudulent regardless of the date on which it was carried out 

  • 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

Secure corporate payment processes and protocols and inactivity time period

May the period time of inactivity required by the (EU) 2018/389 - RTS on strong customer authentication and secure communication (hereinafter: RTS on SCA & CSC) Article 4 (3) (d) be changed from 5 minutes to 20 minutes if the exemption based on Article 17 of RTS on SCA & CSC has been granted by the competent authority to the Payment service provider?

  • 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

PISP’s access to payable charges applied by the ASPSP on the PSU’s initiated payment via the ASPSP’s dedicated interface

Shall the account servicing payment service provider (ASPSP) make the transaction fees accessible to payment initiation service providers (PISPs) via the dedicated interface?

  • 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

Payee-initiated transactions with irregular period or variable amounts for account payments.

Please clarify whether payee-initiated account transactions available in Account Servicing Payment Service Providers (ASPSPs)’ online banking channels are considered discriminatory under PSD2 when not available in the PSD2 Application Programming  Interfaces (APIs). 

  • 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

Mobile Banking Services and SCA in the same app

We use a mobile app, software installed in a separate sandbox on a multi-purpose device, for the elements of strong customer authentication. Is it correct to assume that Article 9 (in COMMISSION DELEGATED REGULATION (EU) 2018/ 389) does not prevent us from offering mobile banking services through the same app?

  • 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

Fraud reporting

How we should treat the transactions that are initiated by PSP (for example refunds, chargebacks, etc.), but those transactions are related to cardholder's actions.

  • 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)

Eligibility of communication by AISPs with ASPSP throughout two access interfaces in parallel

Question no 1: Do art. 30(1), art. 31 and art. 33 of the Commision Delegated Regulation (EU) 2018/389 of 27 November 2017 supplementing Directive (EU) 2015/2366 of the European Parliament and of the Council with regard to regulatory technical standards for strong customer authentication and common and secure open standards of communication (”RTS”) should be interpreted in that manner, that in scenario, where account servicing payment service provider (”ASPSP”) has introduced a so-called dedicated interface within a meaning of art. 31 RTS, which meets requirements provided for in art. 32 and 33 RTS, than ASPSP has a right and it is up to ASPSP’s sole discretion, whether, for purposes of communication with account information service providers (”AISPs”), to: make available to AISPs, in parallel, two access interfaces, as referred to in art. 31 RTS (i.e. dedicated interface and interface made available to the payment service users for the authentication and communication with their ASPSPs); or make available to AISPs only dedicated interface (without prejudice to, among others, contingency measures set forth in art. 33 RTS)? Question no 2: If answer to question no 1 is that in scenario of introduction by ASPSP of dedicated interface, ASPSP has a right and it is up to ASPSP’s sole discretion to make available to AISPs, in parallel, two access interfaces, as referred to in art. 31 RTS (i.e. dedicated interface and interface made available to the payment service users for the authentication and communication with their ASPSPs), does this mean that AISPs, with observation of further requirements set forth in art. 30, art. 34 and art. 35 RTS, might communicate with this ASPSP, in parallel, throughout both access interfaces? Question no 3: If answer to question no 1 is that in scenario of introduction by ASPSP of dedicated interface, ASPSP has no right and it is not up to ASPSP’s sole discretion to make available to AISPs, in parallel, two access interfaces, as referred to in art. 31 RTS, i.e. a contrario ASPSP is allowed to make available to AISPs only dedicated interface (without prejudice to, among others, contingency measures set forth in art. 33 RTS), does ASPSP is under obligement to engange necessary and proportional measures, including technical measures, for AISPs to communicate with ASPSP only via dedicated interface, i.e. with exclusion of interface made available to the payment service users for the authentication and communication with their ASPSPs? Question no 4: If answer to question no 1 is that in scenario of introduction by ASPSP of dedicated interface, ASPSP has no right and it is not up to ASPSP’s sole discretion to make available to AISPs, in parallel, two access interfaces, as referred to in art. 31 RTS, i.e. a contrario ASPSP is allowed to make available to AISPs only dedicated interface (without prejudice to, among others, contingency measures as set forth in art. 33 RTS) but nevertheless ASPSP has not engange necessary and proportional measures, including technical measures, for AISPs to communicate with ASPSP only via dedicated interface, i.e. with exclusion of interface made available to the payment service users for the authentication and communication with their ASPSPs, does this fact in any measure reflects AISPs right to communicate with this ASPSP throughout both access interfaces, or whether AISPs should undertake any additional actions, and if yes, what kind of actions?

  • 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

Trusted Beneficiaries

Please clarify whether under Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication (hereinafter: RTS on SCA & CSC) is it allowed to use the same SCA element to authorize a payment and at the same time (using the same session ID) approve (technically using by a checkbox) the payee as a trusted beneficiary? If it is allowed, the payment service user (hereinafter: PSU) shall be informed (prior to authorisation) by an approval SCA element (SMS) about the payment execution and about modifying the list of the trusted beneficiaries as well?

  • 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 from strong customer authentication

Do the revisions to Art.10 set out in Commission Delegated Regulation (EU) 2022/2360 of 3 August 2022 amending the regulatory technical standards laid down in Delegated Regulation (EU) 2018/389 as regards the 90-day exemption for account access mean that a payment service user or account information service provider is now limited to accessing only the account balance OR the transaction details for the last 90 days when availing of the revised exemption?

  • 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

App to app redirection with biometrics for PIS

Are ASPSPs required to offer redirected authentication with biometrics to users accessing their payment accounts through an AISP or initiating a payment through a PISP, if they offer redirected authentication with biometrics to users accessing accounts or initiating payments directly via the ASPSP?

  • 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

Service Downtime

The question refers to the case that an incident with a duration of two hours that disrupts transaction processing occurs around the daily cut off time of same-day transactions processing. Thus, the incident may be of a short duration, but as a result, transactions are booked one day later. Considering this example, what service downtime should the payment service provider (PSP) indicate in the PSD2 notification? Just the net time of the failure or the total time any payment service users are affected by delayed transactions, i.e. one day?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: EBA/GL/2021/03 - Guidelines on major incident reporting under PSD2 - repealing EBA/GL/2017/10

Period to be covered by statistics pursuant to Article 32(4) of Commission Delegated Regulation (EU) 2018/389

Which period should the statistics to be published by ASPSPs under Article 32(4) of Commission Delegated Regulation (EU) 2018/389 cover in total?

  • 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

Evidences / Records to be stored by account servicing payment service providers (ASPSP) for payment initiation service (PIS) and account information service (AIS) requests

Shall ASPSP keep record of PIS requests received through a PISP and evidences on the authenticity and execution of these payment transactions when SCA is managed by ASPSP ?  Shall ASPSP keep record of the consent of the PSU and also of the AIS requests received through an AISP ? For both evidences is there any specific retention period ?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Not applicable

Reading of the term "means of payment"

What are the 'means of payment' in the LNE Guidelines (guidelines 1.6 and 1.7)? Does the term refer to the technological level of a physical device or a digital carrier, which may accommodate several payment instruments, such as plastic card (chip or magnetic stripe), a mobile phone, a wallet, an app, a wearable, a tablet, a PC or even a specific storage location on an external server? Please provide examples of 'other means of payment' that are relevant in practice from the EBA's perspective. How is the definition of payment instrument according to Article 4(14) PSD2 to be read in the context of the LNE Guidelines? Is the interpretation of the adjective “card-based” (in combination with means of payment) in line with the same adjective in combination with payment instruments according to Article 2(20) of Regulation (EU) 2015/751 (“IFR”)?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: EBA/GL/2022/02 - Guidelines on the limited network exclusion

SCA for token replacement

Is SCA required for the replacement of a tokenized card happening in the background without any ‘action by the payer’ under Article 97(1)(c) PSD2 in the following cases: Expiry of the token and update of the token Replacement of the card, and the new card has a different BIN/Account Range (e.g., for product graduation, such as standard to gold, or simple BIN management) and/or different functionalities Technical and/or configuration changes to the issuer’s BIN configuration (such as migrating from 6 to 8 digit BINs) In all these cases, the existing tokenized credentials have been initially associated with SCA to the user under Article 24(2)(b) RTS, and this is solely a technical replacement of the token. credentials have been initially associated with SCA to the user under Article 24(2)(b) RTS, and this is solely a technical replacement of the token.

  • 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

SCA applicability / Application of SCA at tokenisation stage

Does the authentication to unlock the mobile device count as one of the elements of strong customer authentication when a payment service user is tokenising a card on an e-wallet solution such as Apple Pay?

  • 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

Application of SCA to issuing a payment instrument and tokenisation

Is strong customer authentication (SCA) required when a Payment Service Provider (PSP) issues a payment instrument or creates a token?

  • 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