I have been working for the past year with a number of groups on the topic of PSD2 Access to Account, and Open Banking. In particular the checks and controls of how access is given.
Thanks to PSD2, ASPSPs (mostly banks) have the obligation to allow access to regulated entities and block access to those that do not have access. There is therefore a requirement that ASPSPs understand who is regulated and for what. Failure to properly check access rights leads to the risk of unauthorised transactions and subsequent claims under PSD2, or unauthorised data sharing and subsequent claims under GDPR.
Over the last year, the industry has reached a clear consensus on some of the basics of the access check which in the end lead to a two-stage Access check – checking the identity via the certificate and checking the roles and passporting information via the competent authority register (or an operation directory as a proxy).
Much of the work, has been done in the framework of the Euro Retail Payments Board (ERPB) which published a report at the end of November 2017 and the ETSI ESI Working Group, creating a PSD2 standard for eIDAS certificates.
Article 34 of the Regulatory Technical Standards on Strong Customer Authentication and Common and Secure Communication (“the RTS”) states that eIDAS certificates will be used for identification and that they will contain “the authorisation number” of the PSP using the certificate, the name of the competent authority that issued that certificate, and the role(s) that the competent authority has.
The RTS specified two types of certificate, the Qualified Website Certificate (QWAC) which is used for securing the transport layer, and the Qualified Certificate for Seals (QSEAL), which is used for signing the business content of the message that is transferred.
The process then works as follows, any ASPSP or TPP that needs a certificate, goes to a certificate issuer (a Qualified Trusted Service Provider, or QTSP) and asks for the correct certificate. The QTSP then makes standard identity checks and (new for PSD2) additionally checks PSD2 attributes – i.e. the number and the roles the entity has in the National Register for each country, which is published by the National Competent Authority of that country. So far, so good, a certificate can be issued.
The situation is more difficult when it comes to the loss of authorisation. What happens if a National Competent Authority (NCA) removes an authorisation from an ASPSP or TPP? The November ERPB report puts it as follows:
“Considering that the NCA is not obliged to inform the QTSP, and the QTSP is not obliged to check the NCA register, it is clear that although we can trust the certificates for Identification, in the case that an NCA has withdrawn a license and the certificate has not yet been revoked, there is a period when the roles in the certificate will not be accurate.
In the case that anybody wishes to check the up to date role of an ASPSP, then they must look at the Home NCA of that entity.
As there will be 31 NCA’s, this raises the need for a machine-readable, standardised repository of TPP details, as published by NCAs.”
The Konsentus Group is creating this machine-readable, standardised repository, which is now being developed and tested by a consortium of banks and service providers.
Conclusion
ASPSPs will use eIDAS certificates to identify a party accessing their account.
ASPSPs will use the National registers for the Authorisation of a party, i.e. understanding if a party is regulated and what that party is authorised to do.
Difficulties in interpreting the national registers require a consolidated source of information, such as the Open Banking Europe Directory.
This access check topic is just one topic that was covered at the ETSI / Open Banking Europe workshop held in Nice on the 20th of March. Specifically, this video has an explanation of the access check.
Article by John Broxis
