Search for Q&As Submit a question

List of Q&As

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: 16/07/2018 | Date of publication: 12/03/2021

Account Data required by a ASPSP to execute a payment order via a PISP

In the context of Payment Initiation Service (PIS) where a Payment Service User (PSU) payment order is to be carried out, the Payment Initiation Service Provider (PISP) accesses the PSU e-banking account to require a payment. The PSU may: a) hold a single payment account to be debited or b) hold multiple payment accounts where only one of them is to be debited to finalize the payment order (in this case PSU has to select a payment account).With reference to both use cases and in the presence of an Account Servicing Payment Service Provider (ASPSP)’s dedicated interface, may the PSU be obliged to digit the IBAN of the account to be debited each time she/he initiates a transaction? Is the PISP always required to report the account number to be debited in the payment request or may this parameter be managed bilaterally among ASPSP and PSU (e.g.: default payment account, drop-down selection menu during the strong customer authentication (SCA) procedure, communication over Out-of-Band (OOB) channels, etc.)?

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_4854 | Topic: Strong customer authentication and common and secure communication (incl. access) | Date of submission: 06/08/2019 | Date of publication: 05/03/2021

"Authorisation number" in eIDAS certificates

There are two possible interpretations of the Regulation (EU) 2018/389 (RTS) Article 34 paragraph (2) in the case of payment service providers registered in Member State “A”:1) The authorisation number is the number of the resolution of the NCA (or its predecessor in title) authorising the provision of payment services for the specific PSP, which is not the same as the Registration number appearing in the NCA’s public register.2) The authorisation number is the Registration number appearing in the NCA’s public register (which is a reference number formed based on the VAT number).Please clarify whether interpretation 2) above is in line with the requirements of the RTS? Please clarify whether the 8-digit Registration number (based on the VAT number) appearing in the NCA’s public register, and appearing as “National Identification Number” in the EBA PSD2 register or as “National Reference” in the EBA credit institution register can be used as the “authorisation number” in eIDAS certificates?

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_4679 | Topic: Central register of the EBA | Date of submission: 23/04/2019 | Date of publication: 14/06/2019

Consent for the provision of PIS and AIS

Could the consent to Account Information Service Providers (AISP)/ Payment Initiation Service Provider (PISP) to provide services to a Payment Service User (PSU) also be revoked by the bank directly for PSU’s ease of use and could ASPSPs offer the PSU to generally “opt out” of being able to use the services of bank-independent Third Party 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: 2018_4309 | Topic: Strong customer authentication and common and secure communication (incl. access) | Date of submission: 03/10/2018 | Date of publication: 21/12/2018