Sep 03, 2019 • 8 minutes read

Working with Technical Service Providers under PSD2

According to PSD2, regulated TPPs are allowed to access banks’ PSD2 interfaces. TPPs can choose whether to integrate with banks on their own or to rely on an aggregator – Technical Service Provider (TSP). Regardless of the chosen method, TPPs should identify themselves toward banks for security and traceability reasons. According to PSD2, such identification should be done using eIDAS certificates. 

If TPP decides to work with one or several TSPs, it is important that TPP understands the rules of a correct collaboration and specifically those related to security and regulatory compliance – because eventually, the TPP remains responsible for any TSP’s action. 

Why do TPPs choose to work with Technical Service Providers?

It’s worth mentioning that TPPs need to undertake dozens of steps when integrating with banks’ interfaces. Here are just a few of them:

  • To register and onboard with each bank via a development or consortium portal, based on a set of documentation;
  • To integrate with banks’ sandboxes for testing purposes;
  • To integrate different types of bank interfaces. These can be dedicated (i.e. API) and/or non-dedicated (i.e. adjustment of existing PSU facing interface). Banks can follow diverse API standards like Open Banking UK, Berlin Group, STET for their dedicated interfaces or even implement their own API standard (e.g. BBVA, ING). Besides, TPPs will have to integrate with fall-back channels also, unless banks are exempt from providing one. In case of non-dedicated interfaces, these integrations can be unique per each bank and type of interface (i.e. personal/business).
  • To monitor and upgrade its connection to banks’ new API versions and/or adapt to any interface changes (for non-dedicated channel), taking into account that banks must notify 3 months in advance of these planned updates;
  • To quickly react to emergency changes made to the banks’ interfaces, that would usually occur without advance notification from banks. Some changes might result in interface unavailability;
  • To handle collection, storage, processing, and revocation of PSU consents in accordance with PSD2 and the technical specifications of banks;
  • To register all requests sent to banks in audit log for traceability purposes, in accordance with Article 29, Traceability (RTS on SCA and CSC).

Taking into account all the above responsibilities, TPP (or the bank acting as a TPP) would often prefer to rely on a TSP for many reasons, including faster launching on a new market, access to interfaces in a compliant manner, technical simplicity and security of integration. In most cases, TSPs provide a unified API gateway that allows TPPs to make one technical integration and get access to all pre-connected banks. Such collaboration between TPP and TSP should be done in compliance with the regulation, i.e.when accessing a bank interface, TSP should identify the principal TPP towards the bank (explained below – point 21 of EBA Opinion). 

How to correctly use eIDAS certificates for identification when working with a TSP?

According to EBA Opinion, TPPs that use TSPs for outsourcing some of technical activities in regards to integration with banks should use multiple eIDAS certificates:

[…] 20. However, in the specific cases where PSPs provide services through agents or EEA branches, or where they have outsourced to technical service providers some of the activities related to access to the online accounts held within an ASPSP, the EBA hereby clarifies that CAs should encourage these PSPs to consider using multiple certificates simultaneously: one per agent, EEA branch ortechnical service provider. This should ensure business continuity and better risk management of these PSPs because the legitimacy of one certificate would not be affected by the revocation of any other. PSPs remain fully responsible and liable for the acts of their agents and outsource providers as well as for the revocation and updating of the eIDAS certificates used by them.

What does it mean that TPP (“PSP”) uses one eIDAS certificate per TSP? It means that TPP requests an eIDAS certificate for the TSP and the private key of the certificate is known by this TSP only. So basically, the private key of such a certificate should be in the possession exclusively of the entity for which it was issued and it cannot be shared. To compare, eIDAS certificate is like the limited power of attorney given to the TSP to act based on TPP’s instructions and in accordance with the regulation. Using the same power of attorney for several entities puts at risk the security and stability of services used and offered by the TPP. 

The risks of sharing a single eIDAS certificate with several TSPs (i.e. when more entities have access to private key) are:

  1. Business discontinuity: If the eIDAS certificate is compromised (i.e. its private key was stolen, lost), then the certificate will be revoked and none of TSPs will be able to connect to banks. Similarly, if the eIDAS certificate expires – none of TSPs will be able to connect to banks till the certificate is renewed.
  2. Difficult traceability: The usage of one eIDAS certificate simultaneously by several TSPs makes the dispute resolution more challenging – in case of a security or privacy breach. 
  3. Compliance consequences: if the TPP service is not provided anymore, a significant amount of complaints from end customers to the national regulator can lead to TPP’s licence revocation.

When each TSP has its own eIDAS certificate, the revocation of one certificate would not put in jeopardy the entire business continuity of TPP. And also, this allows to clearly and easily identify the entity that has used that specific eIDAS certificate while interacting with the bank.

21. CAs should also ensure that ASPSPs accept eIDAS certificates presented by agents or outsource providers acting on behalf of AISPs, PISPs and CBPII, provided that the ASPSP is in a position to unequivocally identify the principal PSP in the presented certificate.

What does it mean that ASPSP is able to identify the principal TPP in the eIDAS certificate presented by TSP? It means that the eIDAS certificate used by TSP to connect to banks has to be issued based on TPP’s PSD2 licence.

And what about working with an ‘aggregator of aggregators’ under PSD2?

‘Aggregator of aggregators’ model means that TPP works with a TSP that on its side subcontracts several other TSPs. At first glance, it seems that TPP has less friction due to one contact point. Yet, in such a scenario, TPP needs to know every TSP for which it creates a dedicated eIDAS certificate. For TPP, this model carries the risk of losing control over the use of issued eIDAS certificates by underlying TSPs, delay in receiving reports, and a challenging issue resolution. Therefore, adding an extra intermediary in this process could eventually just lead to more fuss and risk. Acting as a TSP under PSD2, Salt Edge considers this ‘aggregator of aggregators’ model as adding new risks for TPPs and the services they provide. 

Working with the right TSP brings great benefits for a TPP –  faster launching on a new market, unified access to a dozen of pre-integrated banks, accessing bank interfaces in a compliant manner, technical simplicity and security of the integration, etc. Yet, TPPs need to keep in mind that they remain responsible in front of the law for any action undertaken by their chosen TSPs (Article 20 (2) of PSD2). So, before starting the collaboration, TPP should clearly understand whether the model of interaction with a TSP will be in compliance with the regulation. 

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 3400+ financial institutions in 66 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



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.