A third party provider (TPP) is an entity that can access an online transacting payment account to provide either payment initiation services or account information services to an account holder.
It is an entity identified by the second Payment Services Directive (PSD2) regulation which aims to improve “the level playing field for payment service providers (including new players)”. Under PSD2, financial institutions must provide TPPs with access to their customers’ online payment accounts. This enables TPPs – which are not traditional financial institutions, but instead include fintechs, merchants, or other types of payment providers – to access a customer’s financial data or funds through an Application Programming Interface (API).
The introduction of TPPs has resulted in an increase in new competitive companies and innovative financial products meaning that consumers no longer have to rely on their primary bank for the provision of all their financial services and products.
PSD2 aims to make the EU payments market accessible to companies offering consumer and/or business-oriented payment services through the use of APIs to access online transacting payment accounts. There are three types of services that TPPs can be regulated to provide:
Customers have a legal right to use payment initiation services and account information services provided by TPPs with respect to certain payment accounts. Financial institutions, therefore, must allow TPPs access to these payment accounts (with the customer’s ‘explicit’ consent) through either their customer-facing interface (as modified) or a “dedicated interface” (e.g. API).
However, no legal agreement between the two parties is required before access is granted. This means that financial institutions might not know who the third party is and have no pre-existing arrangement with them. Furthermore, they are legally obliged to offer instant access to their accounts unless they believe that the TPP is fraudulent or not authorised for the transaction.
To discover whether a TPP is fraudulent or not authorised for the requested transaction is not a simple process.
There has been a net increase of over 300 new fintech TPP companies since September 2019, though the gross increase is closer to 400 – due to TPPs having their license withdrawn or losing permissions for various reasons. These reasons include mergers and acquisitions, business failure, legal name changes, bankruptcy, and modifications to offered services. As the ecosystem has matured, these changes are happening with greater frequency – which means that financial institutions must make more of an effort to check that a TPP is authorised in real time for any given transaction.
There are three steps to checking the validity of a TPP: identification, authentication, and authorisation.
Identification
eIDAS certificates are used as identity credentials when interacting with financial institutions. They are the first step in securing an open banking transaction, namely by establishing the identity of the TPP.
As explained in PSD2, TPPs can apply for an eIDAS certificate with a Qualified Trust Service Provider (QTSP). QTSPs are government-approved entities and issue two types of PSD2 eIDAS certificates to TPPs:
The use of eIDAS certificates is crucial to ensure independent government-assured trust in the identity of the third party. However, PSD2 explicitly states that the certificates should be used solely “for the purpose of identification” (Article 34). Confirming that a transaction is authenticated and authorised involves two additional steps.
Authentication
The second step makes sure that the TPP is authenticated. For this, QWACs are used to establish a secure communications channel using Transport Layer Security (TLS). As part of the Mutual authenticated TLS (MTLS) protocol, the TPP signs part of the communications data, passing between the two parties, with its private key. The financial institution can check the signature confirming that it matches the public key certificate. This confirms that the TPP holds the corresponding private key and therefore serves as proof of the TPP’s authentication.
The authentication step can also involve a QSealC to ensure the data integrity and proof of origin of the transaction, using digital seals and signatures to ensure the TPP is authenticated. The confidentiality of the data is provided by the encrypted TLS session.
Authorisation
Although QWACs and QSealCs provide secure identity and authentication mechanisms required by PSD2, they do not provide the regulatory check needed to ensure that the TPP is authorised. A financial institution must know in real-time that the TPP is:
eIDAS certificates, though crucial to identify a TPP, cannot be used to validate the authorisation status of the TPP at the time the transaction is taking place. eIDAS certificates are issued with a lifespan of one to two years and so cannot be relied upon to provide authorisation status, as the information can quickly become outdated. In addition, eIDAS certificates contain no information on passporting and so it is not clear whether the TPP is authorised to operate in another country.
Konsentus Verify carries out the identification, authentication, and authorisation security steps in real-time. After confirming the identity and authenticity of the TPP with a thorough eIDAS certificate check with the relevant Qualified Trust Service Provider (of which there are 70+), the data is cross-checked with information held on the databases and registers of the 30 EEA NCAs (of which there are over 115).
This ensures that a financial institution only ever approves a transaction with a third party that is authorised for the appropriate service in that country at the time of the account access request. Konsentus Verify protects customer data from any unauthorised or fraudulent use, upholding the reputation of financial institutions and shielding them from compliance fines and the costs of managing disputes.
