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

Safeguarding with a credit institition in a third country

May a PI authorised and operating in an EU Member State use a credit institution based in a third country (e.g. UK) for the purpose of safeguarding funds in accordance with Art. 10(1)(a) of PSD2?

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

PISP payment order cancellation due to fraud prevention reasons

Due to fraud prevention reasons, could an ASPSP (Account Servicing Payment Service Provider) block a payment order initiated through a PISP (Payment Initiation Service Provider) despite having informed the PISP immediately upon authentication, that the payment was going to be executed (i.e., after having provided the PISP with the code ACSC (AcceptedSettlementCompleted) under the Berlin Group Standard)? In that scenario who should bear the liability if the payment is not executed but, nonetheless, the payee delivered the good or service promptly after being informed by the PISP of the successful initiation of the payment?Would the answer be different if the ASPSP had simply confirmed the sufficiency of funds as stated in the EBA Opinion on the implementation of the RTS on SCA and CSC (EBA-Op-2018-04)? 

  • 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

Multi-licensed entity capital requirement

Should a payment institution that also has a crowdfunding license meet the capital requirements of both authorizations in aggregate?

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

Exchange rate mark-ups part of 'all charges payable'/'currency conversion charges'

Is an exchange rate mark-up (the difference between the interbank rate and the exchange rate offered by the PSP to its PSUs) to be considered as part of ‘all charges payable’ as per PSD2 and the ‘currency conversion charges’ as per CBPR2 prior to the initiation of the payment? How should PSPs disclose this in the payment flow?

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

Consideration of own funds requirements as a comparable guarantee to the PII

Would it be acceptable to consider, has a possible comparable guarantee, an increase of own funds’ requirements, in an amount corresponding to the minimum monetary amount calculated in accordance with the EBA’s tool, while ensuring that this amount would be fulfilled with highly liquid assets?

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

Information provided to the payee on individual payment transaction

If a framework contract includes a condition on providing all required information to the payee at least once a month, is the payment service provider still obliged to provide the information to the payee after the execution of individual payment transaction? Or providing monthly information is enough and provision of information separately about each individual transaction is not required anymore?

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

Provision of the "acquiring of payment transactions" payment service in the EU

Please provide your opinion on whether the payment service – acquiring of payment transactions on an EU webshop – can be provided by a payment service provider from a third country. Please refer to Q&A 4233.

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

Card data (PAN) to be returned in AISP calls

Does the ASPSP have to return the card number (PAN) attached to a fetched payment account in case the user can access this data during a standard session with its ASPSP in the direct internet banking interface? In case of "YES", does the TPP that is fetching this data have to be PCI DSS certified, since this data has to be encrypted based on the PCI DSS requirements? Moreover, could be the "card number (PAN)" considered sensible, since it could be potentially used for fraud?

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

What is the difference between payment account, e-money account and a bank account (account held at the credit institution) in terms of allowed transactions? Is it possible to hold funds on a payment account to make future payment transactions?Is it possible to receive the salary on a payment account, if this account is not an e-money account or an account held by a credit institution, which constitute a deposit or other repayable fund?

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

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