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.

Legal act

Topic

Article

COM Delegated or Implementing Acts/RTS/ITS/GLs/Recommendations

Answer prepared by

Period posted start

Period posted end

Publication start

Publication end

Keywords

Question ID

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

Export options

Select / deselect all results on this page

List of Q&A's

Ban imposed by certain national authorities on the use of the term “neobank” for payment institution

Does the divergence of positions among national authorities regarding the freedom to use the term "neobank" for payment institutions not compromise the consistent application of EU law in the banking sector and the objective of convergence of supervisory practices, and does it not hinder competition and the development of cross-border activities? 

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

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

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

Provision of rejection reasons for payment orders initiated via PISPs.

When an ASPSP provides a PSU, through its online banking channels, with specific information on the reason for the rejection of a payment order, in accordance with Article 36(1)(b) of Commission Delegated Regulation (EU) 2018/389, should that same information also be provided to the PSU via the interface made available for a payment initiation order, whether through a decoupled or redirection flow? Furthermore, should that information also be communicated to the PISP through 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

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

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

PSU support in dedicated and redirected interfaces.

In the context of Article 32 of the RTS (Commission Delegated Regulation (EU) 2018/389), are ASPSPs required to provide PSUs with access to support channels (e.g., helpdesk, chat, telephone) within redirected authentication and authorisation interfaces for payment initiation, at a level equivalent to that in their standard online banking interfaces? Additionally, could you please clarify whether the absence of such support channels in the redirected payment initiation interface constitutes a functional obstacle under paragraph 3 of Article 32?

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

Obligations of ASPSPs to inform PISPs about the execution status of individual payments executed under a standing order initiated via API.

Under PSD2, when a PISP initiates a standing order on behalf of a PSU, the ASPSP generally communicates only the result of the standing order setup (i.e. whether the standing order has been accepted or rejected). In practice, PISPs typically do not receive information on the execution status of each individual payment transaction carried out under that standing order, even though each execution constitutes a separate payment transaction under PSD2. This creates uncertainty as to whether ASPSPs are required to make this information available to PISPs in the same way it is made available to PSUs in online banking channels.   Should ASPSPs provide PISPs with information on the execution status (e.g. executed or rejected) of each individual payment transaction executed under a standing order initiated by a PISP?

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

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

Definition of "equivalent authentication procedure" for journeys initiated from a mobile application

When a Payment Service User (PSU) initiates a service from a Third Party Provider's (TPP) mobile application, what is the correct "equivalent authentication procedure" of the ASPSP that should be used as the benchmark for assessing whether "unnecessary steps" have been added? Is it the ASPSP's mobile web browser authentication journey, or is it the ASPSP's native mobile banking application authentication 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

Clarification of the scope of the term "authentication procedures" in the context of the RTS and the EBA Opinion on obstacles

Does the term "authentication procedures" in the context of the EBA Opinion on obstacles (EBA/OP/2020/10) refer only to the final SCA method, or does it encompass the entire end-to-end user journey required to complete the authentication? Does this mean that any additional steps in the TPP flow, such as the need to click on a QR code image or manually enter a username to invoke the authentication app, which are not present in the direct channel, constitute a failure to support the same "authentication procedure"?

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

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 a mandatory client segment selection screen in a redirection journey

Does a mandatory step in a redirection journey, where a Payment Service User (PSU) must manually select their client segment (e.g., retail or corporate) on an intermediary screen (web interface) before being redirected to the ASPSP's authentication app, constitute an obstacle under Article 32(3) of the RTS, if such a step is not present when the PSU accesses their account directly via the ASPSP's native mobile application?

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 exception for Contactless only terminals (SoftPOS) in case of emergency

We are in the process of developing a backup solution for our SoftPOS terminal application, intended for use during exceptional circumstances such as cyber-attacks or other disruptions to internet connectivity and acquirer systems. As SoftPOS terminals operate exclusively with contactless transactions, and contactless transactions does not support Offline PIN, it is technically not possible to perform Strong Customer Authentication (SCA) in offline mode. We would like to confirm whether, under these conditions, it is acceptable to process offline contactless transactions without applying SCA and follow Directive (EU) 2015/2366 article 0 (15)

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 definition

Does an account provided by a payment service provider, linked to a payment instrument that can be used to make payment transactions to [certain] third parties (e.g. merchants) from that account, as well as to withdraw cash from that account (e.g. from an ATM) and receive incoming payments in the respective account from the same payment users to which the funds were transferred (i.e, refunds from merchants) fall under the definition of a payment account in accordance with PSD2, even if the respective account cannot receive funds from third parties via credit transfers?  

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

Setting limit (daily and/or per transaction) for the execution of payment transaction by PSP

Is PSP allowed, according to the Article 68(1) of PSD2, to set a general limit (daily and/or per transaction) for the execution of payment transaction to the payee with the PSP in another EU Member state, under the certain payment initiation channel (for example mobile banking), in order to mitigate the risk of fraud (to prevent fraud)? Is PSP allowed to set different general limits for national payments and for payments to PSPs in another EU Member state (due to various fraud risk associated to these transactions)? Is PSP obliged to change a limit above the limit that the PSP set - on PSU's request for regular credit transfer?

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

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

the use of strong and widely recognized encryption techniques

All strong and widely recognized encryption techniques (e.g. RSA and ECC) currently available on the market must be provided by the account servicing payment service providers or only that encryption technique which is indicated in the documentation of the technical specification of the API in accordance with Article 30(3) of the RTS on SCA & CSC shall be provided?

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

Organisation and governance

Legal and policy framework

Careers

Supervisory convergence

Direct supervision and oversight

Information for consumers

Ad hoc activities

Risk analysis

Pillar 3 data hub

Reporting

Data

Publications

Media centre