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

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

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

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

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
  • ID: 2025_7644
  • Topic: Other topics
  • Date of submission:
  • Published as final Q&A: 12/06/2026

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
  • ID: 2025_7672
  • Topic: Other topics
  • Date of submission:
  • Published as final Q&A: 12/06/2026

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
  • ID: 2025_7675
  • Topic: Other topics
  • Date of submission:
  • Published as final Q&A: 12/06/2026

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
  • ID: 2025_7425
  • Topic: Other topics
  • Date of submission:
  • Published as final Q&A: 12/12/2025

Authentication process of the PSU with the ASPSP in a combined AIS and PIS journey in a redirection approach

Consider an ASPSP that offers a dedicated interface using a redirection approach. To fulfill the requirement that PSUs using a PIS should not have to enter their own account details, the ASPSP allows TPPs that have an AIS license to retrieve the list of all the PSU’s payment accounts via the interface so that the account can be selected in the TPP’s domain.  Does the ASPSP create an obstacle in the sense of Article 32(3) of Commission Delegated Regulation (EU) 2018/389 if  it forces a PSU who is initiating a payment through a PISP without entering the own IBAN to perform full SCA twice while a PSU who initiates a payment through the ASPSP’s customer interface needs to perform full SCA only once, while the second authentication requires entering only one element of 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: 2025_7358
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 03/10/2025

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

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

Minimum monetary amount of professional indemnity insurance in ongoing supervision

Are points 5.4, 5.7, 5.10 and 7.4 of EBA/GL/2017/08 guideline applicable only while applying for authorisation or in ongoing supervision as well? Is 50 000 per indicator minimal amount after authorisation procedure/first year as well?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: EBA/GL/2017/08 - Guidelines on the criteria on how to stipulate the minimum monetary amount of the professional indemnity insurance
  • ID: 2025_7317
  • Topic: Monetary amount of the professional indemnity insurance
  • Date of submission:
  • Published as final Q&A: 03/10/2025

Knowledge element of SCA.

Can an API key be considered as a Knowledge element of 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: 2024_7286
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 29/08/2025

Proxy matrices

Are credit institutions (ASPSPs) allowed to facilitate proxy matrices implemented by their (corporate) clients that allocate proxy to only certain users to invoke the services of third party payment service providers (TPPs)?  

  • 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: 2024_7265
  • Topic: Other topics
  • Date of submission:
  • Published as final Q&A: 29/08/2025

Obstacles Faced by PISPs in Accessing Payment Status Information Under PSD2

Are ASPSPs allowed to require PISPs to provide any additional identifier beyond what is specified in Article 35.4.b of the RTS in order to access information about the execution of a payment order?

  • 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: 2024_7261
  • Topic: Other topics
  • Date of submission:
  • Published as final Q&A: 29/08/2025

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
  • ID: 2024_7056
  • Topic: Other topics
  • Date of submission:
  • Published as final Q&A: 11/07/2025

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
  • ID: 2023_6910
  • Topic: Other topics
  • Date of submission:
  • Published as final Q&A: 11/07/2025

Paper-based postal money orders as defined by the Universal Postal Union

1. Should postal transfers as defined by the Universal Postal Union, which are not made in paper form but by electronic means, be excluded from the scope of PSD2?     2. If postal transfers, as defined by the Universal Postal Union, in both electronic and paper format, are inseparable from the postal operator’s accounting system, should also paper-based postal transfers not fall outside the scope of PSD2?     3. Should such transfers be excluded from the scope of PSD2 in either case, or agree that the payment institution is not entitled to credit those funds to the payment service customers’ funds accounts where the money of the payment service users is kept separate?     4. Can a payment institution that is also a postal service provider simultaneously provide both PSD2 regulated services and services related to payments but outside the scope of PSD2?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Not applicable
  • ID: 2022_6391
  • Topic: Other topics
  • Date of submission:
  • Published as final Q&A: 11/07/2025

Compliance of non-bank PSPs with the safeguarding requirements in PSD2

Where PIs and EMIs (referred to as non-bank PSPs) have direct access to central bank operated payment systems for settling payment transactions, would keeping a balance on a settlement account with the central bank/payment system, without the central bank maintaining a safeguarding account for the non-bank PSP, be compliant with the safeguarding requirements under Article 10 of PSD2?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Not applicable
  • ID: 2024_7165
  • Topic: Other topics
  • Date of submission:
  • Published as final Q&A: 08/05/2025

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
  • ID: 2023_6882
  • Topic: Other topics
  • Date of submission:
  • Published as final Q&A: 17/01/2025

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