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:

Phone number: +1-437-886-3969


Salt Edge report

Discover what is the current state of open banking in Europe

Download now

Related articles

3 min read May 2020

HyperJar to achieve full PSD2 compliance with Salt Edge

Salt Edge, a leader in developing open banking solutions, enables UK fintech HyperJar to follow PSD2 requirements and provide new open banking capabilities. Budgeting app and eWallet HyperJar helps people plan their spending by allocating money into multiple jars, using each of these mini-accounts for different spending purposes: groceries, coffee,…

3 min read Apr 2020

Salt Edge helps Roundups create a new way of donating

Salt Edge, a leader in offering open banking solutions, joined Roundups in its mission to raise millions through adding up pennies left from payment transactions and donating them to charities and non-profit organisations. Today all aspects of financial life are managed online and charity is no exception. Roundups is a…

3 min read Jun 2019

Salt Edge is connected to 200+ European open banking APIs including all CMA9 banks

Riding the open banking wave, Salt Edge has already integrated with more than 200 banks around Europe. Salt Edge connects to live APIs and sandbox environments from financial institutions as they become available one by one. It means spending days and weeks analyzing, integrating, and testing thousands of connections across…

2 min read Oct 2019

Salt Edge hits next big milestone: 500+ integrated open banking APIs

Being on the right track and speeding up every month, Salt Edge quickly reaches a significant milestone for the company and the industry itself – successful integrations with 500+ open banking APIs. This number is especially important since now the company is integrated with banks in every country of the European Union….