Jun 12, 2019 • 9 minutes read

TPP identification challenge for ASPSP under PSD2

According to PSD2, the financial institutions that act as ASPSPs should have in place at least one interface for regulated TPPs (including other ASPSPs that act as TPPs) for identification and secure communication. Identifying themselves is mandatory for all TPPs that wish to get access to ASPSP’s sandbox, live API, and/or non-dedicated interface – so that each of their actions is traceable.

PSD2 equally applies to all regulated entities, ASPSPs and TPPs alike. Before receiving their PSD2 authorization, TPPs are subject to extensive verification of their security, operational, governance, and risk management controls and subsequently they become strictly supervised and must operate in accordance with the law.

Commission Delegated Regulation (EU) 2018/389 (RTS) Article 34. Certificates

1. For the purpose of identification, as referred to in Article 30(1)(a), payment service providers shall rely on qualified certificates for electronic seals as referred to in Article 3(30) of Regulation (EU) No 910/2014 or for website authentication as referred to in Article 3(39) of that Regulation

Yet, there are several important challenges related to TPP identification. The eIDAS certificates issued by qualified trust service providers (QTSPs) for TPPs do not include one component – the passporting information, that shows in which host Member States (if any) the TPP is allowed to provide payment services, according to passporting rules (Article 34 (3) of RTS).

Furthermore, for some ASPSPs it is still not clear how the identification of TPPs should be performed in the first place. Should ASPSPs rely on eIDAS certificates verification only, or additionally check the EBA Register (Article 15 of PSD2) and/or National Registers (Article 14 of PSD2), or maybe do something else?

After discussing with multiple ASPSPs on this matter, we identified several of their concerns:

  1. Should the ASPSP check TPP passporting information available from the EBA Register and/or National Registers?
  2. What specific information about the TPP shall the ASPSP check?
  3. How often should the TPP checks be performed by the ASPSP?

On April 26, 2019 EBA published an answer that brings clarity to some of ASPSPs’ concerns defined above. According to EBA:

Article 34(1) of the Commission Delegated Regulation (EU) 2018/389 states that for the purpose of identification, payment service providers shall rely on eIDAS certificates. The Delegated Regulation does not require account servicing payment service providers (ASPSPs) to carry out additional checks for the purpose of identification. Given eIDAS certificates do not contain information on passporting, ASPSPs are not legally required to check any passporting information related to the third party provider (TPP) requesting access to online payment accounts.

In addition, Article 68(5) of PSD2 states that an ASPSP ‘may deny an account information service provider or a payment initiation service provider access to a payment account for objectively justified and duly evidenced reasons relating to unauthorised or fraudulent access to the payment account by that account information service provider or that payment initiation service provider’. Given eIDAS certificates do not contain passporting information (as stated above) and that ASPSPs do not therefore have to check passporting rights for the purpose of identification, ASPSPs should not block access to an account on the basis of the absence of information on whether or not a TPP is allowed to provide services in the host Member State.

Now, taking into account the EBA’s answer and the good industry practice, let’s try to elaborate on each of the ASPSPs’ questions listed above:

1) Should the ASPSP check TPP passporting information available from EBA Register and/or National Registers?

From EBA’s position, it’s clear that it is sufficient for ASPSPs to rely on eIDAS certificates for identification purpose and there is no need to perform additional checks of EBA Register or National Registers for TPP passporting information. Accordingly, since it’s optional – it’s up to the discretion of ASPSP whether to check the passporting information.

2) What specific information about the TPP shall the ASPSP check?

Taking into account that checking PSD2 eIDAS certificate is sufficient for TPP identification, ASPSPs should make sure that this certificate is valid. The validity verification of PSD2 eIDAS certificate and of TPP requests are done by performing 5 checks:

  1. To check whether the eIDAS certificate was issued by an authorized QTSP (check the certificate chain). The list of authorized QTSPs is available on the European Commission’s website. It’s worth mentioning that not all authorized QTSPs are issuing PSD2 eIDAS certificates. For more information on PSD2 eIDAS certificates, please refer to the excellent article of my colleague Lisa Gutu, Head of Business Development at Salt Edge: The eIDAS Challenge for TPPs under PSD2.
  2. To check if the PSD2 eIDAS certificate is not expired. This information is indicated in the certificate itself.
  3. To check whether the PSD2 eIDAS certificate is not revoked. QTSPs that are issuing PSD2 eIDAS certificates also publish a revocation list of issued certificates. There can be quite many reasons for revoking a certificate (e.g. the certificate’s private key is lost or compromised, the certificate is not needed anymore, the TPP’s authorization was revoked, etc.). Depending on each QTSP’s approach, the revocation list can be provided via a Certificate Revocation List (CRL) or an Online Certificate Status Protocol (OCSP).
  4. ASPSP should check the PSD2 role/permission assigned to the TPP in order to allow access only to the actions authorized by the National Competent Authority (NCA). The PSD2 roles are indicated in the certificate: PSP_AI – account information, PSP_PI – payment initiation, PSP_CI – confirmation of funds, PSP_AS – account servicing.
  5. To verify the possession of the eIDAS’ private key. Every TPP request should be signed with the private key of its eIDAS QSEAL certificate and such signature should be verified using the public key which is available in the eIDAS QSEAL certificate.

3) How often should the TPP checks be performed by ASPSP?

To cover the last concern in regards to how often PSD2 eIDAS certificate validity checks should be performed by ASPSPs, let’s review the table below:

As I emphasised at the beginning, the interactions between TPPs and ASPSPs are handled in accordance with PSD2 and both entities are equally regulated. Let’s keep in mind that any regulated TPP is meticulously monitored and in case they perform an unauthorized action, these TPPs will be subject to all the legal consequences ensuing from infringements of the national law transposing PSD2. Besides, in case of revocation of their passporting rights or the TPPs’ authorization, the TPPs are legally required to immediately stop any actions that they are no longer authorized to perform or otherwise they will be in violation of the Directive. Any potential damage or loss arising from TPP’s actions should be covered by TPP itself or by its professional indemnity insurance which every TPP is required to hold under PSD2.

The right implementation of TPP identification on ASPSP’s side greatly minimizes the technical and organizational efforts, removes complexity, and allows fast and reliable service provision. As part of Salt Edge PSD2 compliance solution for banks, the TPP verification system includes checking of both the legally mandatory elements (the eIDAS certificate) and also the extra sources for verification, including the EBA Register. The compliance solution validates the TPPs’ eIDAS certificates in real-time, after conducting rigorous checks (expiration, revocation, PSD2 role, request signature), via the relevant QTSP. This gives ASPSP confidence that the TPP connecting to its PSD2 channel(s) is an authorized payment service provider.

I would like to conclude this article by saying that it’s the ASPSP’s choice to add extra TPP verification elements besides the ones required by PSD2 (i.e., eIDAS certificate). In case of any doubt, ASPSPs can always approach their NCA to seek advice in regards to the right way of performing the TPP identification.

Written by Dmitrii Barbasura, Founder and CEO at Salt Edge

About Salt Edge

Salt Edge is a global fintech company offering a range of cutting-edge solutions to financial institutions, banks, finapps, and other fintech companies. The company is registered as Account Information Service Provider by the UK’s FCA, under PSD2. Among its most popular services are financial data aggregation API, open banking and PSD2 solutions, white label retail banking, and data enrichment. ISO 27001 certified, the company employs the highest international security measures to ensure stable and reliable interoperability channels between financial institutions and their users. Connected to 3100+ financial institutions in 61 countries, Salt Edge brings comprehensive financial data at the fingertips of hundreds of thousands of end-users on a daily basis.

More information: www.saltedge.com

Phone number: +1-437-886-3969

E-mail: press@saltedge.com


Subscribe to receive our latest news and updates


By submitting your email address you agree to receive emails from Salt Edge in accordance with Terms of Service and Privacy Policy.