Executive Summary:
With the implementation of the Payment Services Directive 2 (PSD2) Access to Accounts (Open Banking) in September 2019, many Financial Institutions have been working towards compliance with the regulation. They are also attempting to navigate the complexities of the new eco-system and understand the opportunities and associated risks of Open Banking.
One particular area of complexity, and significant risk for Financial Institutions, is the identification of the newly regulated entities, commonly referred to as Third-Party Providers (TPPs), with whom no contractual relationship exists. TPPs with the customer’s consent, can access their account(s) at Financial Institutions to collect transactional account information and execute payment transactions (push payments).
This significantly increases a Financial Institution’s exposure to fraud, risk and reputational impact. They must be able to positively verify the identity of the TPP and know their regulated status at the time of the account being accessed, or payments initiated. To mitigate these business risks, Financial Institutions need to be able to access the most up to date information on a TPP’s regulatory status from the legal systems of record, maintained and operated by the 31 National Competent Authorities (NCA) across the European Economic Area (EEA).
A Financial Institution solely relying on the EBA Register to verify the regulatory status of TPPs will have significant and far-reaching consequences. The EBA Register has been set up solely on the basis of information provided by the 31 NCAs. Therefore, unlike NCA Registers under PSD2, the EBA Register has no legal significance and confers no rights in law. Indeed, the EBA Register does not include Credit Institutions (i.e. banks) who act in the capacity of a TPP.
By using incorrect or out of date information, an unauthorised or fraudulent TPP could be given access to a Payment Service User’s (PSUs) accounts, financial data or be able to execute payment transactions. Conversely, an authorised TPP could be declined access, or be unable to execute payment transactions, thereby denying the PSU with the legal right to access services via a regulated entity. Both these scenarios have business ramifications.
The impacts on the organisation would include some or all of the following: financial losses (direct and indirect), loss of customer confidentially, confidence and reputational and brand damage. From a regulatory perspective, Financial Institutions not only have to comply with PSD2, but also GDPR and other financial services duties of care. Needless to say, in these scenarios the Regulators would not look favourably on the negative customer impact.
Introduction
This paper discusses the data held in the EBA Registers, the issues and inconsistences encountered and how Konsentus Verify addresses these problems.
The EBA Registers
The European Banking Authority (EBA) publishes 2 registers of Payment Service Providers (PSPs) that can act as Third-Party Providers (TPPs), as defined by the Second Payment Services Directive (PSD2):
- Credit institution register;
- Payment institution register
These registers contain information provided by the 31 National Competent Authorities (NCAs) of the European Economic Area (EEA) which are the legal entities responsible for regulating the financial conduct of Payment Service Providers established within their home Member State.
According to the EBA the purpose of these registers is to ‘increase transparency and ensure a high level of consumer protection’ within the European Single market.
This white paper discusses the information held in the EBA Registers, the observed issues with relying on this data for risk decisioning, and how the Konsentus solution can plug the gaps created.
Credit Institutions Register
This register only includes credit institutions classified in three different types:
- CRD credit institutions: legally defined as ‘an undertaking whose business is to receive deposits or other repayable funds from the public and to grant credits for its own account’,
- EEA branches operating in each EEA country: branches of credit institutions authorised in another EEA country which have the right to passport their activities,
- Non-EEA Branches, defined as branches of credit institutions having their Head Office in a third country.
Availability
Public users can search the credit institution register of the EBA free of charge via their website.
Disclaimer
“The present Register has been set up by the EBA solely on the basis of information provided by Member States. Therefore, unlike registers of credit institutions maintained at national level, this Register has no legal significance and confers no rights in law. If an unauthorised institution is inadvertently included in the Register, its legal status is in no way altered; similarly, if an institution has inadvertently been omitted from the Register, the validity of its authorisation will not be affected.”
Payments Institutions Register
The register provides consistent information on:
- The identity of authorised payment and electronic money institutions, including payment initiation service providers (PISPs) and account information service providers (AISPs)
- The country of establishment of these providers and the services they provide
- Information on passporting, i.e. the services provided in host Member States
Availability
Public users can search the central register of the EBA free of charge, as well as download the whole content of the register directly from their website.
Disclaimer
“The present Register has been set up by the EBA solely on the basis of information provided by national competent authorities of the EEA Member States. Therefore, unlike national registers under PSD2, this Register has no legal significance and confers no rights in law. If an unauthorised institution is inadvertently included in the Register, its legal status is in no way altered; similarly, if an institution has inadvertently been omitted from the Register, the validity of its authorisation will not be affected.”
Observed Issues with the EBA Registers
The EBA Registers contain information on the identity of Payment Service Providers and on the regulated payment services that they are authorised/registered to provide under PSD2.
Although NCAs provide the information contained in the central registers of the EBA and are responsible for its accuracy and keeping the information up to date, whilst working with the NCA registers and the EBA registers Konsentus has observed a number of issues and inconsistencies with the EBA registers.
The TPP ID, provided by a QTSP within an eIDAS certificate, cannot be found on the EBA Payments Institutions register
Scenario 1: The Account Servicing Payment Service Provider (ASPSP) cannot identify the TPP and rejects the transaction
An ASPSP, relying on the EBA registers, will be unable to verify the identity of the TPP attempting to access its PSD2 interface, either through a dedicated Application Programming Interface (API) or a Modified User Interface (MUI). The ASPSP will not be able to validate the regulated status of the TPP using the EBA registers and may reject the transaction.
This action is non-compliant with the EBA RTS on SCA and CSC. As clarified by the EBA response to issue XIII raised by participants of the EBA Working Group on APIs under PSD2, published on 26 April 2019:
“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 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.”
The TPP would challenge the rejection if it had been properly authorised/registered by its NCA and issued with a valid eIDAS certificate. During the dispute it could be shown that the NCA register contained several, different IDs for the TPP and that the QTSP, that issued the eIDAS certificate, had used a different ID to the one present on the EBA register.
Since the QTSP used a valid ID from the NCA’s register and the EBA takes no liability for the information on its register, the ASPSP would be liable for incorrectly rejecting the TPP’s transaction.
The TPP could hold the ASPSP responsible for any loss of business or revenue it suffered from the invalid rejection of its transactions. Likewise, the Payment Service User (PSU) could seek compensation from the ASPSP for any losses incurred due to their transaction not being executed by the ASPSP.
Konsentus Verify contains all the different IDs present on the NCA’s register and checks the TPP ID, from the eIDAS certificate, against all the recorded ids. The Konsentus service would have been able to verify the identity of the TPP and check what payment services the TPP was authorised/registered to provide thus enabling the ASPSP to comply with the EBA RTS on SCA and CSC.
Scenario 2: The ASPSP relies on the eIDAS certificate to identify the TPP and accepts the transaction
As the ASPSP is unable to use the EBA registers to verify the identity or the regulated status of the TPP it must rely on the existence and content of the TPP’s eIDAS certificate, used to establish the MTLS connection or Seal a message.
The ASPSP will have to check the digital signature on the TPP’s certificate and validate the trust chain back to a known root key for the QTSP. The ASPSP will have had to previously check that the QTSP has been approved and is on the EU’s list of trusted QTSPs, authorised to issue PSD2 Qualified Web Access Certificates (QWACs) and PSD2 Qualified digital Seal Certificates (QSealCs), retrieve the QTSP’s root key and store it in its authentication and web server trust stores.
The ASPSP will need to check, with the QTSP, that the TPP’s certificate has not been revoked by checking the QTSP’s Certificate Revocation List (CRL) or On-line Certificate Status Protocol (OCSP) responder. It will also need to check that the TPP’s certificate is current and has not expired.
Once these checks have been performed and the tests have been successful the ASPSP can extract the TPP’s identity information from the certificate, i.e. the company name, domain name and authorisation number. It will also check that this information is consistent with the Mutually authenticated Transaction Layer Security (MTLS) connection and transaction data.
The ASPSP can also extract specific PSD2 TPP attribute data from the certificate, namely the PSD2 roles, NCA name and NCA ID. The ASPSP should use the TPP role information namely the Account Information Service Provider (AISP), Payment Initiation Service Provider (PISP) or Card Based Payment Instrument Issuer (CBPII), to check that the TPP is authorised to request the particular service via the ASPSP’s open banking interface.
If any of these checks fail, the ASPSP will reject the transaction otherwise the ASPSP has an obligation under PSD2 to accept the TPP’s request for data or payment initiation.
If the TPP’s regulated status had been withdrawn since it was issued with its PSD2 eIDAS certificates then, at the time of the transaction, it was no longer authorised to access PSU data or initiate a payment on behalf of the PSU. In this case the ASPSP would have wrongly processed the transaction and the PSU could challenge the transaction.
Although the TPP should have notified the QTSP that it had had its regulated states withdrawn and requested the QTSP to revoke its eIDAS certificates, experience has shown us that this does not always happen, even if the TPP is a good actor. However, if he TPP is a bad actor then it certainly would not request its certificates to be revoked.
As Nadja van der Veer points out in her paper: “Taking a chance on TPPs: a road banks cannot afford to follow”, published on 19 September 2019:
“An assumption of a bank’s responsibility may even follow from existing PSD2 provisions such as article 73 on unauthorised transactions, where the bank [ASPSP] is responsible for immediately refunding the bank account holder. If a PISP was involved and the latter was to blame, it will still be up to the bank to get the sums paid to the bank account holder and then get reimbursed by the PISP. If the PISP has then vanished, the bank takes the financial hit.”
“Article 89 of PSD2 also places the responsibility on the banks for non-execution, defective or late execution of payments, again, even when a PISP was involved and responsible. The bank would then need to chase the PISP on its own accord.”
Konsentus validates the TPP’s eIDAS certificate and uses the TPP’s identity authorisation number to check the identity of the TPP and verify what payment services the TPP has been authorised/registered to provide using data from the TPP’s Home NCA. This provides the ASPSP with accurate, up-to-date information on the TPP’s regulated status. Even if a TPP still had a valid eIDAS certificate but its regulated status had been changed or withdrawn, using the Konsentus service, the ASPSP would have the correct information on which to make its decision on whether to accept or reject the TPP’s request.
The ID, from an eIDAS certificate, for a credit institution, cannot be found in the EBA Credit Institutions register
Note: Information on credit institutions, even if they are acting as a TPP, is not held in the EBA Payments Institutions register but in the EBA Credit Institutions register.
In this case, an ASPSP, relying on the EBA Credit Institutions register, is unable to find and verify the identity of the credit institution, acting as a TPP, and attempting to access its PSD2 interface. The ASPSP will not be able to verify if the credit institution is licenced or not and may, therefore, reject the transaction.
As the EBA Credit Institutions register is only available for manual look-up via the EBA’s website the ASPSP would not be able to perform this identity validation in real-time without causing a significant delay to the PSU’s transaction response.
Non-compliance with the EBA RTS on SCA and CSC.
The credit institution would challenge the rejection, if it had been properly licenced by its NCA and issued with a valid eIDAS certificate. During the dispute the credit institution could show that the EBA Credit Institutions register did not contain any IDs for credit institutions within its NCA’s jurisdiction and that the QTSP had issued it with a valid eIDAS certificate containing an ID number issued and available on its Home NCA register. However, the EBA does not take any liability for errors or omissions in its register meaning that the ASPSP would be liable for incorrectly rejecting the transaction from the credit institution.
Since the EBA Credit Institutions register is only available for manual look-up via the EBA’s website, the manual validation of credit institutions, acting as TPPs, will become impractical as transaction volumes increase. A requirement of PSD2 is that open banking transactions should be at least as performant as the PSUs’ on-line interface. There is, therefore, a clear need, by the open banking community, for a performant, industrial scale, real-time register containing all authorised TPPs and credit institutions, acting as TPPs.
As Nadja van der Veer explains in her paper: “Taking a chance on TPPs: a road banks cannot afford to follow”, published on 19 September 2019:
“For those banks looking to cover off this risk quickly and comprehensively, there are a few providers who are addressing the practical issues arising out of PSD2, with private registers including real-time TPP identity and regulatory status checking (and some even provide insurance on the information they provide further reducing the risk liability for banks). As with any outsourced solution, it is of course important to make sure it meets your individual business needs and also has all the components needed to mitigate risk, uphold duty of care and protect consumer trust.”
Konsentus Verify contains the credit institution IDs that are available from the NCAs’ registers. The service checks the status of this data continually to ensure that it holds the latest information on all the credit institutions licenced to operate in the EEA. As the service holds this data in an online, real-time database the information is immediately available to ASPSPs without causing any undue delay to PSU transactions. This enables the ASPSP to comply with the EBA RTS on SCA and CSC.
The TPP ID, from an eIDAS certificate, cannot be found in the EBA registers
An ASPSP, relying on the EBA registers, will be unable to verify the identity of the TPP attempting to access its API. The ASPSP will not be able to verify the regulated status of the TPP and will reject the transaction.
Non-compliance with the EBA RTS on SCA and CSC.
The TPP could challenge the rejection if it had been properly authorised/registered by its NCA and issued with a valid eIDAS certificate. During the dispute the TPP can show that the ID held on its NCA’s register is the same as the ID in its eIDAS certificate. However, the ID on the EBA register is formatted differently (i.e. it does not contain any “. or /” as separators).
Since the QTSP used a valid ID from the NCA’s register and the EBA takes no liability for errors in its registers the ASPSP would be liable for incorrectly rejecting the TPP’s transaction.
Konsentus Verify contains TPP IDs in the format present on the NCA’s registers and on the EBA’s registers. The Konsentus service would have been able to match the ID of the TPP, found in the eIDAS certificate, against its records and check what payment services the TPP was authorised/registered to provide. This enables the ASPSP to comply with the EBA RTS on SCA and CSC.
The TPP ID, from an eIDAS certificate, matches multiple records in the EBA registers
An ASPSP, relying on the EBA register, finds multiple records for the same TPP ID. The records are similar but show different payment services have been authorised/registered to the TPP. The ASPSP is not able to identify which TPP record should be used to accept or reject the transaction request for a specific payment service. As the ASPSP must respond to the transaction in a timely manner it risks incorrectly accepting or rejecting the transaction request.
If the ASPSP makes the wrong decision the TPP or PSU could challenge the decision and hold the ASPSP liable for any financial losses incurred due to the incorrect processing of the transaction. Since the EBA does not take any liability for errors in its registers the ASPSP would be liable for incorrectly accepting or rejecting the TPP’s transaction.
Konsentus Verify contains only one record per TPP and holds the payment services present on the TPP’s Home NCA register. The Konsentus service would have returned a single response for the TPP ID with the correct information on the payment services the TPP was authorised/registered to provide. This enables the ASPSP to comply with the EBA RTS on SCA and CSC.
The TPP has a status of ‘authorised’ on the EBA register but hidden within the TPP’s record on its Home NCA register there are restrictions on its regulated activities (in effect it has been suspended)
An ASPSP, relying on the EBA register, verifies the identity and regulatory status of the TPP. The EBA record shows that the TPP is authorised/registered to perform the requested payment service. The ASPSP rightly accepts the transaction, based on the EBA data, but wrongly accepts the transaction, based on the TPP’s Home NCA data. Since the TPP’s Home NCA register is the legal record of the TPP’s authorisation status, and as the disclaimer on the EBA register quotes “this Register has no legal significance and confers no rights in law”, it would be unwise for an ASPSP to accept the transaction on the strength of the EBA register alone.
Non-compliance with the EBA RTS on SCA and CSC.
As Kai Zhang points out in his paper “PSD2 Open Banking update and operational issues with regulators’ registers”, December 11, 2019:
“where a TPP’s authorisation is merely suspended (wholly or partially) in the sense that it is not allowed to engage in the regulated activities subject to the suspension, but it remains an authorised firm, the issue could become more challenging. In the UK, such suspension is by way of the FCA imposing restrictions on the firm and such restrictions are buried rather deep in the FCA register.”
The PSU could challenge the transaction since the TPP had been suspended from providing regulated services by its Home NCA at the time of the transaction request. Since the EBA does not take any liability for errors or omissions in its registers the ASPSP would be liable for incorrectly accepting the TPP’s transaction.
Konsentus Verify contains information on any restrictions to a TPP’s regulated payment services. A future release of Konsentus Verify will return a warning message to the ASPSP notifying it of the restrictions to the TPPs regulated activities. Thus, enabling the ASPSP to take a risk-based decision on whether to accept or reject the TPP’s transaction request.
A TPP is authorised on its home NCA register but not on the EBA register.
Two Polish TPPs (Blue Media, PayU) who gained authorisation from the Polish NCA for payment services 7 and 8 in November 2019 did not appear on the EBA register until February 2020. It took nearly 3 months for their regulatory status to be reflected on the EBA register.
An ASPSP, relying on the EBA register during this period, would have wrongly rejected the transaction from the TPP.
Non-compliance with the EBA RTS on SCA and CSC.
The TPP and PSU would challenge the rejection and hold the ASPSP liable for any financial losses incurred due to the incorrect processing of the transaction, as the TPP had been properly authorised by its home NCA.
Since the EBA does not take any liability for errors or omissions in its registers the ASPSP would be liable for incorrectly rejecting the TPP’s transaction.
Konsentus Verify contains the regulatory status of all authorised or registered TPPs gathered from all the NCA registers in the EEA. The service checks the status of this data continually to ensure that it holds the latest information on all the payment service providers licenced to operate in the EEA. As the service holds this data in an on-line, real-time database the information is immediately available to ASPSPs without causing any undue delay to PSU transactions. This enables the ASPSP to comply with the EBA RTS on SCA and CSC.
The Payment Services a TPP is authorised to provide on its home NCA register are not the same as the Payment Services on the EBA register.
At a point in time 8 TPPs, which had been authorised to provide PSD2 payment services 1-8 in their home NCA and EBA registers, were changed to having only payment services 1-6 in the EBA register. This change was not reflected in their home NCA register. This mismatch of authorised payment services information persisted in the EBA register for several weeks.
This shows that just because a TPP’s regulatory status was correctly entered in the EBA register by an NCA, it is not guaranteed that the information will remain correct, even if the TPP’s status doesn’t change on the NCA register.
Konsentus Verify contains the regulatory status of all authorised or registered TPPs gathered from all the NCA registers in the EEA and from the EBA registers. The service prioritises the information gathered from the NCAs over the information in the EBA registers. This is because it is the NCAs that are responsible for regulating the TPPs in their jurisdiction. As the EBA themselves say on their website, “unlike national registers under PSD2, this EBA Register has no legal significance and confers no rights in law. If an unauthorised institution is inadvertently included in the Register, its legal status is in no way altered; similarly, if an institution has inadvertently been omitted from the Register, the validity of its authorisation will not be affected.”
Konsentus Verify provides the most current TPP information available on the payment services that TPPs are authorised/registered to provide. This enables ASPSPs to comply with the EBA RTS on SCA and CSC.
Conclusion
As has been highlighted and discussed in this paper, there are far reaching and significant consequences for ASPSPs solely relying on the EBA Register to verify the regulatory status of TPPs.
The EBA Register has been set up solely on the basis of information provided by the 31 NCAs. Therefore, unlike NCA Registers under PSD2, the EBA Register has no legal significance and confers no rights in law. Indeed, the EBA Register does not include Credit Institutions (i.e. banks) who act in the capacity of a TPP.
By using incorrect or out of date information, an unauthorised or fraudulent TPP could be given access to a Payment Service User’s (PSUs) accounts, financial data or be able to execute payment transactions. Conversely, an authorised TPP could be declined access, or be unable to execute payment transactions, thereby denying the PSU with the legal right to access services via a regulated entity. Both these scenarios have business ramifications.
The impacts on the organisation would include some or all of the following; financial losses (direct and indirect), loss of customer confidentially, confidence and reputational and brand damage. From a regulatory perspective, ASPSPs not only have to comply with PSD2, but also GDPR and other financial services duties of care. Needless to say, in these scenarios the Regulators would not look favourably on the negative customer impact.
As payments lawyer, Nadja van der Veer, points out in her article “Why gaps in the EBA Register leave worries over security”, published July 2019, even though the EBA register fulfils its legal responsibilities, if something goes wrong when verifying the authorisation of a TPP:
“…it’s highly likely that it will be the bank [ASPSP], that ends up paying for it”
