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.

Final Q&As Q&As under review Rejected Q&As Archived Q&As All Q&As

List of Q&A's

Applicability of SCA to wallet solutions

Is a single Strong Customer Authentication (SCA) sufficient for transactions performed in staged wallet solutions? Does the funding transaction qualify as a transaction initiated by the payee only, which does not require SCA by the Account Servicing Payment Service Providers (ASPSP)?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Not applicable
  • ID: 2018_4133
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 21/05/2021

Payee-initiated transactions with irregular period or variable amount

Please clarify whether standing agreements between a customer and a merchant resulting in subsequent billing (irregular or otherwise) to be payee-initiated transactions, and as such excluded from the SCA requirement.

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Not applicable
  • ID: 2018_4131
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 01/03/2019

Trusted Beneficiary exemption – Management of the exemption, information flows between PSPs in the payment transaction

For the seamless management of the Article 13 exemption, should ASPSPs provide a feature that: 1) informs Acquirers and PISPs whether the payee is included in the payer’s list of trusted beneficiary; and 2) allows Acquirers and PISPs to suggest new entries or amendments to a payer’s list of trusted beneficiaries?

  • 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
  • ID: 2018_4128
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 25/01/2019

Application of Transaction Risk Analysis (TRA) exemption – Real time risk analysis / monitoring

Is it acceptable if a payment service provider (PSP) looking to apply the TRA exemption makes a best effort using the information available to them to identify that none of the six individual factors mentioned in Article 18(2)(c) of the Commission Delegated Regulation 2018/389 are applicable, but does not have to actually identify non-applicability of all of these factors to be able to use the TRA 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
  • ID: 2018_4127
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 07/06/2019

Explicit consent required by the ASPSP from the PSU to enable the PSU to use the services provided by TPPs / Consenso esplicito richiesto dall’ASPSP al PSU per consentirgli di avvalersi dei servizi prestati dai TPP

May the requirement by the ASPSP for the PSU to give additional explicit consent in order to be allowed to use the services provided by TPPs, in addition to the consent given by the PSU to the TPP, be considered an ‘obstacle to the provision of payment initiation services and of account information services’ pursuant to Article 32 of the RTS?***IT:Puo’ un ulteriore consenso esplicito richiesto dall’ASPSP al PSU per consentirgli di avvalersi dei servizi prestati dai TPP, in aggiunta al consenso prestato dal PSU al TPP, essere considerato un “ostacolo alla prestazione dei servizi di disposizione di ordine di pagamento e di informazione sui conti” ai sensi dell’Articolo 32 del RTS?

  • 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
  • ID: 2018_4123
  • Topic: Other topics
  • Date of submission:
  • Published as final Q&A: 11/01/2019

Exemptions from Strong Customer Authentication (SCA): trusted beneficiaries

Should a Payment Service User (PSU) recreate a list of trusted beneficiaries that was already approved in accordance with the EBA Guidelines on the security of internet payments?

  • 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
  • ID: 2018_4120
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 21/12/2018

Sanctions list screening in the context of TPPs' services - risk management policy

Is the Account Servicing Payment Service Provider (ASPSP) obliged to recognise if a Third Party Payment Service Providers (TPP) is named on a sanctions list or even take some actions when the TPP becomes a designated entity? How the prohibition of directly or indirectly making funds or economic resources available to designated persons and entities is defined in this context?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Not applicable
  • ID: 2018_4117
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 12/03/2021

Accumulated other comprehensive income in template C.01.00

Is the accumulated other comprehensive income in template C.01.00 the same amount than in row 090 in F.01.03? Is row 280 in F.01.03 also taken into account?

  • Legal act: Regulation (EU) No 575/2013 (CRR)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) No 680/2014 - ITS on supervisory reporting of institutions (repealed)
  • ID: 2018_4116
  • Topic: Supervisory reporting - COREP (incl. IP Losses)
  • Date of submission:
  • Published as final Q&A: 07/06/2019

IFRS 9 Transitional arrangements - Definition of ‘t’

How should “t” which is used in the formulas in paragraph 1 of Article 473a CRR be calculated?

  • Legal act: Regulation (EU) No 575/2013 (CRR)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Not applicable
  • ID: 2018_4113
  • Topic: Accounting and auditing
  • Date of submission:
  • Published as final Q&A: 03/08/2018

Data authentication standards

Does a non-remote card payment transaction with a secure, dynamic data authentication of the card (DDA or higher), based on ISO/IEC 7816 (for contact cards) and ISO/IEC 14443 (for contactless card) used with a static PIN meet the requirements of Article 4 of the RTS on 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
  • ID: 2018_4110
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 20/12/2019

Scope of ‘initiation of an electronic payment transaction’

Does a card payment transaction, authenticated with a signature at the point of sale, fall under the scope of Article 97 (I) (b) PSD2? Is there a difference if the signature is provided on a paper or on a signature pad (e.g. electronic signature pad or signature capture at a payment terminal)?

  • 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
  • ID: 2018_4108
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 20/12/2019

Clarification on whether a particular business model type constitutes the provision of an account information service as defined by Article 4 (16) of PSD2

Does a business model where the provider offers a service sending the account information to third parties (different from the payment service user)  (detail provided in the background) constitute the provision of an account information service, particularly as it is not proposed that the account information obtained will be given directly to the Payment Service User?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Not applicable
  • ID: 2018_4098
  • Topic: Authorisation and registration
  • Date of submission:
  • Published as final Q&A: 13/09/2019

API functionality

Does Article 64(2) of PSD2 limit the ability of Payment Initiation Service Providers (PISPs) to initiate a single payment transaction for immediate execution only?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Not applicable
  • ID: 2018_4096
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 21/01/2022

Irrevocability of a payment order initiated by a PISP

The EBA Opinion on the implementation of the RTS on SCA and CSC (EBA-Op-2018-04) contains a Table entitled “Main requirements for dedicated interfaces and API initiatives” and Row 9 refers to the possibility of “cancelling an initiated transaction in accordance with PSD2, including recurring transactions”. Please clarify that these requirements will not apply to single payment transactions initiated by Payment Initiation Service Providers (PISPs) for immediate execution?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Not applicable
  • ID: 2018_4095
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 21/01/2022

Category on which the covered part of exposures should be reported.

How to report the covered part of exposures under IRB approach ?

  • Legal act: Directive 2013/36/EU (CRD)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Draft ITS on Supervisory Reporting of Institutions (for benchmarking the internal approaches)
  • ID: 2018_4093
  • Topic: Supervisory reporting - Supervisory Benchmarking
  • Date of submission:
  • Published as final Q&A: 29/03/2019

Reporting of RWA* and RWA** in Template C.103 of the Benchmarking exercise.

How to report metrics RWA* and RWA** in Template C.103 of the Benchmarking exercise?

  • Legal act: Directive 2013/36/EU (CRD)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Draft ITS on Supervisory Reporting of Institutions (for benchmarking the internal approaches)
  • ID: 2018_4092
  • Topic: Supervisory reporting - Supervisory Benchmarking
  • Date of submission:

Reporting of exposures whose collateral type is (g) credit derivatives, (h) guarantees or (i) unfunded credit protection

How to report exposures whose collateral type is (g) credit derivatives, (h) guarantees or (i) unfunded credit protection?

  • Legal act: Directive 2013/36/EU (CRD)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Draft ITS on Supervisory Reporting of Institutions (for benchmarking the internal approaches)
  • ID: 2018_4091
  • Topic: Supervisory reporting - Supervisory Benchmarking
  • Date of submission:
  • Published as final Q&A: 29/03/2019

Does transaction monitoring need to be real time?

Article 2(1) of the RTS stipulates that "payment service providers shall have transaction monitoring mechanisms in place that enable them to detect unauthorised or fraudulent payment transactions…" and Article 2(2) explains the minimum requirements.However, Article 2 does not specify timing aspects of the transaction monitoring.Is it correct to conclude that the transaction monitoring described in Article 2 does not need to be real time?

  • 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
  • ID: 2018_4090
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 05/10/2018

Obligatory nature of the SCA and exemption based on transaction risk analysis

Does the exemption to the strong customer authentication (SCA) apply to any connection the payment service user (PSU) makes to his/her payment account(s), or only to the connections made through the use of third party processors (TPPs, such as AISPs or PISPs) via the interfaces (dedicated or not) set up by the bank with the TPPs, when a transaction risk analysis is performed and results on a low level of risk? That is, the connections made via the traditional online banking or the mobile application that the financial institution (the bank) provides to the final user are also eligible to a transaction risk analysis and, if a low level or risk is identified, apply exemption to the SCA? Or do the PSD2, and specifically the RTS on SCA and secure communication not apply to the traditional connections performed by the PSUs to their payment accounts via online banking or mobile application provided by the bank (ASPSP), and do they not mandate to apply transaction monitoring in such cases?

  • 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
  • ID: 2018_4089
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 19/10/2018

Timing of recognition of year-end profits in CET1 for the purpose of COREP reporting and Pillar 3 disclosure

What is the correct timing for the recognition of year-end profits in CET1 for the purpose of COREP reporting and Pillar 3 disclosure, in the case that a bank does not request prior permission of the competent authority for inclusion of interim or year-end profits in CET1 pursuant to Article 26(2) of the CRR?

  • Legal act: Regulation (EU) No 575/2013 (CRR)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) No 680/2014 - ITS on supervisory reporting of institutions (repealed)
  • ID: 2018_4085
  • Topic: Supervisory reporting - COREP (incl. IP Losses)
  • Date of submission:
  • Published as final Q&A: 15/05/2020