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

Strong customer authentication (SCA) Knowledge element: Place of Birth and Date of Birth

Does a payer’s date of birth and place of birth constitute a valid Knowledge Element for strong customer authentication.

  • 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: 2021_5821
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 30/07/2021

Clarification on where the creation of the authentication code with dynamic linking for strong customer authentication (SCA) for electronic remote payment needs to be done

Should the authentication code be computed and dynamically linked to the transaction data in a unique processing step prior or together with the payer’s authentication on the payer’s device, or can the authentication code be computed and dynamically linked in one or several subsequent steps in the payment process, possibly not on the payer’s device?

  • 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: 2020_5366
  • Topic: Other topics
  • Date of submission:
  • Published as final Q&A: 30/07/2021

Applicability of SCA to wallet solutions

Is a single Strong Customer Authentication (SCA) sufficient for transactions performed in staged wallet solutions? Does the funding transaction qualify as a transaction initiated by the payee only, which does not require SCA by the Account Servicing Payment Service Providers (ASPSP)?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Not applicable
  • ID: 2018_4133
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 21/05/2021

Obstacle to the provision of payment initiation and account information services

Should Article 32.3 of Regulation (EU) 2018/389, read together with paragraphs 33 to 41 of the Opinion of the European Banking Authority on obstacles under Article 32(3) of the RTS on SCA and CSC, be interpreted so as to consider that interface implementations that require, in a redirection approach, Payment Initiation Services Providers (PISPs) to always transmit the payer’s IBAN to initiate a payment order, are an obstacle to the provision of payment initiation services because the payment service user is required to manually enter their IBAN while in the PISP’s domain? Should Article 32.3 of Regulation (EU) 2018/389 be interpreted identically where the interface implementations require Account Information Service Providers (AISPs) to always transmit the IBAN(s) of the account(s) to be accessed, therefore requiring the payment service user to manually enter their IBAN(s) while in the AISP’s domain?

  • 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: 2021_5763
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 23/04/2021

Use of new technology for SCA

Is a Payment Services Provider (PSP) allowed to adopt innovative technologies for verifying Payment Services Users (PSUs) where the PSP maintains fraud levels below a certain threshold?

  • 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: 2020_5621
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 23/04/2021

Use of behavioural data for SCA

Can a Payment Service Provider (PSP) use behavioural data and auditable scores to apply Strong customer authentication (SCA) in a way that protects consumer privacy?

  • 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: 2020_5620
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 23/04/2021

Independence of the elements for SCA

Can a Payment Service Provider (PSP) apply Strong customer authentication (SCA) using elements from the same category provided that the elements are independent (i.e. breach of one does not compromise reliability of the other elements)?

  • 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: 2020_5619
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 23/04/2021

On the requirements for 'inherence' in strong customer authentication (SCA)

Do the elements required for ‘inherence’ in strong customer authentication (SCA) provide the complete authentication or can they form a part of an authentication decision with some non-biometric elements and still satisfy the inherence condition, for example, as one element of a user profile of several elements. For example, if the biometric, say keystroke dynamics, provides 50% of the decision and other characteristics (e.g. device data, location data) provide the other 50%, does this satisfy the requirement for inherence assuming the condition for 'very low probability of unauthorised access' is also satisfied and that another SCA condition, 'knowledge' or 'possession' is also satisfied? if so, is there a threshold, say 50%, below which it ceases to qualify as 'inherence'?

  • 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: 2020_5353
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 23/04/2021

Contingency Measures under Article 33

Does fallback access to a secondary instance of the dedicated interface in a different data center with dedicated resources, provide an acceptable strategy and plan for the contingency mechanism?

  • 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: 2019_5054
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 23/04/2021

Application of the strong customer authentication (SCA) in case of refund

Does a refund, which is considered as an electronic payment transaction, be subject to  strong customer authentication (SCA)? Does a merchant that initiates a refund request be considered as a payer? If so, does a Payment service provider (PSP), that holds the payment account of a Merchant, have to set up SCA each time his Merchant is doing a refund from its 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
  • ID: 2019_4855
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 23/04/2021

Legal requirements for the authentication procedure when SCA exemptions are applied for remote payment transactions

What are the legal requirements for the type of authentication procedure used when conditions for the application of of Strong customer authentication (SCA) exemption for remote payment transactions are fulfilled?

  • 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: 2020_5673
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 09/04/2021

How to use bank guarantees instead of PII

Is it acceptable to use third party (other than credit institutions) commitments that are covered by a guarantee from a credit institution as a comparable guarantee instead of professional indemnity insurance (PII)?

  • 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: 2020_5335
  • Topic: Monetary amount of the professional indemnity insurance
  • Date of submission:
  • Published as final Q&A: 09/04/2021

Card payments - acquirer

If an acquirer is not able to distinguish whether a card used for a payment is a card with an e-money function, is the acquirer required to report transactions with such cards under the EBA Guidelines on fraud reporting, and if so, under what breakdown?

  • 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)
  • ID: 2019_5045
  • Topic: Fraud reporting
  • Date of submission:
  • Published as final Q&A: 09/04/2021

Chip and Signature cards and their inclusion in the remit of RTS Article 11

Is cardholder signature a strong method of authentication when transacting with card present?If so, is there a requirement to ensure that on Chip and Signature cards we step up to signature from contactless after 5 contactless /cumulative value of 150 euros?If a signature is not considered to be strong customer authentication (SCA), are chip and signature cards exempt from SCA requirements under Article 11 of the RTS on strong customer authentication and secure communication?

  • 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: 2018_4342
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 09/04/2021

Trusted Beneficiaries

Article 13 of the RTS on strong customer authentication (SCA) and secure communication does not seem to restrict the use of trusted beneficiaries beside the fact that the payee must be in the list of trusted beneficiaries when initiating the payment transaction. Is it correct to conclude from this that the usage of trusted beneficiaries is not further restricted and can, therefore, also be implemented as a generic beneficiary approval step prior to every initiation of a payment transaction?

  • 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: 2018_4338
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 09/04/2021

Type of accounts accessible through common and secure communication

Should credit lines (namely “credit cards accounts”), accessible online, be available to Account Information Service Provider (AISP), Payment Initiation Service Provider (PISP) and Card Based Payment Instrument Issuer (CBPII)?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Not applicable
  • ID: 2019_4856
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 12/03/2021

Payment accounts and reference accounts

Are payment accounts, which are coupled with a reference account, in scope of PSD2 especially Regulation (EU) 2018/389 – RTS on strong customer authentication (SCA) and secure communication (CSC)?

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

Credit value date for payment transactions with currency conversion

As a credit entry on an account is possible only in the currency the account is maintained, does this mean that for a payment transaction the credit value date for the payee's account is no later than the business day on which the amount in the payee's account currency is credited to the payee's payment service provider's account?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Not applicable
  • ID: 2018_4150
  • Topic: Other topics
  • Date of submission:
  • Published as final Q&A: 12/03/2021

Sanctions list screening in the context of TPPs' services - risk management policy

Is the Account Servicing Payment Service Provider (ASPSP) obliged to recognise if a Third Party Payment Service Providers (TPP) is named on a sanctions list or even take some actions when the TPP becomes a designated entity? How the prohibition of directly or indirectly making funds or economic resources available to designated persons and entities is defined in this context?

  • Legal act: Directive 2015/2366/EU (PSD2)
  • COM Delegated or Implementing Acts/RTS/ITS/GLs: Not applicable
  • ID: 2018_4117
  • Topic: Strong customer authentication and common and secure communication (incl. access)
  • Date of submission:
  • Published as final Q&A: 12/03/2021