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

Clarification on the use of PSU-linked tokens in payment initiation services under the RTS

In the context of payment initiation services, we would appreciate clarification from the EBA as to whether an ASPSP may require a PISP to use a specific token replacing the PSU’s online banking credentials, and whether such token must be reused by the PISP across the different stages of the payment order, in particular at the payment initiation stage and for subsequent query following the execution of the payment order. Furthermore, we would welcome clarification on the conditions under which this practice would be compatible with the provisions of Commission Delegated Regulation (EU) 2018/389.

  • 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

Execution of an authorized payment instruction made conditional on manual user redirection

If an Account Servicing Payment Service Provider (ASPSP) makes the execution of a payment instruction, already successfully authorized via Strong Customer Authentication (SCA) in its app, conditional on the Payment Service User (PSU) subsequently manually returning from the ASPSP's authentication app back to the Third Party Provider's (TPP) environment, does this condition constitute an obstacle under Article 32(3) of the 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

Obstacle assessment of requiring multiple manual checkboxes for a single AIS consent

Does the practice of an ASPSP requiring a PSU to manually tick multiple, separate checkboxes for different categories of account data in order to grant a single consent for an Account Information Service (AIS) constitute an obstacle under Article 32(3) of the RTS, by adding unnecessary steps and friction to the user journey?

  • 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

Obstacle assessment of requiring an additional SCA for PIS within an existing authenticated AIS session

If a Payment Service User (PSU) initiates a payment (PIS) immediately after establishing a session for an Account Information Service (AIS) (for which SCA has already been performed), does the ASPSP's requirement for an additional, separate SCA—such as the need to fully log in to the mobile banking app before the payment confirmation screen is displayed—solely to access the payment function (and preceding the dynamic linking SCA) constitute an obstacle under Article 32(3) of the 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

Obstacle assessment of an ASPSP offering only web redirection to TPPs while a superior native app authentication method exists for its direct users

Does an Account Servicing Payment Service Provider's (ASPSP) decision to offer only a web-based redirection for Third Party Provider (TPP) initiated journeys constitute an obstacle under Article 32(3) of the RTS, if that ASPSP also makes available a more convenient, direct authentication procedure in its native mobile application for its Payment Service Users (PSUs) when they access their accounts directly?

  • 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

Supervisory obligations of NCAs under Article 32(2) of Commission Delegated Regulation (EU) 2018/389

Article 32(2) of Commission Delegated Regulation (EU) 2018/389 states that competent authorities shall monitor the interfaces, the indicators and subject them to stress testing. We are seeking clarification on the interpretation of this provision. In particular, we would appreciate guidance on the EBA’s expectations regarding the scope and nature of NCAs’ monitoring of these interfaces, including the assessment of their operational performance and reliability, as well as the conduct of stress tests, to ensure that the requirements of Article 32(1),that dedicated interfaces shall maintain the same level of availability and performance as the ASPSP’s own online channels, are effectively met.

  • 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 ASPSPs to comply with standardized communication protocols under Article 30(3) of Commission Delegated Regulation (EU) 2018/389

Under Article 30(3) of Commission Delegated Regulation (EU) 2018/389, ASPSPs are required to follow communication standards issued by international or European standardisation organisations.In this context, we seek clarification on whether, when an ASPSP has chosen to adopt a recognized communication standard issued by a European or international standardisation body (such as ISO 20022) for its PSD2 interfaces, the standard is expected to be applied consistently and in accordance with its specifications across all such interfaces, regardless of internal documentation or subsequent clarifications issued by the ASPSP, which may reflect internal implementation approaches rather than the standard itself.

  • 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

Introduction of additional mandatory steps or redirections in PISP payment initiation flows

In accordance with Article 32(3) of the RTS on SCA and CSC, may an ASPSP impose mandatory additional steps or redirections (pre-step) in a redirection-based payment initiation flow through a PISP, where such steps or redirections do not form part of the payment initiation process experienced by the PSU when using the ASPSP’s own mobile or online channels?

  • 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 general requirements of Chapter 6 of the Regulation (EU) No 575/2013 regarding the definition of own funds

Does the definition of „own funds“ in Article 4(46) of PSD2 refer to the definition of „own funds“ as defined in point 118 of Article 4(1) of Regulation (EU) No 575/2013 only, or are Articles 26 - 88 of Regulation (EU) No 575/2013, in particular Articles 26 (3), 77 and 78 of Regulation (EU) No 575/2013, also refered to by Article 4(46) PSD2?

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

non-discrimination in implementing PSD2 for safeguarding mechanisms

The PSD2 includes important provisions regarding safeguarding accounts for payment institutions (PIs) and electronic money institutions (EMIs). These accounts shall be additionally protected by the credit institutions providing them so they should be free from seizure and the funds kept at them shall not be considered the property of a PI or an EMI in case of bankruptcy of the safeguarding account holder. These provisions have been transposed into the law of the Republic of Poland effective in December 2018. However, according to the transposition, these safeguarding accounts provide these protections (freedom from seizure and not being considered the property of the bankrupt holder) only to the Polish PIs and Polish EMIs (so called “home” PIs and EMIs).  The law has been so formulated that the safeguarding accounts opened in Poland for the non-Polish (yet EEA-based), properly notified to Poland PIs or EMIs do not enjoy these protections.  Is this the proper transposition of the PSD2 provisions of safeguarding accounts or is this the example of the incorrect transposition resulting in the market discrimination of the PIs and EMIs which are not based in Poland?

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

Definition of "Communication Standards" under Article 30.3

a) Is ISO 20022 considered the communication standard referenced in Article 30(3) of the Regulatory Technical Standards (RTS), Commission Delegated Regulation (EU) 2018/389? b) How should NCAs ensure that ASPSPs comply with these standards, in accordance with Article 30.6 of the 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

Clarification needed in dedicated Interfaces supervision

We seek clarification and insights into how competent authorities shall fulfill their responsibilities in line with Recital 23 and Article 32.2 of the Commission Delegated Regulation (EU) 2018/389, specifically regarding the supervision of payment initiation service's dedicated interfaces to ensure effective oversight and monitoring.

  • 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

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

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

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

requirements for professional experience of representatives and board members of EMIs

Dear Sir/Madam,    In the process of licensing an EMI, the management of the company aplying for a licese is required to have certain professional qualifications: experience, clean record, good reputation,etc... As PSD2 does not regulate this topic, each National Bank has set different requirments. The same pereon may be elidgible under the requirments of central bank of one country while not elidgible for another. Usually, the requirments are for banking and equivalent proffesional background and experience.  Profesionals with technology background (eg. Computer Science, blockchain, software development, AI, information management) are not elidgible. However technology is one of the main drivers of innovation and competitiveness in both banks and fintech.    In this regard, I have two questions:  1. Is EBA discussing any harmonisation of requirments for profesional experience of managing teams of EMIs to be enforced in a new updated PSD2? 2. If yes, does EBA consider allowing technology related profesionals to hold management possitions in EMIs?    Best regards,  Filip Mutafis  

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

Initial Capital

What is the initial capital requirement if a payment institution is providing: (a) any of the payment services as referred to in points (1) to (5) of Annex I and service (6) and (7). (b) any of the payment services as referred to in points (1) to (5) of Annex I and service (6) . (c) any of the payment services as referred to in points (1) to (5) of Annex I and service (7).

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

Publication of quarterly statistics, according to GL 3 of the “Guidelines on the conditions to benefit from an exemption from the contingency mechanism under Article 33(6) of Regulation (EU) 2018/389 (RTS on SCA & CSC)”

In what concerns the performance and availability statistics that ASPSPs need to make available on their websites in accordance to GL 3 of the “Guidelines on the conditions to benefit from an exemption from the contingency mechanism under Article 33(6) of Regulation (EU) 2018/389 (RTS on SCA & CSC)”, do ASPSPs need to disclose all their quarterly reports since the entry into production of their APIs? For instance, if the ASPSP made their API available in September 2019, does the ASPSP need to have all the reports online since then? If not, is there any recommended timeframe for the reports to be kept available online?

  • 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