At the European Banking Authority (EBA) Working Group on APIs under PSD2, a number of market participants raised concerns that there could be a potential mismatch, particularly in the case of withdrawn authorisations, between the information contained in the eIDAS PSD2 certificate and the information contained on the EBA and national registers. They highlighted the risk of Financial Institutions (ASPSPs) sharing information with parties no longer authorised by National Competent Authorities (NCAs) but with active eIDAS certificates.
The answer from the EBA to these concerns was:
“In accordance with Article 34 of the RTS on SCA&CSC, for the purpose of identification, as referred to in Article 30(1)(a), payment service providers shall rely on qualified certificates for electronic seals as referred to in Article 3(30) of Regulation (EU) No 910/2014 or for website authentication as referred to in Article 3(39) of that Regulation (eIDAS Regulation). This means that, when a Third-Party Provider (TPP) identifies itself towards the ASPSP via an eIDAS PSD2 certificate, the ASPSP shall grant access to the TPP to the specified account. ASPSPs are not legally required to rely on any other means for the purpose of identification of TPPs.”
It is certainly true that for the purposes of identification of a TPP that ASPSPs can rely on a Qualified Website Authentication Certificate (QWAC) or a Qualified Electronic Seal Certificate (QSealC), but ASPSPs also need to comply with:
- Article 37(1) of PSD2 which states that “Member States shall prohibit natural or legal persons that are neither PSPs nor explicitly excluded from the scope of PSD2 from providing payment services”.
- Article 68(5) of PSD2 which states that an ASPSP “may deny an account information service provider or a payment initiation service provider access to a payment account for objectively justified and duly evidenced reasons relating to unauthorised or fraudulent access to the payment account by that account information service provider or that payment initiation service provider”.
This means that ASPSPs not only need to identify the TPP but also determine the regulated status of the TPP and only grant the TPP access if the TPP is properly authorised and deny access if the TPP is not authorised.
The EBA followed on by stating:
“However, ASPSPs may choose to carry out additional checks of the authorisation/registration status of TPPs in the respective EBA and/or national registers, provided that, in doing so, ASPSPs do not create obstacles to the provision of payment initiation and/or account information services, as required in Article 32(3) of the RTS”
It should be noted that to carry out these “additional checks”, using the currently available EBA and national registers for Credit Institutions, Payment Institutions, exempt Payment Institutions, Electronic Money Institutions, exempt Electronic Money Institutions and other exempt Financial Institutions, could be a complex and time consuming activity. In addition, if these checks were to create delays or friction in the customer journey that would directly or indirectly dissuade customers from using the services of TPPs, this would represent an obstacle prohibited by Article 32(3) of the RTS.
However, these checks should not present an obstacle to the performance of the transaction between the TPP and ASPSP or cause delays in the ‘customer journey’ if they are provided by a high-performing and quality service that can process the regulatory checks at high volume and high speed.
It is incumbent on the ASPSP, as the guardian of the PSU’s data, to ensure that it does not provide access to unauthorised and unregulated TPPs.
PSD2 XS2A Ecosystem
The full PSD2 XS2A ecosystem covers PSD2 API schema, technical, functional, operational and governance domains.
TPP revocation scenario
Let us take a closer look at the concerns raised by some of the participants of the EBA Working Group on APIs for PSD2 when a TPP’s authorisation is withdrawn.
Many organisations, old and new, across the EEA, are setting themselves up to become AISPs and/or PISPs and seeking authorisation/registration from their National Competent Authority (NCA). This is a new market, created by PSD2 open banking regulation, and not all of these new and innovative payment service providers will survive.
So what happens when a TPP goes out of business?
Consider a TPP that, up until today, was authorised to provide AISP and PISP services to PSUs in its Home Member State and in several other EU member states, but, has now ceased trading and gone out of business.
In an ideal world what should happen?
The TPP should notify its Home NCA which should, without delay, withdraw the TPP’s Payment Services licences and update the corresponding information on its public facing register changing the TPP’s status from ‘authorised’ to ‘not authorised’. The NCA should also notify the EBA and update the TPP’s information on the EBA’s electronic central register, by the end of the day, at the latest. After that, the NCA should notify each of the Host NCAs, in the member states where the TPP had ‘passported’ its service, that the TPP is no longer authorised to provide payment services. In response, each Host NCA should change the TPP’s status, on its public register, from ‘authorised’ to ‘not authorised’.
The TPP should also notify the QTSP which issued its eIDAS certificates and request that those certificates are revoked. The QTSP will, without delay, post the details of the revoked certificates on its CRL and OCSP server.
The TPP should suspend its services to PSUs and notify the market that it can no longer offer AISP and PISP services.
What is likely to happen in the ‘real’ world?
If the TPP is a good actor
If the TPP is a good actor, it will suspend its services to PSUs and notify the market that it is no longer able to continue offering AISP and PISP services. It may, after that, notify its Home NCA that is has ceased trading and request the NCA to revoke its AISP and PISP authorisations. Having approved the revocation, the Home NCA would update its public facing register changing the TPP’s status from ‘authorised’ to ‘not authorised’. The Home NCA should then notify the EBA, update the EBA’s electronic central register, by the end of the day, and let each of the Host NCAs know that the TPP has had its AISP and PISP authorisations withdrawn immediately. Each Host NCA should, in turn, update their own public facing register with the change in state of the TPP.
The TPP should request the QTSP which issued its eIDAS certificates to revoke them but, experience of how organisations manage their SSL certificates would suggest that this is less than likely to happen. The part of the organisation that is tasked with managing the organisation’s cryptographic keys and security parameters is not usually customer facing and, as this is a rare event, unlikely to have a reliable process for this eventuality. The staff may also no longer be employed by the company.
The Home NCA could notify the QTSP that it has withdrawn the TPP’s payment services licences and request the QTSP to revoke the TPP’s eIDAS certificates. However, the NCA has no legal obligation to do so and, in all probability, it may not even know which QTSP issued the certificates in the first place. True, the identity of the issuing QTSP is in the certificate but there is no reason for the NCA to have ever seen the TPP’s certificates.
If the TPP is a bad actor
Although, as Dmitrii Barbasura, Founder & CEO at Salt Edge states on his LinkedIn post “TPP identification challenge for ASPSP under PSD2”, published 27 May 2019:
“Any regulated TPP is meticulously monitored and in case they perform an unauthorized action, these TPPs will be subject to all the legal consequences ensuing from infringements of the national law transposing PSD2. Besides, in case of revocation of their passporting rights or the TPPs’ authorization, the TPPs are legally required to immediately stop any actions that they are no longer authorized to perform or otherwise they will be in violation of the Directive.”
But if the TPP is a bad actor it is unlikely to report its business is in difficulties to its Home NCA or stop providing its services. When the Home NCA does find out from either PSUs who may be experiencing a poor or distressing service, other Payment Service Providers in the community, bad or poor behaviour of the TPP in one or more Host member states, or from regular audit activity, the NCA will withdraw the TPPs authorisation status and update the TPP’s status on its public facing register. The Home NCA will also inform the EBA and update the EBA’s electronic central register and inform all the Host NCAs in the member states where the TPP has “passported” its services.
The TPP is not likely to inform it customers that it has had its AISP and/or PISP roles revoked and may even go on collecting information from PSUs’ accounts and issuing payment initiation requests to ASPSPs. Although to do so is breaking the law!
The TPP will certainly not inform the QTSP which issued its eIDAS certificates and ask for them to be revoked. It is also unlikely that the Home NCA will ask for the certificates to be revoked, for the reasons given above.
What happens if a transaction is initiated by the TPP and what should an ASPSP do?
In an ideal world
In an ideal world the TPP should never initiate a transaction with an ASPSP after it has informed its Home NCA that it is ceasing its operations and the NCA has revoked its payment services licences. However, in the disarray of going out of business, the organisation’s servers may be still operating automatically and providing functionality to the TPP’s customers.
In this case an ASPSP would see a request from the TPP to initiate a transaction. As the ASPSP’s API server and the TPP’s server attempt to perform mutually authenticated TLS, the ASPSP’s transport layer security system would try to validate the TPP’s eIDAS QWAC and find that the certificate had been revoked. At this point the transaction would be terminated by the ASPSP’s API server.
If the TPP is a good actor
Here the TPP has notified its Home NCA but has not requested its QTSP to revoke its eIDAS certificates.
In this scenario the ASPSP would see a request from the TPP to initiate a transaction. As the TPP’s eIDAS QWAC has not been revoked the ASPSP’s API server and the TPP’s server will be able to mutually authenticate each other and establish a TLS encrypted channel between the two organisations.
If the ASPSP relies only on the TPP’s eIDAS certificate to identify the TPP, there is no reason why the illegal transaction would not complete successfully. The result being that either the ASPSP passed PSU data to an unauthorised TPP or that the ASPSP processed an illegal payment transaction from an unauthorised TPP. In either case the PSU would be able to seek recompense from the ASPSP. The ASPSP could look for compensation from the TPP however, it should be noted that there is unlikely to be any contractual or legally binding agreement(s) between the ASPSP and TPP. The ASPSP may also be in breach of GDPR or a Capital Requirements Directive, as identified by lawyer Kai Zhang, Associate Director, Bryan Cave Leighton Paisner, in his paper PSD2 Open Banking – TPP Identification: “To Check or Not to Check”, published on 15 May 2019.
As Dmitrii Barbasura points out in his paper on “TPP identification challenge for ASPSP under PSD2” there are five checks that need to be performed to validate a PSD2 eIDAS certificate.
- Has the PSD2 eIDAS certificate been issued by an approved QTSP?
- Has the PSD2 eIDAS certificate expired?
- Has the PSD2 eIDAS certificate been revoked?
- What PSD2 roles have been assigned to the TPP?
- Has the possession of the eIDAS’ private key been verified?
Check number 4 states that an “ASPSP should check the PSD2 role/permission assigned to the TPP in order to allow access only to the actions authorized by the National Competent Authority (NCA). The PSD2 roles are indicated in the certificate: PSP_AI – account information, PSP_PI – payment initiation, PSP_CI – confirmation of funds, PSP_AS – account servicing.”
These PSD2 roles, although true at the time the certificate was issued and when the QTSP checked with the NCA what payment services the TPP had been authorised/registered to provide, this could have changed at any time thereafter. That change of status, suspension or revocation may not have been reflected in the TPP’s eIDAS certificate. So, at the time of the transaction, the ASPSP needs to check with the NCA what payment services the TPP is authorised to provide and the PSD2 roles for which it is authorised thereby ensuring that they are consistent with the function the TPP is requesting the ASPSP to perform.
If the ASPSP, as well as having checked the eIDAS certificate, has also checked the regulatory status of the TPP on the TPP’s Home NCA register then it would see that the TPP’s status had changed from ‘authorised’ to ‘not authorised’ and stop the transaction. The response message from the ASPSP would contain an error code informing the TPP of the reason why the request message was rejected.
If the TPP is a bad actor
In this case the TPP does not want anyone to know that its business is in trouble and wants to continue operating as long as possible, probably in the hope that things will improve. Hence, the TPP does not inform its Home NCA nor does it request its QTSP to revoke its eIDAS certificates. The TPP remains ‘authorised’ until its Home or a Host NCA has sufficient reason to withdraw its authorised status.
Article 13 of PSD2 gives the following reasons why the withdrawal of authorisation may take place:
- The competent authorities may withdraw an authorisation issued to a payment institution only if the institution:
- does not make use of the authorisation within 12 months, expressly renounces the authorisation or has ceased to engage in business for more than 6 months, if the Member State concerned has made no provision for the authorisation to lapse in such cases;
- has obtained the authorisation through false statements or any other irregular means;
- no longer meets the conditions for granting the authorisation or fails to inform the competent authority on major developments in this respect;
- would constitute a threat to the stability of or the trust in the payment system by continuing its payment services business; or
- falls within one of the other cases where national law provides for withdrawal of an authorisation.
- The competent authority shall give reasons for any withdrawal of an authorisation and shall inform those concerned accordingly.
- The competent authority shall make public the withdrawal of an authorisation, including in the registers referred to in Articles 14 and 15.
If a Host NCA becomes concerned about the TPP’s behaviour in its territory it should inform the TPP’s Home NCA. The Host NCA could then withdraw the TPP’s authorised status locally in order to prevent any further trouble for PSUs and ASPSPs in its jurisdiction.
In the above scenario, where the ASPSP is in a Host member state, the ASPSP would see a request from the foreign TPP to initiate a transaction. As the TPP’s eIDAS certificate has not been revoked the ASPSP’s server would accept the request and establish a secure TLS session with the TPP’s server.
At this point the ASPSP could extract the TPP’s unique authorisation number from the eIDAS certificate and find out which country it was authorised in and the name of its Home NCA. It could then look on the TPP’s Home NCA register to check if this TPP is authorised by virtue of ‘passporting’ its services into the Host member state.
If that was as far as the ASPSP was to check, then the TPP would appear ‘authorised’ on its Home NCA register and the transaction would complete successfully. However, if in addition, the ASPSP was to check the Host NCA’s register, it would see that the TPP was ‘not authorised’ and decline the transaction. It appears clear in this scenario that just checking the eIDAS certificate is insufficient and that the ASPSP should check both the Home NCA and Host NCA registers to properly understand the regulatory status of the TPP.
As Kai Zhang points out in his paper: “PSD2 Open Banking – TPP Identification: To Check or Not to Check”:
“ASPSPs tend to be subject to a multitude of regulatory regimes in addition to PSD2. Even if an ASPSP may not be liable in this respect under PSD2, it is less clear whether or not the ASPSP could possibly incur liabilities under other regulatory regimes if it fails to make such checks or its checks are considered inadequate. By way of one example in this respect, UK credit institutions are subject to the general Principles for Business in the FCA Handbook. Principle 2 requires firms to carry out their business with skill, care and diligence and Principle 3 requires them to have adequate internal controls and risk management systems. If an ASPSP relies solely on the eIDAS certificate and that certificate turns out to be incorrect/invalid, would the ASPSP be in breach of such Principles?”
Meanwhile, as the TPP’s Home NCA has been notified of an issue in a Host member state, the Home NCA should investigate the reported issue and determine whether the problem is only in that one member state or more widespread. The Home NCA should then decide whether to withdraw the TPP’s authorised status in that member state or withdraw the TPP’s authorised status entirely on its Home NCA register.
If this process had completed and the Home NCA had withdrawn the TPP’s authorised status on the Home NCA register, then the transaction would have been rejected at the point that the ASPSP checked the TPP’s regulatory status on the Home NCA register. However, if the TPP was only having problems in one or two member states then there may have been no cause for the Home NCA to withdraw the TPP’s authorised status on the Home NCA register, but simply remove the affected member states from the list of ‘passported to’ countries that the TPP had applied to operate in. Again, if the ASPSP was checking the list of countries where the TPP had been authorised to ‘passport’ its services to then the transaction could have been stopped after the check on the Home NCA register.
Conclusion
If unauthorised or fraudulent transactions take place, the ASPSP will be the first port of call for the impacted PSUs to seek recompense. ASPSPs are the guardians of their customers’ data and they have an obligation under PSD2 and GDPR to only share that data with properly authorised and regulated TPPs who have gained the customer’s explicit consent.
If a customer’s data is shared with an unauthorised TPP or a payment transaction is initiated by an unauthorised TPP, then the customer will look for compensation from the ASPSP and the ASPSP may face fines and regulatory sanctions under PSD2 and GDPR. It is the ASPSP’s responsibility to manage its business and regulatory risk and perform the necessary checks and balances appropriate to its risk appetite.
Information is available from the National Competent Authorities, the European Banking Authority and the QTSPs that would enable an ASPSP to allow or deny a TPP access to a payment account for objectively justified and duly evidenced reasons. However, these data sources are disparate, difficult to access, difficult to interpret and not in a form that is suitable for real time, on-line checking at the scale and pace required for ASPSPs to fulfil their responsibilities to both TPPs and their Payment Service Users in support of open banking transactions.
It is possible for these checks to be carried out in a way that does not present an obstacle to the performance of the transaction between the TPP and ASPSP or cause delays in the ‘customer journey’. An on-line, real time cloud based SaaS platform, accessed via a simple RESTful API and supported by a data repository that has consolidated the above data sources and normalised the data can provide ASPSPs with the right information at the right time at high speed and high volume.
References
- Kai Zhang, Associate Director, BCLP Law
PSD2 Open Banking – TPP Identification: To Check or Not To Check, 15 May 2019
https://www.bclplaw.com/en-GB/thought-leadership/psd2-open-banking-tpp-identification-to-check-or-not-to-check.html
- Dmitrii Barbasura, Founder & CEO at Salt Edge
TPP identification challenge for ASPSP under PSD2, 27 May 2019
https://www.linkedin.com/pulse/tpp-identification-challenge-aspsp-under-psd2-dmitrii-barbasura/
- Directive 2015/2366/EU of the European Parliament and of the Council of 25 November 2015 on payment services in the internal market, amending Directives 2002/65/EC, 2009/110/EC and 2013/36/EU and Regulation (EU) No 1093/2010, and repealing Directive 2007/64/EC.
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32015L2366
- Article 36 of the Directive (EU) 2015/2366 (PSD2)
Access to accounts maintained with a credit institution
- Article 36 of the Directive (EU) 2015/2366 (PSD2)
- Article 37 of the Directive (EU) 2015/2366 (PSD2)
Prohibition of persons other than payment service providers from providing payment services and duty of notification
- Article 37 of the Directive (EU) 2015/2366 (PSD2)
- Article 66 of the Directive (EU) 2015/2366 (PSD2)
Rules on access to payment account in the case of payment initiation services
- Article 66 of the Directive (EU) 2015/2366 (PSD2)
- Article 67 of the Directive (EU) 2015/2366 (PSD2)
Rules on access to and use of payment account information in the case of account information services
- Article 67 of the Directive (EU) 2015/2366 (PSD2)
- Commission Delegated Regulation (EU) 2018/389 of 27 November 2017 supplementing Directive (EU) 2015/2366 of the European Parliament and of the Council with regard to regulatory technical standards for strong customer authentication and common and secure open standards of communication
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32018R0389
- Article 34: Certificates
