Article 30(1)(a) of the RTS provides that ASPSPs are obligated to have in place at least one interface which meets, inter alia, the requirement that AISPs, PISPs and CBPIIs are able to identify themselves towards the ASPSP.
For the purpose of identification, ASPSPs and TPPs shall rely on using eIDAS (electronic IDentification, Authentication and trust Services) Certificates for electronic seal and/or for website authentication. Identifying themselves is mandatory for all TPPs that wish to get access to ASPSP’s sandbox, live API, and/or non-dedicated channel.
The eIDAS Regulation (EU) 910/2014 on electronic identification and trust services for electronic transactions in the internal market was introduced before PSD2. It came into effect on 1 July 2016 and is widely used on the European market. eIDAS covers the broad category of all electronic signatures including “any data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign.” In other words, it is an electronic form of signature that a signatory can apply to a document as evidence of their acceptance or approval. This could include a scanned signature image or a click of an “I accept” button on a website or a DocuSign electronic signature.
eIDAS certificates are provided by Qualified Trust Service Providers (QTSPs) who are responsible for assuring the electronic identification of signatories and services by using strong mechanisms for authentication, digital certificates, and electronic signatures. There are hundreds of such providers across EU, but only dozens of QTSPs are providing PSD2 eIDAS certificates.
There are two types of eIDAS certificates:
eIDAS QSEAL can be seen as the digital version of a traditional company stamp, and is currently applied to electronic documents sealing to guarantee the origin and integrity of the document.
Note: PSD2 eIDAS QSEAL certificates are used for different purposes – signing of API/HTTP requests and not for sealing of documents.
According to EBA opinion on usage of eIDAS certificates, Clause 14, ASPSPs have three possible scenarios:
1. “Parallel use of QWACs and QSealCs – this will allow AISPs, PISPs and CBPIIs to identify themselves towards the ASPSPs and, at the same time, ensure that the communication is secure and that the data submitted originates from the PSP identified in the certificate.”
This is the most preferred solution, however, the QTSP market is not ready to provide PSD2 QSEAL certificates just yet. We expect that the vast majority of the ASPSPs will require both QWAC and QSEAL eIDAS certificates for production access closer to the end of 2019.
2. “Use of QWACs only – this will allow AISPs, PISPs and CBPIIs to communicate securely with and identify themselves towards the ASPSP, but cannot provide evidence that the data submitted originates from the PSP identified in the certificate.”
Currently all ASPSPs require only QWAC eIDAS certificates to access the Sandbox and some live APIs. This option creates a challenge for ASPSP to store the request as evidence in case of potential disputes.
3. “Use of QSealCs with an additional element that ensures secure communication – QSealCs will allow AISPs, PISPs and CBPIIs to identify themselves towards the ASPSPs, but cannot ensure confidentiality during the communication session. Therefore, an additional element that ensures secure communication should be used in order to comply with the requirements of Article 35(1) of the RTS.”
This option might be viable only if the QSEAL certificate is used for signing of the requests, while existing SSL/TLS certificates are used for communication.
Even though the usage of eIDAS certificates is available on the market for several years, the specifications were added to the RTS from the very beginning, there are just a few QTSPs that are capable to meet the PSD2 regulatory requirements. So what’s the issue around usual eIDAS certificates and PSD2 specifications?
Usual eIDAS certificates are granted to any company (no matter its license or activity type) or physical person. For instance, Company A that bakes cakes wishes to send an agreement online to its Supplier, Company B, for signing. Both companies have a usual eIDAS certificate, which makes it possible to securely communicate between both companies (QWAC) and ensures that digital signature is actually authorised by Company A and Company B (QSEAL).
In such a case to sign a request, a QTSP will normally give you some card/token with certificate private key or some other device that makes QSEAL signature possible. Another option instead of using such a device is storing the certificate private key on the HSM (Hardware Security Module) of the QTSP. The current costs per signing start from EUR 0.02 (price from the Salt Edge’s research). There are dozens of QTSPs that provide such services within EU right now.
So what about eIDAS PSD2 Certificates? Can all these QTSPs provide them? Unfortunately not. Salt Edge has identified only several QTSPs that have such services, the QTSP market is not ready at all in terms of what they have to do. In case of PSD2, there is no document signing, just secure communication between ASPSP-TPP (QWAC) and signing of requests (QSEAL).
PSD2 eIDAS certificates include additional information that is not present in usual eIDAS certificates, namely:
The problem is on the QSEAL side. There is no possibility to apply the existing infrastructure used for “usual eIDAS certificate” for “PSD2 eIDAS certificate”, as there might be hundreds of thousands or even millions of requests from a TPP per month that should be signed by TPP.
For example, TPP can do 4 automatic refreshes for the Account Information Service per day = 4 requests per day/per connection, and each API call should be signed. Having around 10,000 end-users, it means as a TPP you’ll have at least 4 requests * 10,000 users * 30 days * 10 API calls = 12,000,000 monthly requests. Having the same technological structure:
We’re getting to EUR 240,000/month for an AIS TPP with 10,000 daily active end-users. This makes it impossible to use current eIDAS structure in the post-PSD2 world. Using soft tokens, on the other hand, does not impose any additional expenses per API calls signature.
The regulation indicates that qualified certificates for electronic seals have to be used, however, it does not specify that such tokens have to be generated or stored on the QSCD (Qualified Electronic Signature Creation Device), as it was and still is for Document Sealing in the usual eIDAS certificates. This means that a QTSP can issue QSEAL as soft tokens in the same way as QWAC for PSD2 signing requests, not based on token or HSM.
From the Salt Edge’s market study, such an approach has been confirmed by at least 2 QTSPs so far, which are planning to release public QSEALs via soft token in June 2019.
Summary for TPPs:
Written by Lisa Gutu, Head of Business Development 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