Blog article
See all stories »

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."

TPP verification flow

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:

TPP check type and the frequency of checks

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.

17338

Comments: (6)

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 31 May, 2019, 13:07Be the first to give this comment the thumbs up 0 likes

Awesome post. Kudos for digging deep into an extremely important area of Open Banking / PSD2 that has received very little attention (at least IME). 

Brendan Jones
Brendan Jones - Konsentus Ltd - Reading 18 June, 2019, 10:46Be the first to give this comment the thumbs up 0 likes

Very good points raised in this article, however, there is divergence between regulatory standards and business reality. PSD2 standards are a minimum, and ASPSPs have other regulatory duties of care over and above these such as the general Principles for Business in the UK FCA Handbook.

Brendan Jones
Brendan Jones - Konsentus Ltd - Reading 18 June, 2019, 11:17Be the first to give this comment the thumbs up 0 likes

Konsentus has posted an in depth look at the challenges facing ASPSPs identifying TPPs under PSD2 and other regulatory duties of care. Please read blog posted.

Dmitrii Barbasura
Dmitrii Barbasura - Fintech Galaxy - Uae, Dubai 24 June, 2019, 22:27Be the first to give this comment the thumbs up 0 likes

Brendan, thank you for your comments. I agree that verification of TPP’s eIDAS PSD2 certificate is a regulatory requirement each ASPSP must comply with, and such verification should be sufficient for the purposes of TPP identification under PSD2 and related RTS. EBA’s responses to issues VIII to XIII raised by participants of the EBA Working Group on APIs under PSD2 only reinforces this position: “ASPSPs are not legally required to rely on any other means for the purpose of identification of TPPs.” Thus, can you please provide reference to the specific provisions in PSD2 or RTS that would require the ASPSP to namely check the EBA Register and/or National Registers? Moreover, considering that both EBA and NCAs do not guaranty accuracy of the information presented in their registers and disclaim liability for any errors or omissions therein, it is not clear how such additional checks would help an ASPSP to comply with its other regulatory duties of care.

Nikita Bondariev
Nikita Bondariev - IT Craft - Kharkiv 15 July, 2019, 10:03Be the first to give this comment the thumbs up 0 likes

Hello Dmitrii, thank you for your article. Your posts help us to figure out what we need to do in order to become compliant with PSD2. 

I have a question. Could you please specify what resource bases do you suggest to use for validation of eIDAS certificates? We investigated but didn't find any that provide open API for calling to their DBs. So it's a kind of a challenge for us now, how to validate certificates. I'd appreciate your help.

 

Brendan Jones
Brendan Jones - Konsentus Ltd - Reading 17 July, 2019, 14:00Be the first to give this comment the thumbs up 0 likes

Dmitrii, in answer to the specific questions that you raised, my response is as follows: 

1)    As stated in the EBA responses to issues VIII to XIII raised by participants of the EBA Working Group on APIs under PSD2, it states that (article XIII) “However, ASPSPs may choose to carry out additional checks of the authorisation/ registration status of TPPs in the respective EBA and/or national registers, provided that, in doing so, ASPSPs do not create obstacles to the provision of payment initiation and/or account information services, as required in Article 32(3) of the RTS”.

2)    You are correct that the EBA does not guarantee the accuracy of the information presented in the Register, however, as stated in the EBA Disclaimer “the Register has been set up by the EBA solely on the basis of information provided by national competent authorities of the EEA Member States. Therefore, unlike national registers under PSD2, this Register has no legal significance and confers no rights in law. The Disclaimer goes on to state “the EBA is responsible only for the accurate reproduction of the information received by competent authorities included in the register, while responsibility for the accuracy of that information lies with the competent authorities at national level. Therefore, by default the NCAs are the legal system of record.

Additionally, it would appear strange and worrying if the NCAs are not the legal system of record, as this is the source data for QTSPs to check and verify the regulatory status of TPPs before issuing their eIDAS certificates.

 

Now hiring