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

Salt Edge report

Discover what is the current state of open banking payments in Europe in 2021

Download now

Related articles

9 min read Jun 2020

Building a PSD2 compliant channel: challenges and opportunities for financial institutions

PSD2 obliges ASPSPs including banks, e-wallets, prepaid cards and other companies that offer payment accounts to provide at least one channel for secure communication with third party providers (TPP). Even neobanks or e-money institutions, including their agents, have to provide such channels with sandbox environments published 6 months before going…

3 min read Oct 2021

Money Minx taps Salt Edge to offer customers an enhanced open banking-enabled investing experience

Money Minx, a US-based net worth and investments tracking platform, joined forces with Salt Edge, open banking pioneer, to allow their users in the UK, Germany, and Switzerland to connect all bank accounts and monitor investments with ease – all in one place. The modern world opens the door for…

2 min read Nov 2019

Salt Edge crosses the mark of 600+ integrated PSD2 APIs

A new month and a new massive milestone for Salt Edge on its mission of building bridges between financial institutions and their customers via open banking – it is 600+ integrated open banking APIs in the European Union. While it may seem like integrating new APIs is a tug of…

4 min read Dec 2020

Fast Budget partners with Salt Edge to provide a fully automated way to manage daily finances

Fast Budget, an Italy-based PFM app, teamed up with Salt Edge, a leader in offering open banking solutions, to enable its end-customers to connect and access all bank accounts in one place and eliminate the need to insert the financial data manually. The PFM market is constantly evolving due to…