Response to consultation on the Technical Standards on the EBA Register under PSD2
Go back
We welcome the opportunity to comment on the EBA’s consultation on draft Regulatory Technical Standards setting technical requirements on development, operation and maintenance of the electronic central register and on access to the information contained therein, under Article 15(4) of Directive (EU) 2015/2366 (PSD2) and draft Implementing Technical Standards on the details and structure of the information entered by competent authorities in their public registers and notified to the EBA under Article 15(5) of Directive (EU) 2015/2366 (PSD2).
UK Finance is a trade association representing nearly 300 of the leading firms providing finance, banking, markets and payments-related services in or from the UK. UK Finance has been created by combining the activities of the Asset Based Finance Association, the British Bankers’ Association, the Council of Mortgage Lenders, Financial Fraud Action UK, Payments UK and the UK Cards Association.
Our members are large and small, national and regional, domestic and international, corporate and mutual, retail and wholesale, physical and virtual, banks and non-banks. Our members' customers are individuals, corporates, charities, clubs, associations and government bodies, based in the UK and overseas, served domestically and cross-border. These customers access a wide range of financial and advisory products and services, essential to their day-to-day activities, from our members. The interests of our members’ customers are at the heart of our work.
OUR RESPONSE
The important and pivotal role the national and EBA registers play in supporting the new payment environment
UK Finance strongly supports the EBA’s conclusion that the technical requirements related to the development, operation and maintenance of the EBA Register should contain high level technical requirements related to: (i) the insertion of information in the register, including the automated transmission of information between the national competent authorities (NCAs) and the EBA, and the access of the different users to the register; (ii) the safety, security and integrity of the information contained in the register; (iii) the recording of the information; and (iv) the search of information in the register.
However, we think a vital component is missing from the proposals, which do not appear to address the fact that PSD2 is an important step towards a ‘Digital Single Market’ in Europe, which also represents a significant, European-wide shift in terms of the accessibility of customer data to third parties. The registers that the NCAs and the EBA are required to deliver are essential elements of the operating and risk management model for checking the authorisation and registration status of Payment Initiation Service Providers (PISPs), Account Information Service Providers (AISPs) and Account Servicing Payment Service Providers (ASPSPs), both from a customer protection and from a liability model perspective, bearing in mind that contractual agreements between the parties cannot be mandated. Accordingly, in our view, the national and European authorities have a major role to play in ensuring that their own services are available in time with functionality enabled that can support and promote a reliable, 24x7x365, automated and highly interoperable environment.
Fundamentally, the EBA Register needs to support a highly automated, sophisticated and largely machine-driven communication layer between competent authorities and ASPSPs, PISPs and AISPs. This is an essential building block for a thriving FinTech sector across the European Union and is a key enabler for the success of PSD2.
The need for prompt action by the national authorities and the EBA to ensure that the information is kept up-to-date
We believe that the EBA’s current proposed approach creates issues with potential time lags between revocation of a third party’s authorisation/registration status or permission(s) and the availability of data checks to be conducted by an ASPSP and offers the potential for human error. This also represents a risk to both the ASPSP and, ultimately, the end customer and does not provide the necessary consumer protection in line with the spirit of PSD2. To support the evolution of the payments landscape, which brings third party provider (TPP) services into scope of the Directive and is driven by the development of the FinTech market and the growth in internet and mobile payments, our recommendation is that the EBA should provide a mechanism for ASPSPs to be able to validate TPP permissions electronically and in near real-time. Alternatively, if such a system cannot be delivered in the short term, there should at least be a process for event-based messages to be issued when trigger events occur (trigger events being additions, changes, or revocations of Authorisation/Registration or permissions).
We see it as imperative that the NCAs have the capability to revoke or suspend authorisation/registration immediately and to update the Register in real-time when they have received evidence of, for example, fraud by a third party or a similar serious issue. Fraud and cyber-attacks take place at lightning-speed, moving from institution to institution in seconds if not in parallel. The risk of customer distress and the potential implications for financial stability in the event of sophisticated large-scale attacks, necessitates a very robust and rapid approach.
Promotion of the highest common denominator, automation and efficient processes
PSD2 is a maximum harmonisation directive but the consultation paper appears to be supporting a fragmented environment at the NCA level. We would therefore like the EBA to recommend that all NCAs use the automated process as our preference remains that, as far as possible, updates are made not just ’without delay’ but ‘immediately’. While we appreciate that the EBA may not be able to mandate this within the scope of PSD2, we believe the EBA should at least strongly encourage all NCAs that have many register entries (the parameters of which should be defined and the position reviewed on a regular basis) to use the automated process and to report on their performance to promote timely updates (e.g. twice a day) and the adoption of the automated channel. The Register will be supporting a very automated and real-time environment, therefore the Register itself should be similarly automated and updated in as near to real-time as possible. Importantly, we feel the EBA should encourage the highest common denominator, as the harmonised standard across the EU, and not the lowest.
We support the view that NCAs favouring an automated approach for transmission should retain manual insertion and modification as a fall-back option. This is good practice from a contingency planning perspective. However, we strongly feel that manual insertion should not be used as the primary means of updating the EBA Register. This is because we would see the EBA’s Register being used as the main source of information for many firms to check the authorisation status of third party firms when they seek to access a payment service user’s account. There are potentially serious implications for fraud and financial stability and the Register’s importance in preventing this should be reflected in its performance and usability.
Transmission of data from the NCAs to the EBA: we question the selection of option 1
We would welcome the EBA reconsidering the selection of Option 1 in relation to the transmission of data to the EBA from NCAs. We feel that from a good principles perspective, reloading all data in every instance where there is an addition or modification is not the most efficient approach as it would be cumbersome in the extreme and would create an unnecessary time lag to ensuring up-to-date information and the availability of the EBA Register.
Furthermore, one day for data refreshes from the NCA to the EBA seems too slow, especially in a scenario where a bad actor may have been revoked from the underlying NCA Register. For example, revocation may have taken place on a Friday but this may not have been reflected in the EBA Register until the Monday while, in the meantime, payment service users may still be using the services of the now unauthorised firm. Considering the number of payment transactions and/or data requests that could occur within a day across the ecosystem, we would urge the EBA to further assess Option 2 specifically in terms of the lead time it would take to update the Register. We firmly believe that there is a need for real-time or near real-time updates given the crucial role the Register will play in determining the authorisation status of providers of PIS and AIS services.
If option 1 is to remain the chosen option, we would urge the EBA to investigate alternative technical solutions which shorten the proposed one-day lead time to update the Register. Ultimately, the most important aspect is that the Register can be used as a single source of reliable and accurate information. If service levels are low, or if updates take too long, then the value of the EBA Register is diminished since ASPSPs, PISPs and AISPs will not be able to rely fully on the information. As mentioned, we would strongly encourage the EBA to investigate technical solutions which are as near to real-time as possible. The EBA will need to be clear regarding how long an NCA has - from the point of changing a status of an entrant - to update the EBA Register and how long it will take for the EBA Register to reflect any changes. This will allow firms to take risk-based decisions on whether to use the EBA Register or whether they would need to revert to NCA Registers.
We would also encourage the EBA to put in place appropriate controls to ensure that the Register is only updated by authorised personnel and that information transmitted between NCAs and the EBA is done so securely. This is to minimise the risk of unauthorised modification, defacement and denial of service attacks.
Additionally, it would be helpful if the EBA could clarify how the reloading of data will impact the availability of the Register. Would the out-of-date data be available until the new data is refreshed or would the Register be unavailable until this data refresh is complete? Will there be a change log of some kind to highlight what changes have been made at every refresh?
The EBA should consider the fact that ASPSPs will also need to verify whether a PISP or AISP is passported in from another Member State so the Home state should therefore also be stated.
Potential lessons to be learned from related industry/market developments
There are several industry developments, which the EBA could usefully consider as a way of gaining insight into market needs, best practices and possible technical solutions as well as giving thought to potential synergies. For example, PRETA (https://www.preta.eu/) has launched a project to deliver a pan-European directory to provide relevant information about ASPSPs and TPPs.
In the UK, the Open Banking Implementation Entity (ttps://www.openbanking.org.uk/) is developing an Open Banking Directory to provide an automated mechanism (using APIs) for on-boarding, registering and validating TPPs in real-time while also considering security and other key non-functional requirements (e.g. performance and scalability).
As mentioned elsewhere in this response, we see several possible use cases for the EBA Register, which could include:
• providing a real-time view of TPPs who are authorised and registered, and credit institutions providing PIS and AIS;
• identifying permissions (or where such permission is withdrawn) and passporting;
• supporting the management of an API ecosystem and certification in accordance with eIDAS.
UK Finance supports the EBA’s views that the EBA Register should fulfil objectives related to PSD2 around the role of the Register for increasing transparency of the operation of non-bank PSPs and facilitating cooperation between competent authorities.
We had assumed that the full EBA Register could at least be downloaded manually but we are not certain that even this is the case. The ‘download’ references within the EBA Register refer to downloading the search results rather than the full register. The references are:
• Article 19(5) indicates that “The user of the register shall be able to download the search results under paragraph (2) and the information displayed for each natural or legal person under paragraph (3) and (4) in a separate file”;
• Article 7(3) indicates that “The access of public users to the electronic central register of the EBA shall allow them only to read, search and download the information contained in the register”
At the public hearing on 4 September, the EBA appeared to indicate that the current draft proposal was that only the search results could be downloaded rather than the Register in its entirety. We would strongly recommend that the EBA, as a minimum, makes it possible to download the full register and that it includes functionality to provide the ability to automate that download.
The importance of automation and machine readability
As we mentioned in our answer to question one, the EBA Register is a key enabler for the success of PSD2. We believe that it is of the upmost importance to ensure efficiency and Straight-Through-Processing, that the EBA Register is fully machine readable.
We note from paragraphs 21 and 22 of the consultation paper that the EBA had considered making the EBA Register “machine readable” to enable automatic extraction of information. We understand, from what was said at the EBA public hearing, that the possibility of creating an interface that would allow external applications to search the Register automatically was discounted on the basis that it would be too costly and would impact the IT project implementation timelines by 3 to 6 months.
We would strongly urge the EBA to reconsider the ability to extract information automatically from the EBA Register i.e. to ensure that it is machine readable. The EBA Register is likely to be used as the main source of information for many firms to check the authorisation status of third party provider firms. As such, the ability to efficiently and effectively interrogate the register in a manner that is as near real-time as possible is essential to ensure the integrity of the ecosystem and to protect all actors within it. It is also very important from an investment perspective as many ASPSPs will be looking to create automated systems and processes to check the EBA Register. Otherwise ASPSPs may have to employ staff and develop processes to interrogate the EBA Register and NCA Registers on a manual basis.
The costs and risks of ASPSPs having to rely on manual processes
While it is difficult to quantify the costs arising from ASPSPs needing to rely on manual processes, since it would depend upon bespoke approaches adopted by individual PSPs, it would seem reasonable to assume the sum would most likely exceed the cost that development of a central automated EBA solution would entail.
Searching, retrieving and validating information on a manual basis will be time consuming, affecting service quality for both TPPs and customers, and will not easily be scalable to accommodate growing volumes of PIS and AIS requests. Operational risks will be greater due to the risk of human error and problems in identifying potential fraud.
We would therefore welcome further comment on the EBA’s statement that introduction of “machine readable” functionality would give “marginal added value” in relation to the cost incurred by the EBA. We do not agree that this is the most appropriate lens through which to make an assessment. We ask that the EBA (and NCAs) take a much broader approach to the cost-benefit analysis by considering the implications of this decision on the costs and benefits (or detriments) to the wider ecosystem because of choosing not to make such a system machine readable.
In addition, NCAs would have until the RTS deadline to implement the machine-to-machine accessibility – which might make implementing the changes somewhat easier to accept and would also recognise the timeline by when the full ecosystem would need to work in an STP-like manner.
Alternative approaches for the EBA to consider
In case it proves impossible for the EBA to take on board industry concerns and the associated cost this would have for ASPSPs, AISPs and PISPs, we would advocate a function that would enable an automated download of the full list. We think that this is a middle ground between making the EBA Register “machine readable” and having to manually download the full register. Thus, the full EBA Register would be downloadable via a “machine” (API) request. This would not be the same as making the EBA Register searchable via “machine readable” API requests. However, it would allow ASPSPs to create and invoke daily scheduled requests to download automatically the full EBA Register via an API and/or each individual home member register if there has been a change. ASPSPs would create a ‘local’ copy of the EBA Register to verify and validate that an AISP or PISP is registered and authorised for the services being performed on behalf of the customer. The ability to download the EBA Register automatically would also remove new ongoing cost to the ASPSPs by eliminating the need for a member of the staff to perform a manual download each day. It would also reduce the risk of manual errors that could occur.
eIDAS
Finally, paragraph 23 of the consultation paper refers to Article 29(2) (now Art. 34(2)) of the RTS on strong customer authentication and common and secure communication relates to Certificates. We have taken this article to refer to eIDAS, and the use of qualified trust service providers to identify and validate the third party. There is no reference or direction to performing the PISP/AISP identification when utilising a dedicated interface (i.e. API), which is likely to be the standard approach for ASPSPs.
We think that the EBA and the NCAs should have a longer-term approach to considering capacity, capability and performance. The EBA should consider reviewing non-functional requirements on a regular basis e.g. yearly or quarterly. This includes using at the very least bank grade security for the Register and the EBA should also consider the risk of denial of service attacks and the appeal to fraudsters of changing/creating PISP/AISP details.
As a further point, if the EBA Register or an NCA Register experiences an outage – should firms stop providing data/making payments or should they carry on even though they are at risk?
We support development of a comprehensive single listing of all PSPs offering PISP or AISP services and would encourage the EBA also to incorporate credit institutions offering PIS and AIS services into the EBA Register. The EBA should at least make it possible, on a voluntary basis, for credit institutions offering AIS and PIS to be listed on the register.
We are also concerned that payment service users will not appreciate that there are two EBA Registers (the other being the Credit Institution Register set up in relation to the Capital Requirements Directive). The risk is that the payment service user may search for a credit institution in the proposed PSD2 EBA Register but will be unable to find the firm and may therefore conclude that the credit institution is not authorised to provide PIS and AIS. While we appreciate that the EBA may feel that it does not have a mandate under PSD2 to include credit institutions, it would be helpful if some thought could be given as to the best way of informing the public that two Registers exist.
We understand that the EBA Register will be accessible to the public and, although it is essential that customers can check who is listed, the Register will also be open to fraudsters to see the information about genuine TPPs. Since fraudsters could use the information to impersonate an authorised/registered firm and offer fake payment initiation and account information services, we recommend that the EBA considers ways to mitigate this risk.
Possible use of the Legal Entity Identifier (LEI)
UK Finance supports the LEI being a requirement under the RTS/ITS since harmonised identification, based on open standards principles, will be crucial to the success of PSD2. LEI is an open, trusted and globally-recognised identifier. The Global Legal Entity Identifier was created as an ISO standard post the financial crash of 2008. Endorsed by the G20, and the system that supports it, the standard ensures greater transparency on who parties are engaging with in financial transactions to better understand exposure and risk.
The reuse of internationally recognised identifiers such as LEI could be beneficial to the ease of use and growth of the ecosystem. The use of LEI in the Register will help ASPSPs, PISPs and AISPs to find a reliable and verifiable record of a legal entity, this would of course form part of a broader solution on secure communication, authentication and authorisation.
The LEI will help provide a reliable means for two parties to identify each other through a trusted means. The LEI is already cited in legislation across the EU and the globe, including EMIR, CRR, AIFMD and others. This means that many PSPs that will be providing payment services under PSD2 are likely to already have an LEI. It would be beneficial for this to be extended and that LEI should be incorporated as a requirement for those on the EBA and NCA Registers. This will lead to a more robust environment for identifying parties.
Comment regarding Annex 1, Table 1 (Format of the Information on payment institutions), Field 3.1 “Country”
We note that Table 1 field 3.1 indicates that the format is the Member State as shown “by the ISO country codes”. One of the codes listed is “UK” but there is no such ISO country code and we believe that it should instead refer to “GB”.
Therefore, we strongly recommend that the EBA Register should include enquiry contact details of a monitored phone and email address – to support communication and dispute resolution. These fields, which are not unusual, should be standardised (phone format and email format) but will be even more important given that institutions will be in different jurisdictions and the Register(s) may be the only source of contact information. The UK’s Open Banking Directory goes further than this by including key business and technical contacts. Such an approach, if adopted at European level, would be a useful addition to support the new environment, aiding communication between the various parties and leading to a more positive outcome for payment service users.
Question 1: Do you agree with the option the EBA has chosen regarding the transmission of information by NCAs to the EBA? If not, please provide your reasoning
1 INTRODUCTION TO UK FINANCEWe welcome the opportunity to comment on the EBA’s consultation on draft Regulatory Technical Standards setting technical requirements on development, operation and maintenance of the electronic central register and on access to the information contained therein, under Article 15(4) of Directive (EU) 2015/2366 (PSD2) and draft Implementing Technical Standards on the details and structure of the information entered by competent authorities in their public registers and notified to the EBA under Article 15(5) of Directive (EU) 2015/2366 (PSD2).
UK Finance is a trade association representing nearly 300 of the leading firms providing finance, banking, markets and payments-related services in or from the UK. UK Finance has been created by combining the activities of the Asset Based Finance Association, the British Bankers’ Association, the Council of Mortgage Lenders, Financial Fraud Action UK, Payments UK and the UK Cards Association.
Our members are large and small, national and regional, domestic and international, corporate and mutual, retail and wholesale, physical and virtual, banks and non-banks. Our members' customers are individuals, corporates, charities, clubs, associations and government bodies, based in the UK and overseas, served domestically and cross-border. These customers access a wide range of financial and advisory products and services, essential to their day-to-day activities, from our members. The interests of our members’ customers are at the heart of our work.
OUR RESPONSE
The important and pivotal role the national and EBA registers play in supporting the new payment environment
UK Finance strongly supports the EBA’s conclusion that the technical requirements related to the development, operation and maintenance of the EBA Register should contain high level technical requirements related to: (i) the insertion of information in the register, including the automated transmission of information between the national competent authorities (NCAs) and the EBA, and the access of the different users to the register; (ii) the safety, security and integrity of the information contained in the register; (iii) the recording of the information; and (iv) the search of information in the register.
However, we think a vital component is missing from the proposals, which do not appear to address the fact that PSD2 is an important step towards a ‘Digital Single Market’ in Europe, which also represents a significant, European-wide shift in terms of the accessibility of customer data to third parties. The registers that the NCAs and the EBA are required to deliver are essential elements of the operating and risk management model for checking the authorisation and registration status of Payment Initiation Service Providers (PISPs), Account Information Service Providers (AISPs) and Account Servicing Payment Service Providers (ASPSPs), both from a customer protection and from a liability model perspective, bearing in mind that contractual agreements between the parties cannot be mandated. Accordingly, in our view, the national and European authorities have a major role to play in ensuring that their own services are available in time with functionality enabled that can support and promote a reliable, 24x7x365, automated and highly interoperable environment.
Fundamentally, the EBA Register needs to support a highly automated, sophisticated and largely machine-driven communication layer between competent authorities and ASPSPs, PISPs and AISPs. This is an essential building block for a thriving FinTech sector across the European Union and is a key enabler for the success of PSD2.
The need for prompt action by the national authorities and the EBA to ensure that the information is kept up-to-date
We believe that the EBA’s current proposed approach creates issues with potential time lags between revocation of a third party’s authorisation/registration status or permission(s) and the availability of data checks to be conducted by an ASPSP and offers the potential for human error. This also represents a risk to both the ASPSP and, ultimately, the end customer and does not provide the necessary consumer protection in line with the spirit of PSD2. To support the evolution of the payments landscape, which brings third party provider (TPP) services into scope of the Directive and is driven by the development of the FinTech market and the growth in internet and mobile payments, our recommendation is that the EBA should provide a mechanism for ASPSPs to be able to validate TPP permissions electronically and in near real-time. Alternatively, if such a system cannot be delivered in the short term, there should at least be a process for event-based messages to be issued when trigger events occur (trigger events being additions, changes, or revocations of Authorisation/Registration or permissions).
We see it as imperative that the NCAs have the capability to revoke or suspend authorisation/registration immediately and to update the Register in real-time when they have received evidence of, for example, fraud by a third party or a similar serious issue. Fraud and cyber-attacks take place at lightning-speed, moving from institution to institution in seconds if not in parallel. The risk of customer distress and the potential implications for financial stability in the event of sophisticated large-scale attacks, necessitates a very robust and rapid approach.
Promotion of the highest common denominator, automation and efficient processes
PSD2 is a maximum harmonisation directive but the consultation paper appears to be supporting a fragmented environment at the NCA level. We would therefore like the EBA to recommend that all NCAs use the automated process as our preference remains that, as far as possible, updates are made not just ’without delay’ but ‘immediately’. While we appreciate that the EBA may not be able to mandate this within the scope of PSD2, we believe the EBA should at least strongly encourage all NCAs that have many register entries (the parameters of which should be defined and the position reviewed on a regular basis) to use the automated process and to report on their performance to promote timely updates (e.g. twice a day) and the adoption of the automated channel. The Register will be supporting a very automated and real-time environment, therefore the Register itself should be similarly automated and updated in as near to real-time as possible. Importantly, we feel the EBA should encourage the highest common denominator, as the harmonised standard across the EU, and not the lowest.
We support the view that NCAs favouring an automated approach for transmission should retain manual insertion and modification as a fall-back option. This is good practice from a contingency planning perspective. However, we strongly feel that manual insertion should not be used as the primary means of updating the EBA Register. This is because we would see the EBA’s Register being used as the main source of information for many firms to check the authorisation status of third party firms when they seek to access a payment service user’s account. There are potentially serious implications for fraud and financial stability and the Register’s importance in preventing this should be reflected in its performance and usability.
Transmission of data from the NCAs to the EBA: we question the selection of option 1
We would welcome the EBA reconsidering the selection of Option 1 in relation to the transmission of data to the EBA from NCAs. We feel that from a good principles perspective, reloading all data in every instance where there is an addition or modification is not the most efficient approach as it would be cumbersome in the extreme and would create an unnecessary time lag to ensuring up-to-date information and the availability of the EBA Register.
Furthermore, one day for data refreshes from the NCA to the EBA seems too slow, especially in a scenario where a bad actor may have been revoked from the underlying NCA Register. For example, revocation may have taken place on a Friday but this may not have been reflected in the EBA Register until the Monday while, in the meantime, payment service users may still be using the services of the now unauthorised firm. Considering the number of payment transactions and/or data requests that could occur within a day across the ecosystem, we would urge the EBA to further assess Option 2 specifically in terms of the lead time it would take to update the Register. We firmly believe that there is a need for real-time or near real-time updates given the crucial role the Register will play in determining the authorisation status of providers of PIS and AIS services.
If option 1 is to remain the chosen option, we would urge the EBA to investigate alternative technical solutions which shorten the proposed one-day lead time to update the Register. Ultimately, the most important aspect is that the Register can be used as a single source of reliable and accurate information. If service levels are low, or if updates take too long, then the value of the EBA Register is diminished since ASPSPs, PISPs and AISPs will not be able to rely fully on the information. As mentioned, we would strongly encourage the EBA to investigate technical solutions which are as near to real-time as possible. The EBA will need to be clear regarding how long an NCA has - from the point of changing a status of an entrant - to update the EBA Register and how long it will take for the EBA Register to reflect any changes. This will allow firms to take risk-based decisions on whether to use the EBA Register or whether they would need to revert to NCA Registers.
We would also encourage the EBA to put in place appropriate controls to ensure that the Register is only updated by authorised personnel and that information transmitted between NCAs and the EBA is done so securely. This is to minimise the risk of unauthorised modification, defacement and denial of service attacks.
Additionally, it would be helpful if the EBA could clarify how the reloading of data will impact the availability of the Register. Would the out-of-date data be available until the new data is refreshed or would the Register be unavailable until this data refresh is complete? Will there be a change log of some kind to highlight what changes have been made at every refresh?
The EBA should consider the fact that ASPSPs will also need to verify whether a PISP or AISP is passported in from another Member State so the Home state should therefore also be stated.
Potential lessons to be learned from related industry/market developments
There are several industry developments, which the EBA could usefully consider as a way of gaining insight into market needs, best practices and possible technical solutions as well as giving thought to potential synergies. For example, PRETA (https://www.preta.eu/) has launched a project to deliver a pan-European directory to provide relevant information about ASPSPs and TPPs.
In the UK, the Open Banking Implementation Entity (ttps://www.openbanking.org.uk/) is developing an Open Banking Directory to provide an automated mechanism (using APIs) for on-boarding, registering and validating TPPs in real-time while also considering security and other key non-functional requirements (e.g. performance and scalability).
As mentioned elsewhere in this response, we see several possible use cases for the EBA Register, which could include:
• providing a real-time view of TPPs who are authorised and registered, and credit institutions providing PIS and AIS;
• identifying permissions (or where such permission is withdrawn) and passporting;
• supporting the management of an API ecosystem and certification in accordance with eIDAS.
Question 2: Do you agree with the proposed criteria and functionalities related to the search of information in the EBA Register? If not, please provide your reasoning.
The ability to download the full EBA RegisterUK Finance supports the EBA’s views that the EBA Register should fulfil objectives related to PSD2 around the role of the Register for increasing transparency of the operation of non-bank PSPs and facilitating cooperation between competent authorities.
We had assumed that the full EBA Register could at least be downloaded manually but we are not certain that even this is the case. The ‘download’ references within the EBA Register refer to downloading the search results rather than the full register. The references are:
• Article 19(5) indicates that “The user of the register shall be able to download the search results under paragraph (2) and the information displayed for each natural or legal person under paragraph (3) and (4) in a separate file”;
• Article 7(3) indicates that “The access of public users to the electronic central register of the EBA shall allow them only to read, search and download the information contained in the register”
At the public hearing on 4 September, the EBA appeared to indicate that the current draft proposal was that only the search results could be downloaded rather than the Register in its entirety. We would strongly recommend that the EBA, as a minimum, makes it possible to download the full register and that it includes functionality to provide the ability to automate that download.
The importance of automation and machine readability
As we mentioned in our answer to question one, the EBA Register is a key enabler for the success of PSD2. We believe that it is of the upmost importance to ensure efficiency and Straight-Through-Processing, that the EBA Register is fully machine readable.
We note from paragraphs 21 and 22 of the consultation paper that the EBA had considered making the EBA Register “machine readable” to enable automatic extraction of information. We understand, from what was said at the EBA public hearing, that the possibility of creating an interface that would allow external applications to search the Register automatically was discounted on the basis that it would be too costly and would impact the IT project implementation timelines by 3 to 6 months.
We would strongly urge the EBA to reconsider the ability to extract information automatically from the EBA Register i.e. to ensure that it is machine readable. The EBA Register is likely to be used as the main source of information for many firms to check the authorisation status of third party provider firms. As such, the ability to efficiently and effectively interrogate the register in a manner that is as near real-time as possible is essential to ensure the integrity of the ecosystem and to protect all actors within it. It is also very important from an investment perspective as many ASPSPs will be looking to create automated systems and processes to check the EBA Register. Otherwise ASPSPs may have to employ staff and develop processes to interrogate the EBA Register and NCA Registers on a manual basis.
The costs and risks of ASPSPs having to rely on manual processes
While it is difficult to quantify the costs arising from ASPSPs needing to rely on manual processes, since it would depend upon bespoke approaches adopted by individual PSPs, it would seem reasonable to assume the sum would most likely exceed the cost that development of a central automated EBA solution would entail.
Searching, retrieving and validating information on a manual basis will be time consuming, affecting service quality for both TPPs and customers, and will not easily be scalable to accommodate growing volumes of PIS and AIS requests. Operational risks will be greater due to the risk of human error and problems in identifying potential fraud.
We would therefore welcome further comment on the EBA’s statement that introduction of “machine readable” functionality would give “marginal added value” in relation to the cost incurred by the EBA. We do not agree that this is the most appropriate lens through which to make an assessment. We ask that the EBA (and NCAs) take a much broader approach to the cost-benefit analysis by considering the implications of this decision on the costs and benefits (or detriments) to the wider ecosystem because of choosing not to make such a system machine readable.
In addition, NCAs would have until the RTS deadline to implement the machine-to-machine accessibility – which might make implementing the changes somewhat easier to accept and would also recognise the timeline by when the full ecosystem would need to work in an STP-like manner.
Alternative approaches for the EBA to consider
In case it proves impossible for the EBA to take on board industry concerns and the associated cost this would have for ASPSPs, AISPs and PISPs, we would advocate a function that would enable an automated download of the full list. We think that this is a middle ground between making the EBA Register “machine readable” and having to manually download the full register. Thus, the full EBA Register would be downloadable via a “machine” (API) request. This would not be the same as making the EBA Register searchable via “machine readable” API requests. However, it would allow ASPSPs to create and invoke daily scheduled requests to download automatically the full EBA Register via an API and/or each individual home member register if there has been a change. ASPSPs would create a ‘local’ copy of the EBA Register to verify and validate that an AISP or PISP is registered and authorised for the services being performed on behalf of the customer. The ability to download the EBA Register automatically would also remove new ongoing cost to the ASPSPs by eliminating the need for a member of the staff to perform a manual download each day. It would also reduce the risk of manual errors that could occur.
eIDAS
Finally, paragraph 23 of the consultation paper refers to Article 29(2) (now Art. 34(2)) of the RTS on strong customer authentication and common and secure communication relates to Certificates. We have taken this article to refer to eIDAS, and the use of qualified trust service providers to identify and validate the third party. There is no reference or direction to performing the PISP/AISP identification when utilising a dedicated interface (i.e. API), which is likely to be the standard approach for ASPSPs.
Question 3: Do you agree with the proposed non-functional requirements related to the operation of the EBA Register? If not, please provide your reasoning.
The current non-functional requirements that the EBA has set out are currently very high level and we would welcome some further detail. We would also like to see the key non-functional requirements for the register made available 24x7x365 and updated in real-time, as per our previous comments. Given the central and vital role that we see the EBA Register playing as part of the practical application of the PSD2 provisions, the idea that a central register could be out-of-date by a day, and only operational during working hours, makes the Register itself largely redundant.We think that the EBA and the NCAs should have a longer-term approach to considering capacity, capability and performance. The EBA should consider reviewing non-functional requirements on a regular basis e.g. yearly or quarterly. This includes using at the very least bank grade security for the Register and the EBA should also consider the risk of denial of service attacks and the appeal to fraudsters of changing/creating PISP/AISP details.
As a further point, if the EBA Register or an NCA Register experiences an outage – should firms stop providing data/making payments or should they carry on even though they are at risk?
Question 4: Do you agree with the way how the EBA proposes to fulfil the mandate in terms of the natural and legal persons that will need to be included in the future EBA Register? If not, please provide your reasoning.
Based on paragraphs 34 and 35, it appears that existing credit institutions who decide to extend their current services and offer AIS and PIS services will not be included in the EBA Register. This will essentially mean that ASPSPs will have to check more than one register to determine if the request is from a PSP permitted to offer AIS or PIS. This would therefore mean additional overhead costs for the entire market.We support development of a comprehensive single listing of all PSPs offering PISP or AISP services and would encourage the EBA also to incorporate credit institutions offering PIS and AIS services into the EBA Register. The EBA should at least make it possible, on a voluntary basis, for credit institutions offering AIS and PIS to be listed on the register.
We are also concerned that payment service users will not appreciate that there are two EBA Registers (the other being the Credit Institution Register set up in relation to the Capital Requirements Directive). The risk is that the payment service user may search for a credit institution in the proposed PSD2 EBA Register but will be unable to find the firm and may therefore conclude that the credit institution is not authorised to provide PIS and AIS. While we appreciate that the EBA may feel that it does not have a mandate under PSD2 to include credit institutions, it would be helpful if some thought could be given as to the best way of informing the public that two Registers exist.
We understand that the EBA Register will be accessible to the public and, although it is essential that customers can check who is listed, the Register will also be open to fraudsters to see the information about genuine TPPs. Since fraudsters could use the information to impersonate an authorised/registered firm and offer fake payment initiation and account information services, we recommend that the EBA considers ways to mitigate this risk.
Question 5: Do you agree with the option the EBA has chosen regarding the detail of information for the natural and legal persons that will be contained in the future EBA Register? If not, please provide your reasoning.
We support the EBA’s approach to guarantee minimum basic, mandatory information across the EU and provider types. It is important that there is consistency and transparency but the NCAs and the EBA need to consider what information payment service users and firms need to support the new payment landscape. The approach should not be driven by the lowest common denominator but rather all NCAs should be strongly encouraged to ensure that the information held in the national public registers (and available for submission and inclusion in the EBA Register) is sufficient, comprehensive and useful.Possible use of the Legal Entity Identifier (LEI)
UK Finance supports the LEI being a requirement under the RTS/ITS since harmonised identification, based on open standards principles, will be crucial to the success of PSD2. LEI is an open, trusted and globally-recognised identifier. The Global Legal Entity Identifier was created as an ISO standard post the financial crash of 2008. Endorsed by the G20, and the system that supports it, the standard ensures greater transparency on who parties are engaging with in financial transactions to better understand exposure and risk.
The reuse of internationally recognised identifiers such as LEI could be beneficial to the ease of use and growth of the ecosystem. The use of LEI in the Register will help ASPSPs, PISPs and AISPs to find a reliable and verifiable record of a legal entity, this would of course form part of a broader solution on secure communication, authentication and authorisation.
The LEI will help provide a reliable means for two parties to identify each other through a trusted means. The LEI is already cited in legislation across the EU and the globe, including EMIR, CRR, AIFMD and others. This means that many PSPs that will be providing payment services under PSD2 are likely to already have an LEI. It would be beneficial for this to be extended and that LEI should be incorporated as a requirement for those on the EBA and NCA Registers. This will lead to a more robust environment for identifying parties.
Comment regarding Annex 1, Table 1 (Format of the Information on payment institutions), Field 3.1 “Country”
We note that Table 1 field 3.1 indicates that the format is the Member State as shown “by the ISO country codes”. One of the codes listed is “UK” but there is no such ISO country code and we believe that it should instead refer to “GB”.
Question 6: Do you agree with the EBA that the contact details, dates of authorisation/registration, and the services provided in the Host Member States, should not be included in the EBA register? If not, please provide your reasoning, which should also include the benefits for payment service users and other interested parties of having this information in the EBA Register.
Given that PSD2 allows previously unknown PSPs to access customers’ accounts without requiring a prior agreed contract with the relevant ASPSP, it seems inevitable that operational problems and disputes will arise from time to time. Without access to contact information, resolving any issues is likely to take longer or could lead to escalation unnecessarily, resulting in a poor customer experience.Therefore, we strongly recommend that the EBA Register should include enquiry contact details of a monitored phone and email address – to support communication and dispute resolution. These fields, which are not unusual, should be standardised (phone format and email format) but will be even more important given that institutions will be in different jurisdictions and the Register(s) may be the only source of contact information. The UK’s Open Banking Directory goes further than this by including key business and technical contacts. Such an approach, if adopted at European level, would be a useful addition to support the new environment, aiding communication between the various parties and leading to a more positive outcome for payment service users.