• Vladimir Pintea, Head of Open Banking Gateway at Salt Edge


• 04.11.2021 02:45 pm
#financial #API #openbanking

eIDAS certificates have an important role under PSD2. Their usage is mandatory for ensuring that data is kept secure and within trusted parties at all times. These certificates issued by QTSPs can be associated with passports with which TPPs identify themselves when onboarding with and accessing banks’ channels. While the eIDAS certificate is the ‘passport’, the PSD2 licence number represents the TPP’s identification number. This means that no matter how many times the ‘passport’ (certificate) is changed, and as long as it is valid, the TPP’s licence number should be the main identifier – which seems not to be always the case in banks’ TPP verification implementations.

Since these certificates are commonly valid for one-two years, hundreds of TPPs, including banks acting as TPPs, face the issue of renewing their eIDAS certificates and re-engaging with thousands of ASPSP APIs now and in the months to come. And here is where the interesting process starts. Going ourselves through it and also assisting our clients on the path to connect to banks with the new eIDAS certificates, we’ve encountered various constraints that are shared in this article

The biggest challenges I believe result from a lack of clear procedures or guidelines at the EU level on how banks should handle the update of eIDAS certificates. As a consequence, each bank has been approaching it differently – many of them require manual intervention in the developer portals, endless email discussions, or even practically going once again through the entire onboarding process. In the meantime, banks have updated their developer portals, old guides have changed, new procedures of authorisation and authentication, different from previous ones, have been added. For TPPs to synchronise their certificate renewal with each ASPSP puts at risk the end-customers’ experience and the overall business continuity of the TPPs.

More exactly, we had difficulties with 49 banks across Europe, out of which:

1. 26 banks required to log in to the developer portal and upload new certificates for the bank to be able to identify the TPP with the new certificate. It seems that banks with such implementation don’t verify the TPPs’ eIDAS certificates at every API request, but only during the onboarding process. This may represent a security and compliance risk.
2. 5 banks requested to create a new application in their developer portals, which led to the invalidation of all previously granted Account Information consents. This created disruption as all end-customers were forced to reconnect their bank accounts to the desired TPP apps and go through the SCA journey all over again.
3. 6 banks required to race-run dynamic registration with different client names. This is quite absurd as it means that the same TPP now would have two different identities in the banks’ systems, with separate accounts, logs, and overall history.
4. 11 banks didn’t have any means for handling the new certificates. These banks had to be contacted by email, while the adjustments needed to be made by hand. With these banks, the experience can be described as it follows:
   1. Average response time of 5.2 days;
   2. The fastest response time was 4 days;
   3. The slowest response time – 11 days;
   4. No reply from 1 bank even after 1 month.
5. 1 European consortium of banks started rejecting API requests with the new certificate 2 weeks after the migration, even though the updated certificates were working and had been accepted for the previous 2 weeks.

On top of that, some QTSPs revoke the old but still valid certificates once the new one is issued. For example, one QTSP revoked the old certificate just after 24 hours, resulting in all bank connections getting invalidated consents. Overall, this creates business disruption as TPPs don’t have a grace period to seamlessly introduce the new certificates to banks. Also, some QTSPs issue QWAC and QSeal certificates at different time terms, meaning that TPPs would have to send API requests to banks with a new QWAC and an old QSeal. 

How to handle eIDAS certificates renewal issues

Although these obstacles present clear disruption risks for business continuity and security, there are actions that TPPs, ASPSPs, and QTSPs can take to bypass or minimise those threats. 

First of all, TPPs should choose very carefully the QTSP they want to work with, as to prevent inconveniences. They should sit down with the QTSP and discuss the entire process of renewal – whether the old certificate will be valid for a transition period, can the QWAC and QSeal be renewed at the same time, which are all the required documents for the renewal, and more. Ideally, a transition period of at least one month should be granted while both certificates can be used. 

Careful in advance planning will help TPPs to go through this process easier, hopefully. It’s also important to seek communication with the bank right away and inform them in case of any encountered obstacles. 

How can ASPSPs help out? Well, first and foremost, ASPSPs should allow multiple eIDAS certificates to be associated with one TPP in their developer portals. It’s also important to emphasise that introducing new eIDAS certificates to banks should be absolutely automatic, by modern means of dynamic registration using dedicated API endpoints. Banks should have already started updating their TPP verification systems – taking into account that they had over 2 years to build it correctly. There are experienced vendors that can consult on the proper implementation. Salt Edge can give a hand as we’ve successfully implemented TPP Verification for numerous institutions across Europe. 

It is very recommended that EBA and National Regulators consider setting clear standards and guidelines at European or country levels. Based on these guidelines, ASPSPs could prepare their own instructions for TPPs to navigate through the process easier. This way, issues with downtimes, consent revocation, and endless manual work would be less likely to occur. 

We encourage TPPs to start planning the renewal of their eIDAS certificates and leave at least one month for this process. 

If you found insightful information here and would like to know more on how to plan correctly for the eIDAS certificates renewal process, names of great QTSPs that we’ve been working with, consultation on how to implement the TPP verification, contact us and we’ll gladly assist you.