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:

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.

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.