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

Provision of external payroll accounting services to an employer

Does the activity of external payroll processing for an employer constitute a payment service under PSD2, if it consists of receiving funds for wages and related deductions (taxes, health and social insurance) in the payroll processor’s payment account from the employer, and transferring these to employees, tax authorities, insurance companies etc.? Would the answer change depending on whether the payroll processor  maintains an account separately for each employer?   

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

Credit

Does this credit qualify as consumer credit, exclusively available to individual consumers? Or can it also be extended to legal entities?

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

Legal requirement for ASPSPs to provide for cancellation of future dated pay-ments through its dedicated payment initiation services interface

Is there a legal requirement for ASPSPs to allow its PSU to cancel/revoke future dated payments via a payment initiation service provider, using the ASPSPs dedicated payment initiation services 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

Third party access to account attributes

In Norway there is a widely used scheme by which payees send out invoices containing structured payment information which is being used by the payee to match incoming payments with invoices. The information is in the form of a number defined by the payee. The number consists of up to 25 digits, including a control digit. The information flows all the way through the payment chain and back to the payee. The credit account number must be set up with attributes associated with it, according to scheme rules, which are defined jointly by the banks. The payee has to enter into an agreement with its bank in order to make use of the scheme. There is a nationwide registry covering all banks, containing information about agreements, accounts and attributes associated with each account. The banks have direct access to the registry. As and when the PSU (Payment Service User) keys in the invoice information, the bank checks in real time that what is being keyed in is correct according to information held in the registry. There is check that indeed the credit account is set up for the scheme. A control digit is checked, increasing the likelihood of a correct number being entered. If no number is keyed in, the PSU is told so, if the account is such that a number is required. While keypunching, the PSU is being informed there and then if the information is wrong such that the PSU may correct it. The bank will not accept the payment order unless it is pre-verified to pass the controls. Not so for TPPs (Third Party Provider). They are not granted access to the registry. The TPP does not know if the payment order will pass the controls. Not until payment initiation there is a check. This check is being performed by the bank, not by the third party. The TPP receives information from the bank about the outcome of the check. TPPs must revert back to the PSU and / or the payee, or the banks, and try to resolve any issues. There are costs associated with follow up and correction. PSD2 Article 66 number 4 letter (c) obliges ASPSPs to treat payment orders transmitted through the services of a payment initiation service provider without any discrimination other than for objective reasons, in particular in terms of timing, priority or charges vis-à-vis payment orders transmitted directly by the payer. Not having access to the registry puts the TPPs at a disadvantage, with a bearing on timing, as payments may be delayed and may become overdue. The banks' own payment services have direct access to the key payment information held in the registry, whereas third party payment services do not. The FSA of Norway seeks advice on whether this constitutes a discrimination according to PSD2 Article 66. Not having access to the registry puts the TPPs at a disadvantage. It leads to extra work for TPPs and others involved in the payment. Additional costs are being incurred. The FSA of Norway seeks advice on whether not giving TPPs access to the registry creates obstacles for TPPs as per Commission delegated regulation (EU) 2018/389 Article 32 number 3. Lastly, the FSA of Norway seeks advice on whether there are other relevant provisions in the regulation, and whether the principle of "level playing field" may apply in this case.

  • 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

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

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

Requirement for loan agents to register as payment service providers under EU's Second Payment Services Directive 2015/2366 ("PSD2").

I would like some clarification on Directive 2015/2366/EU (PSD2) Article 4 paragraphh 22 - Money remittance. If a firm performs administrative services (including but not limited to the calculation of interest/fees and principal owing between lenders and a borrower) and as part of this service is required to regularly transfer money between lenders and a borrower (no fee involved), does this qualify as money remittance? No fees are charged for the transfer of money.  

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

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

Interpretation of payment instrument

What devices or procedures can be considered as payment instrument as per Art. 4(14) of PSD2?

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

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

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

The SCA-Exemption for account access based on art. 10 of Regulation (EU) 2018/389 as amended by Regulation (EU) 2022/2360.

We require a clarification with reference to the art. 10 of Regulation (EU) 2018/389 as amended by Regulation (EU) 2022/2360, regarding the meaning of the sentence: “…provided that access is limited to one of the following items online…”.  Does it mean that the 180days exemption is not allowed in case the PSU requires at the same time and in the same request: i) balance and ii) transactions-list of her/his payment account?

  • 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

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

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)

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

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

Eligibility of communication by AISPs with ASPSP throughout interface used for authentication and communication with the ASPSP's payment services users in case of ASPSP’s exemption from the fall back mechanism

Question no 1:   Does a fact, that based on art. 33(6) RTS, given ASPSP was granted by competent authority with exclusion from the obligation to set up the contingency mechanism described under art. 33(4) RTS, means, that such exemption merely gives this ASPSP a right not to set up the contingency mechanism, and hence, this is up to ASPSP to enjoy and to follow this exclusion, or whether, in opposition, this exemption creates on ASPSP side obligation to bring this exclusion to life.   Question no 2:   Does a fact, that given ASPSP was granted by competent authority with exclusion from the obligation to set up the contingency mechanism described under art. 33(4) RTS, creates on AISP’s end any kind of obligation, for instance lack of right to communicate with ASPSP in question throughout interface made available to the payment service users for the authentication and communication with their ASPSPs.

  • 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