Response to consultation on the Technical Standards on the EBA Register under PSD2
Go back
In Recital 42, the Directive assigns the task of “enhancing transparency of the operation of payment institutions that are authorised by, or registered with, competent authorities of the home Member State, including their agents, and to ensure a high level of consumer protection in the Union” to the electronic central register held by the EBA (for brevity’s sake, EBA register). As a tool for attaining transparency by making information on payment institutions (or on payment service providers other than banks) available to the general public, the EBA register could be a valid system for developing innovative payment services on the domestic market and for boosting user trust level. This is particularly relevant in the case of providers working on a cross-border basis.
In answer to the consultation paper on the draft RTS and ITS and in view of the function envisaged by the PSD2 for the EBA register, ABI wishes to bring the following issues to the attention of the EBA:
• If the register is to become a useful and reliable source of information for all users (especially for payment service users - PSUs), and especially for protection against fraud perpetrated by unauthorised parties, there must be a clear aim to align it to the registers held by the national competent authorities as much as possible. This is why we would recommend:
o closing the time gap as far as possible between the updating of national registers and the EBA register;
o arranging for the standard input method to be automatic, leaving manual input only as a fall-back solution;
• Although it is true that the Directive “does not explicitly require the EBA to develop the “machine-readable functionality” (point 23 of the CP), neither does it prohibit it. Including the option of automated access to the EBA register would pave the way to developing automatic solutions to check the validity of authorisation of Payment Institutions (PIs), Electronic Money Institutions (EMIs) providing payment initiation services (Payment Initiation Service Provider – PISP) and account information services, and parties that only provide information services (Account Information Service Provider – AISP) at the time when access to accounts is requested and this would be enormously useful for all market operators.
• The EBA register should not be confined to having the minimum information (point 37, option b of the CP) contained in the national registers, but should act as a comprehensive information tool enabling users in any Member State and at any given time to find out whether a service provider located in their own Member State, or in another one, is legitimate or not. This is why the technical notes attached to the draft ITS should be supplemented with the registration/authorisation and withdrawal-of-authorisation dates of the PIs, EMIs and AISPs; with the authorisation/withdrawal-of-authorisation dates of their branches and agents; with the payment services provided in the host Member State; and, for the purposes of dealing with disputes, with the contact details of the registered individuals.
• In order to equip the EBA register with the highest possible security standards, availability and performance levels, we recommend adding some other “non-functional” items to the set requirements, viz: availability of the register 24/7, scalability in terms of capacity and performance, user notification for any downtime caused by maintenance work, and other ideas as detailed in answer no. 3;
• Albeit not envisaged under the mandate ofArticle 15 of the PSD2, inserting banks that offer payment initiation and account information services (both as PISP and AISP) on the EBA register would facilitate the checks that the Account Servicing Payment Service Provider (ASPSP) has to run since this would do away with the need to consult several different sources of information. Therefore, we would like the EBA register to include banks that provide payment initiation and account information services.
Here follows a list of all the specific answers to the questions asked in the CP.
Q1: If the EBA register is to be accepted as a reliable source of information by the PSUs in particular who wish to check whether a given entity is legitimate or not (if, for example, they want to protect themselves against the risk of fraud), but also by the ASPSPs, it will be necessary to guard against any circumstances which could lead to a lack of alignment with the national registers held by the Competent Authorities. To this end, ABI feels that:
• As regards points 9-13 of the rationale and Article 8 paragraph 1 of the draft RTS which states that it is up to the Competent Authorities to choose how to feed data into the register, the automated approach should be favoured and the web-user interface for manual insertion and modification should be allowed only as a fall-back solution/contingency plan. Automatic extraction and transmission of the contents of national registers to the EBA register attenuates the risk of any discrepancies arising as a result of manual errors caused by insertion/modification repeated on both national registers and the EBA register;
• As for the time lapse between updating the national registers and the EBA register, option 1 (point 13) which envisages real-time data alignment would be preferable. One day (a working day, therefore in the event of bank holidays, a time delay over 24 hours) is an excessive time lag (point 15 of the CP). It should be borne in mind that, if the ASPSPs do not have a safe source of rapidly updated information, when a competent Authority withdraws authorisation for a PISP or AISP, there could be no effect on the system if the unauthorised providers remain active on the sites of merchants or on devices on which the apps are installed. As an alternative to real-time updating, we suggest that the competent Authorities generate the data and send it to the EBA without delay, at least more than once a day and at set times, upon updating the national registers.
• As regards Article 4, paragraph 1, some thought should be given to the importance of providing service continuity and therefore, envisaging two or more individuals (one manager and a stand-in) amongst staff members as “CA users”.
We should also think about showing the last date when the EBA register was updated with the information on the national registers.
It must be noted that certain access-security aspects do not figure amongst the requirements. For instance, user management, from creation to withdrawal/termination (article 4 RTS), the features of the credentials, how long they are valid for, the default values (Article 6 RTS), how the Competent Authorities notify the users, how authentication takes place, and so forth. By the same token, as regards sending the files, any indication of a standard (xml) seems to be in contrast with EBA’s technologically neutral stance in other circumstances. Moreover, it is not clear (articles 10 and 11) how to reduce the risk of information loss caused by accidentally sending a partial file. Even if the Competent Authorities, who must interact directly with the EBA in the management of the register, can make any comments and observations that they wish, we feel that it would be useful to have greater detail on these aspects in the final version of the RTS/ITS.
Alternatively, the EBA could look at solutions involving an automatic download of the information entered on the register by the ASPSP in a .csv-format file and transmission to the ASPSP using the ’“ftp” protocol.
It should also be specified (point 24) whether it will be possible to download the entire register, only sections of it, or the most recent updates.
With reference to the search options available and in view of the information contained in the attached technical notes, we recommend the following additions:
• a key that unambiguously identifies on a European/EBA level the entities which are not banks and that standardises the different encoding formats of the individual Member States. This could be easily done by linking the national code to the relevant authorisation/registration number;
• the registration/authorisation date and withdrawal-of-authorisation date of the PIs, EMIs and providers of information services only (AISPs);
• the registration/authorisation date and withdrawal-of-authorisation date of any branches of the PIs, EMIs and AISPs in the host Member State;
• the payment services provided in the host Member State. Indeed, these might only be some of those for which the provider is authorised/registered in its home Member State (pursuant to Article 28 of the PSD2 in the application to exercise the right of establishment and freedom to provide services, the payment institution declares which payment service or services it will be providing in the host Member State);
• the registration/authorisation date and withdrawal-of-authorisation date of any agents of the PIs, EMIs and AISPs.
Alongside the information to be included in the items outlined in the attachments, the following should be included in the search functionality:
• a search enabling the extraction of the PIs, EMIs, AISPs, their branches and agents authorised/registered or active on a given date or during a given timeframe. The authorisation/registration and withdrawal-of-authorisation dates are especially crucial because, in the event of a dispute, it will be necessary to check whether the party involved (PI, EMI, AISP, branch or agent) was authorised or not to provide payment services (and if so, which ones) on a given date.
• a name search for the branches or agent. In the event of cross-border operations via branches or agents, the user (especially for the PSU) in the host Member State will naturally tend to search for the provider’s name in the EBA register, i.e. the name of the branch or agent, and not the name of the registered/authorised entity in the home Member State. Indeed, the two names may be different (as indicated in the descriptive notes of the information on the attachments).
• a search for payment and electronic-money services provided in the host Member State.
As regards viewing (point 20 of the CP) the information extracted during the search, the authorisation/withdrawal-of-authorisation dates, or the authorisation/registration status so far, should be part of the immediately displayed data without requiring the user to click to obtain further details.
In addition, the following should be put in place:
• formalisation of the Recovery Point Objective (RPO) and Recovery Time Objective (RTO) of the register platform
• availability 24/7
• development of a scalable solution in terms of capacity and performance
• make arrangements to ensure that the site warns users in advance should there be changes to the application supporting the EBA Register
• even though EBA has provided for a disaster-recovery strategy to guarantee service continuity, we recommend putting communication mechanisms in place with the Competent Authorities in case the site/EBA register has to shut down for security reasons.
Otherwise, any operational misgivings about what procedure to follow in order to abide by the regulatory provisions on TPP identification (Article 29 RTS) would linger rather than being dispelled.
Moreover, the draft RTS and ITS do not clarify responsibility in the case of dissimilarities and misalignments between the national registers and the EBA register.
• a key that unambiguously defines on a European/EBA level, the entities which are not banks and that standardises the different encoding formats of the single states. This could be easily done by linking the national code to the relevant authorisation/registration number;
• the contact details and telephone numbers must be present so that entities/individuals can be easily reached and, in the event of customer disputes ensuing from payments initiated by TPPs, the counterparties involved can be got in touch with;
• the registration/authorisation date and withdrawal-of-authorisation date of the PIs, EMIs and AISPs;
• the registration/authorisation date and withdrawal-of-authorisation date of any branches of the PIs, EMIs and AISPs in the host Member State;
• the payment services provided in the host Member State. Indeed, these might only be a select amount of those for which the provider is authorised/registered in its home member state (pursuant to Article 28 of the PSD2 in the application to exercise the right of establishment and freedom to provide services, the payment institution declares which payment service or services it will be providing in the host Member State);
• the registration/authorisation date and withdrawal-of-authorisation date of any agents of the PIs, EMIs and AISPs.
Last but not least, we think that the address lines should be increased to at least 75 characters because 50 characters might not be enough.
• issuers of payment instruments that only have limited use;
• network or electronic-communication service operators for the purchase of digital content and voice-technology services, of tickets or for charity purposes.
Finally, even though not directly related to the consultation, we would like to point out that automated-access methods, information sets, common transmission methods and formats amongst the national registers are all factors which would contribute to resolving many issues outlined in this reply paper. The market operators could automatically access reliable and securely updated information sources. Therefore, we would urge the EBA to define on its own initiative the common requirements for the national registers held by the competent Authorities.
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
The Italian Banking Association (ABI) appreciates this opportunity to make comments and observations on the Consultation paper (CP) containing the draft Regulatory Technical Standards (RTS) and the Implementing Technical Standards – (ITS) as regards the requirements for the electronic central register and the information notified to the EBA by the Competent Authorities under article 15 paragraphs 4 and 5 of the PSD2 published and placed in consultation by the EBA in close collaboration with the European Central Bank and the Eurosystem.In Recital 42, the Directive assigns the task of “enhancing transparency of the operation of payment institutions that are authorised by, or registered with, competent authorities of the home Member State, including their agents, and to ensure a high level of consumer protection in the Union” to the electronic central register held by the EBA (for brevity’s sake, EBA register). As a tool for attaining transparency by making information on payment institutions (or on payment service providers other than banks) available to the general public, the EBA register could be a valid system for developing innovative payment services on the domestic market and for boosting user trust level. This is particularly relevant in the case of providers working on a cross-border basis.
In answer to the consultation paper on the draft RTS and ITS and in view of the function envisaged by the PSD2 for the EBA register, ABI wishes to bring the following issues to the attention of the EBA:
• If the register is to become a useful and reliable source of information for all users (especially for payment service users - PSUs), and especially for protection against fraud perpetrated by unauthorised parties, there must be a clear aim to align it to the registers held by the national competent authorities as much as possible. This is why we would recommend:
o closing the time gap as far as possible between the updating of national registers and the EBA register;
o arranging for the standard input method to be automatic, leaving manual input only as a fall-back solution;
• Although it is true that the Directive “does not explicitly require the EBA to develop the “machine-readable functionality” (point 23 of the CP), neither does it prohibit it. Including the option of automated access to the EBA register would pave the way to developing automatic solutions to check the validity of authorisation of Payment Institutions (PIs), Electronic Money Institutions (EMIs) providing payment initiation services (Payment Initiation Service Provider – PISP) and account information services, and parties that only provide information services (Account Information Service Provider – AISP) at the time when access to accounts is requested and this would be enormously useful for all market operators.
• The EBA register should not be confined to having the minimum information (point 37, option b of the CP) contained in the national registers, but should act as a comprehensive information tool enabling users in any Member State and at any given time to find out whether a service provider located in their own Member State, or in another one, is legitimate or not. This is why the technical notes attached to the draft ITS should be supplemented with the registration/authorisation and withdrawal-of-authorisation dates of the PIs, EMIs and AISPs; with the authorisation/withdrawal-of-authorisation dates of their branches and agents; with the payment services provided in the host Member State; and, for the purposes of dealing with disputes, with the contact details of the registered individuals.
• In order to equip the EBA register with the highest possible security standards, availability and performance levels, we recommend adding some other “non-functional” items to the set requirements, viz: availability of the register 24/7, scalability in terms of capacity and performance, user notification for any downtime caused by maintenance work, and other ideas as detailed in answer no. 3;
• Albeit not envisaged under the mandate ofArticle 15 of the PSD2, inserting banks that offer payment initiation and account information services (both as PISP and AISP) on the EBA register would facilitate the checks that the Account Servicing Payment Service Provider (ASPSP) has to run since this would do away with the need to consult several different sources of information. Therefore, we would like the EBA register to include banks that provide payment initiation and account information services.
Here follows a list of all the specific answers to the questions asked in the CP.
Q1: If the EBA register is to be accepted as a reliable source of information by the PSUs in particular who wish to check whether a given entity is legitimate or not (if, for example, they want to protect themselves against the risk of fraud), but also by the ASPSPs, it will be necessary to guard against any circumstances which could lead to a lack of alignment with the national registers held by the Competent Authorities. To this end, ABI feels that:
• As regards points 9-13 of the rationale and Article 8 paragraph 1 of the draft RTS which states that it is up to the Competent Authorities to choose how to feed data into the register, the automated approach should be favoured and the web-user interface for manual insertion and modification should be allowed only as a fall-back solution/contingency plan. Automatic extraction and transmission of the contents of national registers to the EBA register attenuates the risk of any discrepancies arising as a result of manual errors caused by insertion/modification repeated on both national registers and the EBA register;
• As for the time lapse between updating the national registers and the EBA register, option 1 (point 13) which envisages real-time data alignment would be preferable. One day (a working day, therefore in the event of bank holidays, a time delay over 24 hours) is an excessive time lag (point 15 of the CP). It should be borne in mind that, if the ASPSPs do not have a safe source of rapidly updated information, when a competent Authority withdraws authorisation for a PISP or AISP, there could be no effect on the system if the unauthorised providers remain active on the sites of merchants or on devices on which the apps are installed. As an alternative to real-time updating, we suggest that the competent Authorities generate the data and send it to the EBA without delay, at least more than once a day and at set times, upon updating the national registers.
• As regards Article 4, paragraph 1, some thought should be given to the importance of providing service continuity and therefore, envisaging two or more individuals (one manager and a stand-in) amongst staff members as “CA users”.
We should also think about showing the last date when the EBA register was updated with the information on the national registers.
It must be noted that certain access-security aspects do not figure amongst the requirements. For instance, user management, from creation to withdrawal/termination (article 4 RTS), the features of the credentials, how long they are valid for, the default values (Article 6 RTS), how the Competent Authorities notify the users, how authentication takes place, and so forth. By the same token, as regards sending the files, any indication of a standard (xml) seems to be in contrast with EBA’s technologically neutral stance in other circumstances. Moreover, it is not clear (articles 10 and 11) how to reduce the risk of information loss caused by accidentally sending a partial file. Even if the Competent Authorities, who must interact directly with the EBA in the management of the register, can make any comments and observations that they wish, we feel that it would be useful to have greater detail on these aspects in the final version of the RTS/ITS.
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.
ABI does not agree with EBA's decision not to implement a “machine-readable” functionality. If EBA does not provide automatic access to the register, all the ASPSPs will have to bear the additional costs incurred by setting up a special monitoring system which aligns the registered/authorised parties with their relevant status, or will have to turn to external suppliers for a fee. All operators will be then forced by EBA to introduce and carry out new manual activities (point 24). Although it is true that the Directive does not “explicitly require the EBA to develop the “machine-readable” functionality” (point 23), neither does it prohibit it, and this functionality would be of huge help in launching PI and AI services on the market. Therefore, if the costs involved in developing an interface have prompted the EBA’s decision in this sense, ABI invites it to reassess the actual costs involved which may not be as prohibitive as it first seems; said costs should be balanced against the benefits for the Single payment Market as a whole.Alternatively, the EBA could look at solutions involving an automatic download of the information entered on the register by the ASPSP in a .csv-format file and transmission to the ASPSP using the ’“ftp” protocol.
It should also be specified (point 24) whether it will be possible to download the entire register, only sections of it, or the most recent updates.
With reference to the search options available and in view of the information contained in the attached technical notes, we recommend the following additions:
• a key that unambiguously identifies on a European/EBA level the entities which are not banks and that standardises the different encoding formats of the individual Member States. This could be easily done by linking the national code to the relevant authorisation/registration number;
• the registration/authorisation date and withdrawal-of-authorisation date of the PIs, EMIs and providers of information services only (AISPs);
• the registration/authorisation date and withdrawal-of-authorisation date of any branches of the PIs, EMIs and AISPs in the host Member State;
• the payment services provided in the host Member State. Indeed, these might only be some of those for which the provider is authorised/registered in its home Member State (pursuant to Article 28 of the PSD2 in the application to exercise the right of establishment and freedom to provide services, the payment institution declares which payment service or services it will be providing in the host Member State);
• the registration/authorisation date and withdrawal-of-authorisation date of any agents of the PIs, EMIs and AISPs.
Alongside the information to be included in the items outlined in the attachments, the following should be included in the search functionality:
• a search enabling the extraction of the PIs, EMIs, AISPs, their branches and agents authorised/registered or active on a given date or during a given timeframe. The authorisation/registration and withdrawal-of-authorisation dates are especially crucial because, in the event of a dispute, it will be necessary to check whether the party involved (PI, EMI, AISP, branch or agent) was authorised or not to provide payment services (and if so, which ones) on a given date.
• a name search for the branches or agent. In the event of cross-border operations via branches or agents, the user (especially for the PSU) in the host Member State will naturally tend to search for the provider’s name in the EBA register, i.e. the name of the branch or agent, and not the name of the registered/authorised entity in the home Member State. Indeed, the two names may be different (as indicated in the descriptive notes of the information on the attachments).
• a search for payment and electronic-money services provided in the host Member State.
As regards viewing (point 20 of the CP) the information extracted during the search, the authorisation/withdrawal-of-authorisation dates, or the authorisation/registration status so far, should be part of the immediately displayed data without requiring the user to click to obtain further details.
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.
Given the critical nature of the register and in keeping with the provisions contained in the Guidelines on major incidents, we suggest that the EBA reports the incident and informs the users and competent Authorities of the required recovery time within 4 hours of it having happened.In addition, the following should be put in place:
• formalisation of the Recovery Point Objective (RPO) and Recovery Time Objective (RTO) of the register platform
• availability 24/7
• development of a scalable solution in terms of capacity and performance
• make arrangements to ensure that the site warns users in advance should there be changes to the application supporting the EBA Register
• even though EBA has provided for a disaster-recovery strategy to guarantee service continuity, we recommend putting communication mechanisms in place with the Competent Authorities in case the site/EBA register has to shut down for security reasons.
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.
Albeit not envisaged under the mandate in Article 15 of the PSD2, inserting banks that offer payment initiation and account information services (both as PISP and AISP) on the EBA register would facilitate the checks that the Account Servicing Payment Service Provider (ASPSP) has to run since this would do away with the need to consult several different sources of information. Therefore, we would like the EBA register to include banks that provide PI and AI services.Otherwise, any operational misgivings about what procedure to follow in order to abide by the regulatory provisions on TPP identification (Article 29 RTS) would linger rather than being dispelled.
Moreover, the draft RTS and ITS do not clarify responsibility in the case of dissimilarities and misalignments between the national registers and the EBA register.
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.
The EBA’s decision seems to tie in with their intention to align and standardise the information in the register. Nevertheless, option B would be preferable because it offers more flexibility.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.
The EBA states (point 42 of the CP) that there is much granularity on the public registers regarding relevant information like authorisation/registration dates, branches and services provided in the host Member State. Even though not all the national registers contain given pieces of information, ABI believes that such data should still figure on the EBA register. In the face of burgeoning cross-border operations by the PSPs, one of the aims of the EBA is to ensure high consumer protection (point 39, recital 42 of the PSD2) by disclosing information about providers. Therefore, the EBA register should not just be a simple reflection of the national registers nor should it confine itself to the minimum set of information contained therein, it ought to be a useful tool enabling users from any Member State to settle any doubts at any given time as to the legitimacy of a provider established in another Member State. Therefore, as previously explained in answer 2, we feel that the attached technical notes should be supplemented with the following information:• a key that unambiguously defines on a European/EBA level, the entities which are not banks and that standardises the different encoding formats of the single states. This could be easily done by linking the national code to the relevant authorisation/registration number;
• the contact details and telephone numbers must be present so that entities/individuals can be easily reached and, in the event of customer disputes ensuing from payments initiated by TPPs, the counterparties involved can be got in touch with;
• the registration/authorisation date and withdrawal-of-authorisation date of the PIs, EMIs and AISPs;
• the registration/authorisation date and withdrawal-of-authorisation date of any branches of the PIs, EMIs and AISPs in the host Member State;
• the payment services provided in the host Member State. Indeed, these might only be a select amount of those for which the provider is authorised/registered in its home member state (pursuant to Article 28 of the PSD2 in the application to exercise the right of establishment and freedom to provide services, the payment institution declares which payment service or services it will be providing in the host Member State);
• the registration/authorisation date and withdrawal-of-authorisation date of any agents of the PIs, EMIs and AISPs.
Last but not least, we think that the address lines should be increased to at least 75 characters because 50 characters might not be enough.
Question 7: Do you agree with the extension of the information for the service providers excluded from the scope of the PSD2 that will be entered in the EBA register? If not, please provide your reasoning.
To increase transparency for register users, and especially for the PSUs, we believe that the EBA register should contain information on service providers falling outside the scope of the PSD2 who should notify the Competent Authorities that they have implemented exclusion or abided by the access conditions:• issuers of payment instruments that only have limited use;
• network or electronic-communication service operators for the purchase of digital content and voice-technology services, of tickets or for charity purposes.
Question 8: Do you agree with the scope of the information on agents of payment institutions, exempted payment institutions, account information service providers, electronic money institutions and exempted electronic money institutions to be included in the EBA register? If not, please provide your reasoning.
Please see the observations set forth in answer 6.Finally, even though not directly related to the consultation, we would like to point out that automated-access methods, information sets, common transmission methods and formats amongst the national registers are all factors which would contribute to resolving many issues outlined in this reply paper. The market operators could automatically access reliable and securely updated information sources. Therefore, we would urge the EBA to define on its own initiative the common requirements for the national registers held by the competent Authorities.