This white paper discusses the data held in the NCA Registers, the issues and inconsistencies encountered and how Konsentus Verify addresses these problems.
What are the NCA Registers and what information do they hold?
There are 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 (PSPs) established within their home Member State.
Each NCA publishes information about the Payment Service Providers under its regulatory control, including organisation name, address and identification number. The NCAs provide this information in a range of different registers, formats and languages.
According to the European Banking Authority (EBA) the purpose of these registers is to ‘increase transparency and ensure a high level of consumer protection’ within the European Single market.
There are two classes of Payment Service Providers defined by the regulations:
- Payment Institutions (including Electronic Money Institutions)
- Credit Institutions
Payment Institutions
Under the Second Payment Services Directive (PSD2) the types of payment services a Payment Institution or an Electronic Money Institution can be licenced to provide are defined as:
Payment Services
- Services enabling cash to be placed on a payment account as well as all the operations required for operating a payment account.
- Services enabling cash withdrawals from a payment account as well as all the operations required for operating a payment account.
- Execution of payment transactions, including transfers of funds on a payment account with the user’s payment service provider or with another payment service provider:
- execution of direct debits, including one-off direct debits;
- execution of payment transactions through a payment card or a similar device;
- execution of credit transfers, including standing orders.
- Execution of payment transactions where the funds are covered by a credit line for a payment service user:
- execution of direct debits, including one-off direct debits;
- execution of payment transactions through a payment card or a similar device;
- execution of credit transfers, including standing orders.
- Issuing of payment instruments and/or acquiring of payment transactions.
- Money remittance.
- Payment initiation services.
- Account information services.
Credit Institutions
Credit Institutions are regulated under an earlier directive which did not contain the above payment service definitions. However, since Credit Institutions are covered by a more rigorous regulation, they can automatically provide any, or all, of the above payment services without seeking any further permission from their regulatory authority.
Observed Issues with the NCA Registers
The NCA 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. Whilst working with the NCA registers, Konsentus has observed some issues and inconsistencies.
Some NCA registers hold multiple id numbers for TPPs
Scenario 1: The TPP ID, from an eIDAS certificate, cannot be found in the NCA register
Because the NCA register holds multiple IDs for the TPP, an Account Servicing Payment Service Provider (ASPSP) may not be able to find the TPP in the register using the ID value from the eIDAS certificate. The ASPSP will, therefore, be unable to verify the identity of the TPP attempting to access its PSD2 interface, through either a dedicated Application Programming Interface (API) or a Modified Customer Interface (MCI), nor will it be able to validate the regulated status of the TPP and may reject the transaction, wrongly assuming that the TPP is not authorised.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.”
No doubt 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, who issued the eIDAS certificate, had used an ID that was not searchable in the NCA register.
Since the QTSP had used a valid ID from the NCA’s 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.
The Konsentus solution, 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. Konsentus Verify would have been able to verify the identity of the TPP and check what payment services the TPP was authorised/registered to provide, 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 find the TPP in the NCA register it must rely on the existence and content of the TPP’s eIDAS certificate. This is used to establish the MTLS connection or Seal a message to verify the identity and regulated status of the TPP.
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). Then, 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, ie 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 this 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 that this does not always happen, even if the TPP is a good actor. However, if the 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 continually monitors all 31 NCA websites and extracts all relevant information. If an NCA provides multiple TPP ID numbers, the Konsentus service records them all. Konsentus Verify validates the TPP’s eIDAS certificate and uses the TPP’s identity authorisation number to check the identity of the TPP, against any of the stored id numbers. The payment services the TPP has been authorised/registered to provide are then verified. By using the Konsentus service, even if a TPP still had a valid eIDAS certificate but a withdrawn or changed regulated status, the ASPSP would have the correct information on which to make its decision on whether to accept or reject the TPP’s request.
A PSP record cannot be found on an NCA register that was there a few days ago:
Some NCAs only keep currently authorised TPPs on their register and remove a TPP record from their register when the TTP’s authorisation has been withdrawn.
This only enables ASPSPs to check the current regulated status of a TPP and not what its status was in the past. If the TPP is on the register, it is authorised, if it is not on the register, it is not authorised.
However, if a TPP subsequently has its authorisation withdrawn and a PSU challenges the ASPSP, claiming that the TPP is not authorised, the ASPSP will not be able to find the TPP on the NCA register. Therefore, it will not be able to retrospectively show that the TPP was authorised at the time the transaction took place.
Without this historical information and, in the case of a dispute with a PSU, ASPSPs will find it difficult to show that the TPP was authorised at the time of the transaction and subsequently had is authorisation withdrawn and its record removed from the NCA register.
Konsentus Verify retains a history of the NCA registers and an immutable log of all the TPP checks it performs. If a dispute between a PSU and an ASPSP occurs, it is possible to look back at the state of the NCA register at the time the transaction took place and verify the regulated status of the TPP. Konsentus Verify is not only able to verify the identity of the TPP and check what payment services the TPP was authorised/registered to provide at the time of the transaction, but the immutable log and NCA register history can be used by ASPSPs as evidence for dispute resolution.
A TPP’s passporting information cannot be found on the NCA register:
Within the EEA, TPPs have the right to offer their payment services in all other EEA countries. However, if they want to exercise this right, they must notify their home member state NCA which countries and what services they wish to provide. The home member state NCA then notifies the NCAs of all the other member states where the TPP wants to provide payment services. And, if the other member states do not object, the TPP is free to provide services in the other member states.
If an ASPSP is approached by a TPP, via its PSD2 interface, and that TPP is operating from another member state, the ASPSP needs to check that the TPP has been authorised to provide payment services in its country.
To prove its identity, the TPP will present the ASPSP with a qualified eIDAS PSD2 certificate. Inside the certificate is information identifying which NCA is responsible for regulating the TPP and which has authorised it to provide payment services under PSD2. The ASPSP can use this information to check the regulatory status of the TPP, and if it has been authorised to provide payment services in the country of the ASPSP.
Konsentus has noticed that some NCAs do not necessarily report passporting information on their registers. This leaves the ASPSP with a problem. Should they honour the TPP’s request, based on the TPP’s home member state authorisations or, should they reject the TPP’s request as they are unable to verify what if any payment services the TPP is authorised to provide in the country of the ASPSP?
The Konsentus PSP identity and regulatory checking service, Konsentus Verify gathers passporting data from the NCAs’ registers and from the EBA registers. By combining data from these multiple sources, Konsentus can provide ASPSPs with the broadest range of passporting information.
Multiple records, for the same PSP, are found in different registers with differing information within the same NCA website.
Some NCA websites have more than one register recording the regulatory status of PSPs. So, a single PSP can appear in more than one register and have different payment services attributed to it.
Sometimes, the only way to resolve this issue, is by having a direct relationship with the NCA, who can direct you to the correct register. Konsentus has observed that the information from the wrong register has also been transposed on to the EBA registers and that the EBA website that gives links to the NCA websites also directs you to the wrong register.
An ASPSP relying on this incorrect register would be at risk of making the wrong decision on whether to allow a TPP access to its PSD2 interfaces or not. This would lead to the TPP challenging the rejection as it had been properly authorised by the NCA to provide payment services.
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 maintains communications with the NCAs to ensure that its PSP identity and regulatory checking service contains the correct regulatory information supplied by the NCAs. Konsentus therefore provides ASPSPs with accurate, up-to-date information on the regulated status of TPPs. Konsentus also has liability insurance which warrants the data provided, enabling ASPSPs to manage their risk when deciding on whether to accept or reject a TPP’s request to access account information.
Some NCA registers return different results when searched in English to when they are searched in their native language:
On some NCA websites the register information is provided in multiple languages. Konsentus has found that the results of a PSP search can return different results depending on which language the search is conducted in.
An example of this is a TPP who could not be found when the search was conducted in English as the common language. However, when the same search was conducted in the register’s native language, the TPP was found and its regulated status could be determined.
If the ASPSP had accepted the results of the first search, in English, it would have wrongly rejected the transaction believing that the TPP was not authorised as it did not appear on the NCA’s register.
Konsentus Verify continually monitors all 31 NCA websites and extracts all relevant information, regardless of language. This information is normalised and provided to ASPSPs via a RESTful API which returns all the information on the PSP that the ASPSP needs to make an informed decision on whether to accept the TPP’s access to accounts request or not.
An NCA register is unavailable:
Between November 2019 and December 2019, NCA register uptime was below 99% for 7 of the 31 NCAs, with the worst uptime being only 82%.
This means that ASPSPs relying on these NCA registers, to validate the identity and regulatory status of TPPs, would not be able to provide a service that is as available and fast as the ASPSPs’ user interfaces, as required by PSD2.
The ASPSPs would have to choose whether they did not respond to TPP requests during the times the NCA registers were offline or if they would rely entirely on the PSD2 role information contained within the TPPs’ eIDAS PSD2 certificates, aware that this information may be out-of-date at the time that account access is being requested.
Konsentus Verify is a high availability SaaS based service that runs on the AWS cloud. It monitors all 31 EEA NCA websites continuously and always holds the latest information on the regulatory status of Payment Service Providers. Any down-time issues with individual NCA websites would not be visible to ASPSPs who would always get the latest regulatory information available on PSPs.
The TPP has a status of ‘authorised’ on the NCA register. However, hidden within the TPP’s record there are restrictions on its regulated activities (in effect it has been suspended).
An ASPSP, relying solely on the TPP’s headline regulatory status on the NCA register, could accept the transaction. But this would be the wrong decision, based on the additional data that is available deeper in the NCA’s website, where it would be seen that the TPP had been suspended from providing any regulated services.
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.”
A PSU could challenge any transaction via this TPP since the TPP has been suspended from providing any regulated services by its NCA.
The Konsentus PSP identity and regulatory checking service contains information on any restrictions to a TPP’s regulated payment services. A future release of the Konsentus service will return a warning message to the ASPSP notifying it of the restrictions to the TPPs regulated activities. This will enable the ASPSP to take a risk-based decision on whether to accept or reject the TPP’s transaction request.
A home NCA has not kept host NCAs updated with regulatory changes it has made to Payment Service Providers on its registers.
An ASPSP, relying solely on its home NCA register, may not be made aware of changes to the regulatory status of foreign TPPs providing PSD2 services in its jurisdiction. This could lead to it making the wrong decision to either accept or reject a transaction from a foreign TPP.
For example in January 2020 the French NCA, ACPR (Autorité de Contrôle Prudentiel et de Résolution), reported that:
“Following a recent review of its register of financial intermediaries, the Financial Conduct Authority (FCA), the British supervisory authority, informed the ACPR on July 22, 2019 that entities registered in the United Kingdom and authorised to practice in France through the European passport system, their authorisations had been withdrawn by the FCA in the past without the ACPR having been notified of the cancellation of the corresponding passport activities.”
It is not a legal requirement for a host NCA to hold data on TPP’s passporting their services into their jurisdiction from another country. The home NCA of the TPP has the legal responsibility to provide accurate information on where and what services the TPP can provide in other Member States.
An ASPSP should look at the TPP’s home NCA register to determine if the TPP has the appropriate regulatory status to provide payment services in its jurisdiction. This passporting information can be quite difficult to find on some NCA registers as it can be several layers down on their websites.
Konsentus monitors TPP data from all 31 NCAs register, including passporting information. The Konsentus service tells the host ASPSP what payment services a TPP can provide in the TPP’s home Member State (the country in which it is based and registered) and what payment services the TPP is authorised to provide in the host Member State of the ASPSP i.e. what services the host NCA has been informed that the TPP has passported into its jurisdiction.
Conclusion
Whilst the NCA registers are the legal record of Credit Institution and PSP/TPP identity and regulatory status, being able to access and interpret the information is a considerable challenge. The Konsentus PSP identity and regulatory checking service uses the information provided by the NCAs and makes it available to ASPSPs via a simple, RESTful API in a consistent, standardised form. This reduces the effort and risk for ASPSPs providing PSD2 compliant interfaces to TPPs.
