Response to consultation on the Technical Standards on the EBA Register under PSD2
Go back
PSD2 requires ASPSPs to open the infrastructure to third party providers (TPPs) and to ensure that only authorised TPPs (banks included) access customer’s payment accounts, ASPSPs should be able to check promptly the information about the TPPs from a reliable, legally-binding, real-time updated and consolidated register. PSD2 also requires TPPs to obtain a qualified certificate for electronic seals from a Qualified Trust Service Provider (QTSP) dully authorized.
The creation of the EBA register is a one-time opportunity for the European-Union to introduce consistency between the various registers at National level. The European Banking Authority should encourage National Competent Authorities (NCAs) to work together to bring barriers down and ensure that PSPs are supported in their efforts to deliver swift and reliable services. As it stands, the current discrepancies on the processes (manual/automated, machine readable or not, accuracy of data checked rapidly or not, update or corrections of files, insertion in the register of credit institutions active on the PIS/AIS market, dispute resolution…) reintroduce fragmentation by forcing PSPs to only rely on National Registers. Without a true effort to harmonize the elements of the registers between Member States, the EBA register may become irrelevant.
For both purposes a reliable, legally-binding, real-time updated and consolidated register is required to ensure all relevant parties are able to verify information about the TPP. The EBA registry should be the only register to fulfil all these needs.
If the current proposal, excluding banks and with limited functionalities remains as it is, the register will not be of any help in solving the operational need that ASPSPs face to identify TPPs when accessing payment service users’ accounts.
Consequently, ASPSPs would always have to refer to other sources of information, i.e. national registers, to obtain the most up to date information. This diminishes the utility of the EBA central register, effectively making of it an untrusted and useless source of information for the purpose of verification of TPPs accessing payment accounts and raising the question as to what purpose the EBA Register is there to perform.
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 the reasoning.
The market needs to have real-time solutions that will allow PSPs to be informed real-time of the withdrawal of the authorization or licensing of TPPs in order to maintain the overall trust in the payments’ ecosystem. A registration/authorization withdrawn on a Friday will not be entered in the register during the week-end. We fully understand that current constraints may not make this possible in the short term. A truly functioning pan-European register should remain a medium term goal by which NCAs would work together to align their processes and registers, preventing PSPs from having to rely on 28 different registers instead of one.
Short term, provisions setting a clear maximum timeframe for NCAs to update the central EBA register are indeed missing in the document. Additionally, there is currently a risk of mismatches in the information contained in the various databases of the EBA and NCA. This will create uncertainties and misunderstandings about the moment an AISP, PISP or PSP issuing card-based payment instruments (as IPs) can start operating or in situations when their authorization/registration is totally or partially revoked (we indeed assume that PSPs issuing card based payment instruments will not be qualified any different from any other payment institution authorised to issue payment instruments. We would welcome this clarification from EBA in the final version of the RTS/ITS).
The need for a real-time update procedure is of utmost importance when addressing fraudulent TPPs and avoiding damages to Payment Service Users and ASPSPs as well as promoting the overall trust in payment services.
If the system does not have a process for the instant transfer for information between the NCA registers and EBA register, the inclusion of an additional piece of data in the register should be considered in order to minimize the impact of delays in information propagation and the potential negative consequences for payment service users. The register should include the commercial name of the Company (i.e. i.e. the name under which the Company advertises its services to its clients, the date of entry into force of authorisation/registration for AISP, PISP. This additional data would allow NCA to notify scheduled modifications within the standard automated communication procedure.
Furthermore, the EBA and NCAs should establish and follow a communication procedure like the one established in Article 6 of DIRECTIVE 98/26/EC on settlement finality in payment and securities settlement systems, i.e. the decision regarding changes to an authorisation shall be notified to European and National Competent Authorities and forwarded without delay to any interested party, specially to Account Servicing Payment Service Providers. This is critical in situations where a TPP authorization is partially or completely cancelled.
Additionally, clarifications are needed to understand how the re-load of the information will impact the availability of the register.
According to PSD2, account information service providers, payment initiation service providers and payment service providers issuing card-based payment instruments have to identify themselves towards the account servicing payment service provider (generally the bank). Banks have to check not only the identity of other PSPs, but also that:
• The PSP is legally registered and authorized to provide the type of payment services for which it is accessing the bank, and
• The authorization to provide payment services has not been suspended or revoked.
Regarding the identification of PSPs, Art. 29 of the proposed EBA Draft RTS on strong customer authentication and secure communication mandates the use of qualified certificates for electronic seals or for website authentication compliant with the e-IDAs Regulation. These types of certificates will include two additional specific attributes for PSD2 purposes. EBA should make sure that these certificates with additional attributes are standardized as soon as possible to ensure that the Directive can be implemented timely by Payment Services Providers.
In order to comply with the requirements established in the RTS on SCA and CSC, an ASPSP will have to check with the Qualified Trust Service Provider (QTSP) that the certificate that the TPP holds is valid and also if the TPP is (still) authorized to perform the service that it is requesting.
When a PSP is accessing an ASPSP’s API to request access to provide a payment service, the key point is that those checks mentioned above (identity, authorization/register and validity of authorization/register) have to be performed online. According to PSD2, ASPSPs cannot allow any PSP to access client’s account data unless those checks have been carried out and the results are positive.
The EBA proposal will set up a central register that may be useful for informational purposes, but it will be totally useless for the operational requirements of PSPs. For this reason, the EBA is strongly suggested to reconsider its approach which would undoubtedly comply with PSD2 mandate in the broadest terms, but would not solve the payments market need. Instead, the EBA should evaluate the possibility of setting up a pan-European central register that provides not only a web service query functionality, but also an interface with an automated, online machine-readable query functionality available 24x7x365. It should include not only “non-bank” PSPs information, but also data of credit institutions that provide AIS or PIS services. Although PSD2 does not mandate such a central, automated register, the EBA would be missing the chance to deliver a key element for the development of payment services in a secure manner which is the ultimate goal of the directive.
Without such a central, automated register, PSPs will be obliged to refer to other sources of information and ultimately to the national register of the PSP requesting access in order to perform the necessary checks. This implies having to connect potentially with 28 different national registers. This latter alternative poses serious risks to the implementation of the PSD2 and higher costs for the market as a whole due to:
• PSPs national registers actually containing different pieces of data in different formats and languages. Fragmentation will oblige all PSPs to carry out technological projects to adapt to each register and gain expertise on how each of them works.
• Access to each national register would be done according to national requirements, which may mandate their own authentication methods. In that case PSPs may have to obtain identification credentials that may not be accepted in other Member States.
• While some national registers may provide an automated, online query functionality, others do not.
• There is no higher authority over all national registers empowered to design, plan and implement in a coordinated fashion the adaptation of the registers to PSD2 operational requirements. There is no guarantee that all national registers will provide an automated, online query functionality by the time the EBA RTS on strong customer authentication become applicable.
By contrast, a pan-European central register of PSPs would foster harmonization of the pieces of data on the authorisation/registration of PSPs and of their branches and/or agents in other Host Member States. It should provide an automated and online machine access, query functionality that would enable all types of PSPs to check securely in real time the information and status of other PSPs. The central register would be subject to a design and implementation project coordinated at European level, with certainty on the final implementation date. In this manner, the central register would be a valuable service and would ease the compliance with the EBA RTS on SCA and CSC as all the information to be checked would be accessible through just 2 interfaces - the EBA Register’s one and that offered by the QTSP - or just one if the QTSP could embed the checking of the EBA Register in its own interface, a possibility that would be facilitated by the existence of “machine readable” access to the EBA Register. The absence of machine readable solution will require PSPs to have staff to support the operational process, which will be very time consuming and may lead to substantial risks associated with manual tasks (i.e. human error).
Current market initiatives are working toward the creation of directories to cross-check registration and authorisation status. A direct link between these initiatives and the EBA register would allow for a quicker cross-check of the register.
If the EBA proposal under consultation is retained:
• Public users should be, at least, entitled to rely on a machine engine for the search and have the ability to download data automatically (e.g. one URL to download & export). This would allow ASPSPs to build a mirror database of the register. In this way ASPSPs could check the requests of the PSPs against their mirror database. A mentioned above, for transparency purposes, the register should contain the brand (and/or commercial name) of the natural or legal person under which it operates on the market. The register should also display the date of registration of the PSP.
• Once the information is validated, the register should publish on its webpage notices of the amendments made in order that public users are informed of any changes in a timely manner.
• For consistency purposes, we would recommend that National ID numbers of natural or legal persons are harmonized in a consistent way across the European Union.
• Appointing at least one member of staff for inserting and modifying information manually may create some issues in case that one staff member is not capable to work. For that reason, we recommend that NCAs appoint at least two staff members.
• Last but not least, articles 5.5 and 5.6 should be aligned and provide that NCAs update the electronic central register in real time.
Equally, market participants should be swiftly informed of any security breach in order for them to take the appropriate measures as quickly as possible.
Article 10 (2) require that EBA and NCAs to apply secure encryption when they implement automated provision of information for filling and updating the central EBA register. We would recommend adding a requirement to encrypt the transmission of data to ensure information is not compromised at any time.
Customers would be better protected - and communication among PSP would be more secure - if all PSPs legally entitled to offer Account Information and Payment Initiation Services appeared in the EBA Central Register. This would guarantee that information on ASPSPs is available to the public in the same way as the rest of the PISPs, AISPs.
PSPs need to access only one central point containing all of the relevant information. Otherwise, the proposed solution will force them to consult national registers and design and implement an automated system to do so. From the user perspective, having two different registers will complicate things quite substantially. Worse, ASPSPs active in the PIS/AIS field will not appear in the register and may, as such, be perceived as unauthorised institutions. Users should therefore be informed of the existence of two different registers, pending the creation of one single register. If the coverage of all registered institutions is defective, the register will not meet the requirements of a level playing field for those service providers who are missing from the register.
Moreover, the EBA can create this unique register without imposing new obligations on NCAs, and instead just leveraging the information included in the EBA register of credit institutions created in accordance to the EBA Board decision EBA BoS 2013 432.
Concerning the search results (Art. 19 of the draft RTS setting technical requirements on development, operation and maintenance of the electronic central register and on access to the information contained therein), the national identifier of the natural or legal person since the name of the person might not be enough for identification purposes considering that they can use various commercial names and different than legal name. Related to this, as per defined in art.2 b) of the RTS “national identifier” – means a unique method of identification of natural and legal persons in the national public registers. This seems to be more a legal identifier and if so, the “national registry code” should be also included. Both elements should be part of the search criteria and displayed as search results (art.19).
● Contact details - to ensure a quality service for payments service users. Contact details of each PSP in the register are essential in case of disputes (as well as in case of technical problems), because PSPs involved in a disputed payment transaction will have to contact each other to solve it and determine who liable (Art. 92 PSD2) is. They are a necessary tool to comply with the directive and they should be available in national registers as well as in the central, pan-European one.
In the end, payment users will be the most affected party in case the management of claims related to new PSD2 services are unnecessarily delayed.
● Date of authorisation/registration - this will prevent uncertainty or misunderstandings regarding the status of a PSP.
● Country where the PSP can offer the service(s) - this will allow a user to retrieve a list with the details of every PSP offering PIS and/or AIS in just one interaction.
● The national identifier of the PSP in the Host Member where the PSP is offering or planning to offer services - this will allow a user to easily identify and cross reference information regarding PSPs.
● The payment services for which the payment institution is authorised or for which the natural or legal person has been registered (Art. 14.2 PSD2) and the payment services that the entity/institution is providing in a Host country.
One other point to be clarified is the registration of branches of payment institutions that are established in a different state from their headquarters and which do not constitute a separate legal entity. Although in paragraph 41 it is stated that these branches would not be included in the register, they seem to be included in article 3 of the draft ITS. Furthermore, they are usually registered in the host national register and have a national identifier in the respective national public register where they operate.
Finally, there remains some ambiguity and confusion in the industry about the differences between the process for authorisation and registration. It should be made clear that all NCAs will be expected to perform comprehensive due diligence on the information provided as part of an application for registration, just as they would for an application for authorisation. Only by doing this will the registration process ensure that appropriate entities are able to be registered, and that as a result the EBA central register is a trusted source of information.
It would have been useful if the EBA consultation paper had included examples on how different types of PSPs would be shown in the central register.
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
We welcome the opportunity to comment on the draft RTS and ITS on the EBA electronic central register and would wish to thank EBA for holding a very useful hearing on 4th September as it allowed us to have a very fruitful initial exchange of views on this critical part of PSD2.PSD2 requires ASPSPs to open the infrastructure to third party providers (TPPs) and to ensure that only authorised TPPs (banks included) access customer’s payment accounts, ASPSPs should be able to check promptly the information about the TPPs from a reliable, legally-binding, real-time updated and consolidated register. PSD2 also requires TPPs to obtain a qualified certificate for electronic seals from a Qualified Trust Service Provider (QTSP) dully authorized.
The creation of the EBA register is a one-time opportunity for the European-Union to introduce consistency between the various registers at National level. The European Banking Authority should encourage National Competent Authorities (NCAs) to work together to bring barriers down and ensure that PSPs are supported in their efforts to deliver swift and reliable services. As it stands, the current discrepancies on the processes (manual/automated, machine readable or not, accuracy of data checked rapidly or not, update or corrections of files, insertion in the register of credit institutions active on the PIS/AIS market, dispute resolution…) reintroduce fragmentation by forcing PSPs to only rely on National Registers. Without a true effort to harmonize the elements of the registers between Member States, the EBA register may become irrelevant.
For both purposes a reliable, legally-binding, real-time updated and consolidated register is required to ensure all relevant parties are able to verify information about the TPP. The EBA registry should be the only register to fulfil all these needs.
If the current proposal, excluding banks and with limited functionalities remains as it is, the register will not be of any help in solving the operational need that ASPSPs face to identify TPPs when accessing payment service users’ accounts.
Consequently, ASPSPs would always have to refer to other sources of information, i.e. national registers, to obtain the most up to date information. This diminishes the utility of the EBA central register, effectively making of it an untrusted and useless source of information for the purpose of verification of TPPs accessing payment accounts and raising the question as to what purpose the EBA Register is there to perform.
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 the reasoning.
The market needs to have real-time solutions that will allow PSPs to be informed real-time of the withdrawal of the authorization or licensing of TPPs in order to maintain the overall trust in the payments’ ecosystem. A registration/authorization withdrawn on a Friday will not be entered in the register during the week-end. We fully understand that current constraints may not make this possible in the short term. A truly functioning pan-European register should remain a medium term goal by which NCAs would work together to align their processes and registers, preventing PSPs from having to rely on 28 different registers instead of one.
Short term, provisions setting a clear maximum timeframe for NCAs to update the central EBA register are indeed missing in the document. Additionally, there is currently a risk of mismatches in the information contained in the various databases of the EBA and NCA. This will create uncertainties and misunderstandings about the moment an AISP, PISP or PSP issuing card-based payment instruments (as IPs) can start operating or in situations when their authorization/registration is totally or partially revoked (we indeed assume that PSPs issuing card based payment instruments will not be qualified any different from any other payment institution authorised to issue payment instruments. We would welcome this clarification from EBA in the final version of the RTS/ITS).
The need for a real-time update procedure is of utmost importance when addressing fraudulent TPPs and avoiding damages to Payment Service Users and ASPSPs as well as promoting the overall trust in payment services.
If the system does not have a process for the instant transfer for information between the NCA registers and EBA register, the inclusion of an additional piece of data in the register should be considered in order to minimize the impact of delays in information propagation and the potential negative consequences for payment service users. The register should include the commercial name of the Company (i.e. i.e. the name under which the Company advertises its services to its clients, the date of entry into force of authorisation/registration for AISP, PISP. This additional data would allow NCA to notify scheduled modifications within the standard automated communication procedure.
Furthermore, the EBA and NCAs should establish and follow a communication procedure like the one established in Article 6 of DIRECTIVE 98/26/EC on settlement finality in payment and securities settlement systems, i.e. the decision regarding changes to an authorisation shall be notified to European and National Competent Authorities and forwarded without delay to any interested party, specially to Account Servicing Payment Service Providers. This is critical in situations where a TPP authorization is partially or completely cancelled.
Additionally, clarifications are needed to understand how the re-load of the information will impact the availability of the register.
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.
From an operational and functional point of view, the proposal falls very short of what PSPs would require from a central, pan-European register.According to PSD2, account information service providers, payment initiation service providers and payment service providers issuing card-based payment instruments have to identify themselves towards the account servicing payment service provider (generally the bank). Banks have to check not only the identity of other PSPs, but also that:
• The PSP is legally registered and authorized to provide the type of payment services for which it is accessing the bank, and
• The authorization to provide payment services has not been suspended or revoked.
Regarding the identification of PSPs, Art. 29 of the proposed EBA Draft RTS on strong customer authentication and secure communication mandates the use of qualified certificates for electronic seals or for website authentication compliant with the e-IDAs Regulation. These types of certificates will include two additional specific attributes for PSD2 purposes. EBA should make sure that these certificates with additional attributes are standardized as soon as possible to ensure that the Directive can be implemented timely by Payment Services Providers.
In order to comply with the requirements established in the RTS on SCA and CSC, an ASPSP will have to check with the Qualified Trust Service Provider (QTSP) that the certificate that the TPP holds is valid and also if the TPP is (still) authorized to perform the service that it is requesting.
When a PSP is accessing an ASPSP’s API to request access to provide a payment service, the key point is that those checks mentioned above (identity, authorization/register and validity of authorization/register) have to be performed online. According to PSD2, ASPSPs cannot allow any PSP to access client’s account data unless those checks have been carried out and the results are positive.
The EBA proposal will set up a central register that may be useful for informational purposes, but it will be totally useless for the operational requirements of PSPs. For this reason, the EBA is strongly suggested to reconsider its approach which would undoubtedly comply with PSD2 mandate in the broadest terms, but would not solve the payments market need. Instead, the EBA should evaluate the possibility of setting up a pan-European central register that provides not only a web service query functionality, but also an interface with an automated, online machine-readable query functionality available 24x7x365. It should include not only “non-bank” PSPs information, but also data of credit institutions that provide AIS or PIS services. Although PSD2 does not mandate such a central, automated register, the EBA would be missing the chance to deliver a key element for the development of payment services in a secure manner which is the ultimate goal of the directive.
Without such a central, automated register, PSPs will be obliged to refer to other sources of information and ultimately to the national register of the PSP requesting access in order to perform the necessary checks. This implies having to connect potentially with 28 different national registers. This latter alternative poses serious risks to the implementation of the PSD2 and higher costs for the market as a whole due to:
• PSPs national registers actually containing different pieces of data in different formats and languages. Fragmentation will oblige all PSPs to carry out technological projects to adapt to each register and gain expertise on how each of them works.
• Access to each national register would be done according to national requirements, which may mandate their own authentication methods. In that case PSPs may have to obtain identification credentials that may not be accepted in other Member States.
• While some national registers may provide an automated, online query functionality, others do not.
• There is no higher authority over all national registers empowered to design, plan and implement in a coordinated fashion the adaptation of the registers to PSD2 operational requirements. There is no guarantee that all national registers will provide an automated, online query functionality by the time the EBA RTS on strong customer authentication become applicable.
By contrast, a pan-European central register of PSPs would foster harmonization of the pieces of data on the authorisation/registration of PSPs and of their branches and/or agents in other Host Member States. It should provide an automated and online machine access, query functionality that would enable all types of PSPs to check securely in real time the information and status of other PSPs. The central register would be subject to a design and implementation project coordinated at European level, with certainty on the final implementation date. In this manner, the central register would be a valuable service and would ease the compliance with the EBA RTS on SCA and CSC as all the information to be checked would be accessible through just 2 interfaces - the EBA Register’s one and that offered by the QTSP - or just one if the QTSP could embed the checking of the EBA Register in its own interface, a possibility that would be facilitated by the existence of “machine readable” access to the EBA Register. The absence of machine readable solution will require PSPs to have staff to support the operational process, which will be very time consuming and may lead to substantial risks associated with manual tasks (i.e. human error).
Current market initiatives are working toward the creation of directories to cross-check registration and authorisation status. A direct link between these initiatives and the EBA register would allow for a quicker cross-check of the register.
If the EBA proposal under consultation is retained:
• Public users should be, at least, entitled to rely on a machine engine for the search and have the ability to download data automatically (e.g. one URL to download & export). This would allow ASPSPs to build a mirror database of the register. In this way ASPSPs could check the requests of the PSPs against their mirror database. A mentioned above, for transparency purposes, the register should contain the brand (and/or commercial name) of the natural or legal person under which it operates on the market. The register should also display the date of registration of the PSP.
• Once the information is validated, the register should publish on its webpage notices of the amendments made in order that public users are informed of any changes in a timely manner.
• For consistency purposes, we would recommend that National ID numbers of natural or legal persons are harmonized in a consistent way across the European Union.
• Appointing at least one member of staff for inserting and modifying information manually may create some issues in case that one staff member is not capable to work. For that reason, we recommend that NCAs appoint at least two staff members.
• Last but not least, articles 5.5 and 5.6 should be aligned and provide that NCAs update the electronic central register in real time.
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.
Whilst we fully agree with the EBA requirements to have an EBA central register that is robust, reliable, efficient, secure and user friendly, we would suggest introducing an availability percentage (99,88% during prime time and 98,5% during non-prime time) to give certainty to the market that the central register meets its objectives.Equally, market participants should be swiftly informed of any security breach in order for them to take the appropriate measures as quickly as possible.
Article 10 (2) require that EBA and NCAs to apply secure encryption when they implement automated provision of information for filling and updating the central EBA register. We would recommend adding a requirement to encrypt the transmission of data to ensure information is not compromised at any time.
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.
Although with this proposal EBA would seem to fulfil its mandate, the EBA central register would only be of value if it contained all of the relevant information on authorized and registered PSPs in the EU that are allowed to provide payment services under PSD2. Not including data of all PSPs in the EBA Register makes difficult to meet the objective of “ensuring high level of consumer protection in the European Union (EU), by providing for easy public access to the list of all natural and legal persons providing payment services” as well as the authentication of credit institutions acting as AISPs or PISPs. To check if a company offering account information (AIS) or payment initiation services (PIS), it means that not only ASPSPs but also payment users and other types of PSP will have to be aware of the existence of other data sources and know which one is applicable to check if a specific provider offering this kind of services is authorised to do so.Customers would be better protected - and communication among PSP would be more secure - if all PSPs legally entitled to offer Account Information and Payment Initiation Services appeared in the EBA Central Register. This would guarantee that information on ASPSPs is available to the public in the same way as the rest of the PISPs, AISPs.
PSPs need to access only one central point containing all of the relevant information. Otherwise, the proposed solution will force them to consult national registers and design and implement an automated system to do so. From the user perspective, having two different registers will complicate things quite substantially. Worse, ASPSPs active in the PIS/AIS field will not appear in the register and may, as such, be perceived as unauthorised institutions. Users should therefore be informed of the existence of two different registers, pending the creation of one single register. If the coverage of all registered institutions is defective, the register will not meet the requirements of a level playing field for those service providers who are missing from the register.
Moreover, the EBA can create this unique register without imposing new obligations on NCAs, and instead just leveraging the information included in the EBA register of credit institutions created in accordance to the EBA Board decision EBA BoS 2013 432.
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.
As previously said, the EBA register should allow for a real-time identification of any PSP offering AIS and PIS. In this sense, providing more detailed information could smooth the functioning of the new services regulated by PSD2.Concerning the search results (Art. 19 of the draft RTS setting technical requirements on development, operation and maintenance of the electronic central register and on access to the information contained therein), the national identifier of the natural or legal person since the name of the person might not be enough for identification purposes considering that they can use various commercial names and different than legal name. Related to this, as per defined in art.2 b) of the RTS “national identifier” – means a unique method of identification of natural and legal persons in the national public registers. This seems to be more a legal identifier and if so, the “national registry code” should be also included. Both elements should be part of the search criteria and displayed as search results (art.19).
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.
No, the EBA register should include all those items since there is value to payment service users and to the wider payment industry in including:● Contact details - to ensure a quality service for payments service users. Contact details of each PSP in the register are essential in case of disputes (as well as in case of technical problems), because PSPs involved in a disputed payment transaction will have to contact each other to solve it and determine who liable (Art. 92 PSD2) is. They are a necessary tool to comply with the directive and they should be available in national registers as well as in the central, pan-European one.
In the end, payment users will be the most affected party in case the management of claims related to new PSD2 services are unnecessarily delayed.
● Date of authorisation/registration - this will prevent uncertainty or misunderstandings regarding the status of a PSP.
● Country where the PSP can offer the service(s) - this will allow a user to retrieve a list with the details of every PSP offering PIS and/or AIS in just one interaction.
● The national identifier of the PSP in the Host Member where the PSP is offering or planning to offer services - this will allow a user to easily identify and cross reference information regarding PSPs.
● The payment services for which the payment institution is authorised or for which the natural or legal person has been registered (Art. 14.2 PSD2) and the payment services that the entity/institution is providing in a Host country.
One other point to be clarified is the registration of branches of payment institutions that are established in a different state from their headquarters and which do not constitute a separate legal entity. Although in paragraph 41 it is stated that these branches would not be included in the register, they seem to be included in article 3 of the draft ITS. Furthermore, they are usually registered in the host national register and have a national identifier in the respective national public register where they operate.
Finally, there remains some ambiguity and confusion in the industry about the differences between the process for authorisation and registration. It should be made clear that all NCAs will be expected to perform comprehensive due diligence on the information provided as part of an application for registration, just as they would for an application for authorisation. Only by doing this will the registration process ensure that appropriate entities are able to be registered, and that as a result the EBA central register is a trusted source of information.
It would have been useful if the EBA consultation paper had included examples on how different types of PSPs would be shown in the central register.