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

Consumer explicit consent to the PISP for processing of personal data

Can the presentation by the consumer of its identification data to the merchant (e.g. CustomerID and IBAN through a QR code read by the Point of Interaction (POI)) be interpreted as the consumer providing explicit consent via the merchant to the usage of this data by a Payment Initiation Service Provider (PISP) that has a contractual relationship with the merchant (but not with the consumer) for the processing of data that will enable the initiation of a single (instant) credit transfer with the consumer’s Account Servicing Payment Service Provider (ASPSP), subject to sufficient information about this PISP made available beforehand to the consumer (in accordance with Articles 44 and 45 of PSD2)? Or is the explicit consent of the consumer to the PISP required by way of contract, as mentioned in section 3.2.1 of the EDPB Guidelines 06/2020 on the interplay of Directive 2015/2366/EU (PSD2) and the GDPR?

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

Information to be provided by the PISP to the payer prior to the initiation of the transaction

Is it sufficient that the merchant makes available upon request by the payer (consumer) the information about the Payment Initiation Service Provider (PISP) in the Point of Interaction (POI) environment before the consumer presents their data (e.g., via a QR code) to meet the requirements of Articles 44 and 45, (2), PSD2?

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

Elements of possession (SIM card) and knowledge (knowledge-based responses to challenges or questions)

1. Can evidence of possession (SIM card) can also be verified by reading and identifying the phone number used for the phone call? 2. Can a knowledge element be based on a) transaction history of the customer; b) contact information of the customer?

  • 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

Merchant IDs and SCA

In the situation where Strong Consumer Authentication (SCA) was completed at the time of completing a hotel booking by an Online Travel Agent (OTA) or hotelbrand.com under their Merchant ID but the actual payment will take place at the time of arrival: will the SCA authentication token remain valid for the hotel (merchant) making the charges and its respective Merchant ID?

  • 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 towards SCA if association is done based on phone call

Does the requirement to apply Strong customer authentication (SCA) under Article 24 paragraph 2 b of Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication apply when customer is served using telephone call? Or is the only possibility to associate authentication credentials with the customer not having active credentials at hand, only possible having customer present?

  • 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

Delegation of 2-Factor Authentication (2FA) to PISP, AISP or other third party

Where a Payment Service Provider (PSP) is providing financial services via a third party application - either through a Payment Initiation Services Provider (PISP), Account Information Service Provider (AISP) or by providing embedded financial products or banking as a service solutions (i.e. financial services via an Application Programming Interface (API)) - is it permitted for the PSP to delegate the application of 2-Factor Authentication (2FA) to the third party?

  • 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

Association with the payment service user by means of a remote channel

Is it sufficient to use a company level knowledge element, in combination with a peronal posession element to associate a user of a business application with personalised security credentials such as authentication software or a knowledge element?

  • 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 on level of protection required for the processing of the IBAN outside the inter-PSP environment

Can the IBAN of the payer or payee be handled in cleartext outside the inter Payment Service Provider (PSP) environment? For instance could a payer’s IBAN be contained in cleartext in a payer-presented QR-code provided by the payer’s device to the merchant’s point of interaction for the initiation of an (instant) credit transfer? Or could a merchant’s IBAN be contained in cleartext in a merchant-presented QR-code at the merchant’s point of interaction to be read by the payer’s device for the initiation of an (instant) credit transfer?

  • 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 on the qualification and protection requirements of a CustomerID when included in a payer-presented QR-code for the initiation of (instant) credit transfers at the point of interaction (POI)

Is the CustomerID (i.e. ID issued by an Account Servicing Payment Service Providers (ASPSP) to its Payment Services User (PSU) for accessing the on-line banking system and usually required by PSD2 Application Programming Interfaces (APIs) to identify the PSU) to be qualified as “personalised security credentials of the PSU” within the meaning and for the purposes of Article 66 (3) b), PSD2, and Article 35 (5), RTS, and therefore be treated as “sensitive payment data” within the definition of Article 4 (32), PSD2? Accordingly, can said CustomerID be included in cleartext in the payer-presented QR-code for the initiation of (instant) credit transfers at the point of interaction (e.g. POS, vending machine) without any protection during the QR-code life-cycle, including the generation of the QR-code, storage of the QR-code on the payer’s device, transmission from the payer device to the payee’s point of interaction and in the payee’s (e.g. merchant) point of interaction?

  • 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

Intermediaries and Merchant-ID

In the hotel industry, given that when a customer reserves a room, a payment is often not taken at this time, should an entity (intermediary, online travel agent or brand/hotel group) that collects payment details from a customer also facilitate strong customer authentication (SCA), regardless of when or by whom the actual payment transaction may be processed? If yes, should the customer be explicitly informed of the entities involved in order for their consent to be valid?

  • 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

Validity of SCA

If  Strong customer suthentication (SCA) is required at the time of booking which is more than 90 days before the guest’s arrival, will hotels be able to process the payment at location with an expired authentication token? If not, can an SCA be renewed and who would be responsible for doing so?

  • 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

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

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

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

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

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

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

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

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

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