Response to consultation on the Technical Standards on the EBA Register under PSD2
Go back
We welcome the opportunity to comment on both the proposed Draft RTS as well as the Draft ITS re. the central EBA register. We appreciate EBA’s efforts to develop these RTS and ITS. PSD2 requires ASPSPs (banks) to open up their payment account infrastructure to third party providers (TPPs), who provide payment initiation services (PIS) and/or account information services (AIS). To ensure that (only) duly licensed or registered TPPs access customer’s payment accounts, ASPSPs should be able to check promptly reliable and up-to-date information about the TPPs. PSD2 further requires TPPs to obtain a qualified certificate for electronic seals from a “trust center” (Qualified Trust Service Providers (QTSPs)), which is authorized to issue such certification. A reliable, legally-binding (e.g. legally prevailing over national registers), real-time updated and consolidated source is required to enable QTSPs to verify information about the TPP. We (still) believe that the central EBA register should provide this functionality. However, we are aware – and regret – that this will probably not be the case. In our view absence of a properly functioning central EBA register does not seem to match with PSD2’s ambitions. Hopefully, market-led initiatives will close the gap.
Q1. 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 can understand EBA’s rationale for preferring a combination of technical solutions, which support both manual insertion of data by NCA staff in the central EBA register via a web user interface, as well as an automated transmission of information. The latter, based on the application-to-application principle, reloads the complete set of information contained in the national public registers into EBA’s central register on a daily basis and using a single batch file. We prefer an automatic entry of the information into the register as default, and manual insertion of data as a backup.
In par. 15 of chapter 4 (p. 6 of its CP) EBA explains: “It would also guarantee that the information is transmitted from the NCAs to the EBA with a relatively short delay (a day after the information in the national registers is amended), which was considered by the EBA to be in line with Article 15(2) of the PSD2 which requires NCAs, “without delay”, to notify the EBA of the information entered in their public registers.” We believe that real-time transmission of data between the NCAs’ registers and central EBA register – instead of the proposed one day lead-time to update the register – is the best solution, e.g. that the central EBA register does not show any information-gaps as compared to the local NCAs’ registers. For example, when a TPP discontinues its license (PIS) or registration (AIS) on Friday, then the EBA register – if not processing and displaying information real-time – will be updated the next Monday (e.g. three days later). This is detrimental to the reliability of the central EBA register, as being a trusted source for information for PSPs, PSUs and other relevant parties. Relying on outdated information can result in serious risks for both customers and PSPs. It creates a risk that the payment transactions processed or payment information exchanged during the weekend might have been initiated by an unauthorized person. In this context, we consider it to be useful if EBA mandates the NCAs to update their local registers at specific times, for example twice a day, with simultaneous automated feed of any changes into the EBA register.
We notice that art. 10(7) of the Draft RTS (p. 21 of the CP) not specifies what happens when “the automatically transmitted information fails to be validated by the application of the electronic central register of the EBA”. We assume that the central EBA register will then show the information which was uploaded during the last successful transmitted batch. And if so, will it then contain a warning that the information as shown in the register, could be outdated? We recommend that EBA provides more clarity on this.
Furthermore, art. 11(5) of the Draft RTS (p. 22 of the CP) prescribes that NCAs “which provide information to the EBA manually shall, [NB: this comma is redundant and should be deleted] receive a response from the application of the electronic central register of the EBA about the outcome of the data validation process in real time”. Art. 11(6) and (7) of the Draft RTS mention that NCAs who provide information automatically receive a response from the central EBA register about the outcome of the data validation process of the whole batch file not later than the beginning of the next business day. We expect that it is technically realistic to provide this response on a (near) real-time basis; e.g. after the batch has been received and successfully – or unsuccessfully – processed by the central EBA register, instead of within one business day as proposed.
Art. 11(7) of the Draft RTS (p. 22 of the CP) states that “The competent authority shall transmit a corrected or updated file with the whole set of information without undue delay”. We wonder what happens if a NCA sends in incorrect batches (or even sends no batches at all) on a more often/ structural basis. The Draft RTS do not seem to provide EBA with any enforcement instruments to - when deemed necessary – ‘encourage’ NCAs to provide (correct) data batches. Maybe the enforcement powers of EBA are regulated in another Directive or Regulation. If so, a reference to that legislation would be welcome. Lastly, we wonder which timeframe(s) EBA considers to be appropriate when it speaks about “without undue delay”?
Finally, we recommend EBA to specify in its Final Draft RTS and ITS what exactly the added value of a central EBA register is as compared to the existing national registers. Maybe a referral to recital (42) of PSD2 can be made, which states: “in order to enhance 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, it is necessary to ensure easy public access to the list of the entities providing payment services. EBA should therefore develop and operate a central register in which it publishes a list of the names of the entities providing payment services. Member States should ensure that the data that they provide is kept up to date. Those measures should also contribute to the enhancement of the cooperation between the competent authorities.”.
Furthermore, EBA does not specify that its central register should have a clear link with QTSPs, re. whether a PSP has a valid license (PIS) or registration (AIS). We recommend EBA to include information in its central register re. qualified certificates for electronic seals as issued by QTSPs. This to minimise fraud risk and to help PSPs (both ASPSPs, PISPs and AISPs) validating each other, especially on a cross-border basis within the EU. We therefore propose EBA to include both certificate issuing dates and validity dates in its central register, as well as the names of the QTSPs, which have issued the certificates.
In our view the absence of the above mentioned functions of the central EBA register is not at par with PSD2’s ambitions.
Current market-driven initiatives (such as PRETA) could perhaps fill the above mentioned gaps, and develop solutions (directory services) for PSPs to verify other PSPs’ identities in light of PSD2’s XS2A. We believe that this also requires a link between these market-driven directories service(s) and the central EBA register; e.g. that market-driven initiatives are able to (automatically) read and export the information – required for the PSD2-directory services they provide – from the central EBA register. This also requires that the central EBA register has machine readable functionalities. As a minimum requirement the central EBA register should provide for a possibility of downloading the data into the CSV-format in order to be relied upon by ASPSPs for their checks on TPPs and vice versa. This allows PSPs to initiate regular scheduled requests to automatically download all EBA register and/or each individual home member register; create local copies of the register to verify and validate the TPP.
In such a context we believe that – when EBA stays with its decision not to it a implement machine readable functionalities – we consider it necessary that the NCAs are to be encouraged to align the format of their national registers. We therefore recommend EBA, when PSD2 and/or the EBA GL’s on the central EBA register are reviewed, to consider issuing minimum standards for national registers of NCAs to ensure that PSPs (incl. ASPSPs) and QTSPs can rely on a harmonized, standardized and automated local registers. These should at a minimum include a possibility to access national registers through automatic ways, signing up for notification of new entries/ updates of the register and machine-readable functions. However, implementing an automated machine readable functionality now, saves PSPs costs, because their staff will not have to do manual downloads each day; it will reduce the risk of manual errors and the time necessary to do the checks.
Furthermore, we recommend EBA to add a search criterion in its central register next to the ones as mentioned in par. 18 (p. 9 of the CP) and in art. 18(1) of the Draft RTS (p. 24 of the CP), namely the “brand (or commercial) name of the natural or legal person under which it provides its payment services to the market”. This because the statutory name of a PSP can be different as compared to the brand or commercial name under which the PSP offers its services in the market. Since the central EBA register is to be used by PSUs (consumers and businesses), and other interested parties– e.g. together being ‘the general public’ as mentioned in par. 25(b)) (p. 11 of the CP) and art 2(c) (p. 19 of the CP) of the Draft RTS, we believe it is important to add the brand or commercial name to the required information to be included in EBA’s central register.
Art. 19(2) of EBA’s draft RTS (p. 25 of the CP) sums-up the information which the central EBA register shows when a natural or legal person meets the search criteria filled in by the user of the register. In light of transparency and completeness, we believe it is useful to add the following information here: “The (host) Member States, next to its own (home) Member State, where the natural or legal person also provides, or intends to provide, its payment and electronic money services”. This information is already captured in the tables with the format of the information under art. 4 – 11 of the Draft ITS, as shown in its Annex I (p. 31 - 48 of the CP). Exempted payment institutions (table 2, p. 34 - 35), exempted EMIs (table 5, p. 41 - 42), agents (table 6, p. 43 - 44) and excluded service providers (table 8, p. 47 - 48) do – as per definition – not provide payment services on a cross-border basis in other (host) member states. Therefore, we agree on EBA’s choice not to capture this information (whether the natural or legal person also provides, or intends to provide, its payment and electronic money services in other (host) Member States) in table 2, 5, 6 and 8. With regard to table 7 (p. 45 – 46 pf EBA’s CP), which is meant for credit institutions “that are entitled under national law to provide payment services”, we would appreciate more clarity in this matter, as we explain in our answer on Q7.
We further recommend EBA that the search-functionalities in its central register will be able to deal with small typos and/or misspelled words (the human error factor). For example: the system ‘notices’ and notifies the user of the register that ‘paymnet’ could mean ‘payment’.
Regarding the “national identification number of the natural or legal person”, as mentioned in par. 18(c) (p. 9) and in art. 2(b) (p. 19) and art. 18(1) (p. 24) of the Draft RTS (and also in art. 2(d) of the Draft ITS on p. 28), we derive from art. 11(8) (p. 22) of the Draft RTS that every NCA uses a different structure for compiling these ID-numbers: “Competent authorities shall notify the EBA about the types of national identifiers and their format which competent authorities use in their national public registers and which the EBA shall use for validation purposes.”. To simplify the search for users of the central EBA register, we advocate that NCAs should structure these unique national ID-numbers in a consistent way across the EEA.
NB: Art. 4(1) (p. 20 of the CP) of the Draft RTS prescribes that each NCA “shall appoint at least one member of the staff who shall be responsible for inserting and modifying information manually via a web user interface in the electronic central register of the EBA.”. We recommend that, to prevent a ‘single point of capability”, that NCAs appoint at least two staff members in this matter. This to mitigate this risk, we suggest EBA to change the words “shall appoint at least one member of the staff who shall be responsible for inserting and modifying information manually via a web user interface in the electronic central register of the EBA.” into “shall set-up at least one staff function, where the responsibility for inserting and modifying information manually via a web user interface in the electronic central register of the EBA is assigned.” (a staff function can be shared between, for example, two staff members).
As an additional risk mitigation feature, we suggest that the users of the central EBA register are offered a possibility to subscribe for receiving real-time alerts in case, for example, a PISP’s license or AISP’s registration has been withdrawn by its NCA. Alternatively, these alerts could be also send out by the individual NCAs.
Art 10 (2) (p. 21 of the CP) of the Draft RTS requires that EBA and NCAs apply secure encryption" when they implement automated provision of information for filling and updating the central EBA register. This to safeguard the integrity of the information processed. We note that encryption as such is primarily intended for safeguarding data-confidentiality, and not for safeguarding data-integrity. However, encryption seems to work quite well here as it is difficult to consciously manipulate an encrypted file. We recommend EBA to clearly describe its roles and responsibilities as well as those of NCAs with regard to assuring authenticity and integrity of data in the import- and update process. For example, will the EBA be able to "prove" that they used the originally sent single batch file to update its central register?
Furthermore, we recommend EBA to specify in its Final Draft RTS and ITS whether a difference in certain data held in a national register may exists for a limited period of time as compared to the central EBA register. In other words, how long may it maximally take for a data alteration in the national register to be imported and displayed in the central EBA register (for example: maximally one working day)? Ideally, this functions on a real-time basis.
Finally, we recommend EBA to add a requirement in its GLs that the non-functional requirements of its central register will be reviewed on a yearly basis, to check whether GL’s are still up-to-date and where improvements are necessary."
In addition, we recommend EBA to design its central register “in such a way that it can be used for the purposes of Article 29 of the RTS on SCA and CSC, so that qualified trust service providers(QTSPs) will be able to identify properly all TPPs, including credit institutions, to whom they are requested to issue qualified certificates for electronic seals, and account servicing payment service providers will be able to check the credentials of these TPPs”, as stated in par. 34 (p. 13) of chapter 4 of EBA’s CP. This to ensure that all relevant PSD2 “XS2A” parties can interact with each other in a secure and effective manner.
NB: We noted that the letter ‘s’ is missing and the word ‘to’ is redundant in the text of art. 11 (3(a)) of the Draft RTS (p. 22 of EBA’s CP): “(…) electronic money institutions, exempted electronic money institution(s), the institutions referred to to (…).”.
We recommend EBA to include information about the qualified certificate for electronic seals, issued by the QTSP, in its central register. This to minimise fraud risk and to help PSPs (ASPSPs, PISPs and AISPs) validating each other, especially on a cross-border basis within the EU. We therefore propose to include certificate issuing dates and validity dates, as well as the names of the QTSPs, which have issued the certificate.
We further believe that the central EBA register should include dates of authorisation/registration, as well as the payment services provided in host member states. This because the central register is to be used by PSUs and other interested parties too. Knowing how long a PSP has been authorised/ registered in its home member state and/ or which payment services it provides in other (host) member states could be quite relevant information for the public. We believe this information provides additional transparency in the market, which will have a positive effect on consumers’ confidence in payment services offered on cross-border basis within the EU/ EEA, and is in line with PSD2’s objectives related to the central EBA register.
As we explained in our answer to Q4, we advocate that information of (credit) institutions referred to in points (4) to (23) of art. 2(5) of Directive 2013/36/EU (Capital Requirements Directive (CRD IV)) is also be included in the central EBA register, at least for those ASPSPs who offer PIS and/or AIS. However, EBA explains in par. 33 to 35 (p. 13 of its CP) that it lacks a legal mandate doing so. Art. 3(i) of the draft ITS (p. 29 of EBA’s CP) states that the central EBA register shall contain information about the following natural and legal persons: “i. the institutions referred to in points (4) to (23) of Article 2(5) of Directive 2013/36/EU, if they are entitled under national law to provide payment services;”. We recommend EBA to provide clarity on this; do NCAs also have to include the information as required by the Draft RTS and ITS, about credit institutions who also provide payment services, or not? Furthermore, we wonder what is exactly meant with “if they are entitled under national law to provide payment services;”.
We further recommend that, next to the name of the agent (as mentioned in par. 4 (a)) (p. 16 of EBA’s CP), the brand (commercial) name under which the service provider provides its payment services to the market should be recorded in EBA’s central register. This information needs to be captured in the tables with the format of the information under art. 4 – 11 of the Draft ITS as shown in its Annex I (p. 31 -48 of EBA’s CP). For our rationale, we refer to our answers to Q2 and Q5 (see above).
We also suggest EBA to clarify the relation between row 6, point 8 (‘Account information services’) of Table 1 (Format of the information on payment institutions) and Table 3 (Format of the information on AISPs) of Annex I of the draft ITS. We assume that when a PSP provides AIS only, e.g. no other payment services as mentioned in the Annex of PSD2, the NCA needs to provide EBA the information in the format as specified in Table 3. And when a PSP (also) provides other payment services (next to AIS) as mentioned in PSD2’s Annex, then the NCA needs to provide EBA the information about that PSP in the format as specified in Table 1 (and not in the format as specified in Table 3 also).
Finally, we reiterate the necessity of a clear link between the QTSP and the central EBA register (whether a PSP has a valid license (PIS) or registration (AIS) as granted by its NCA. We believe that such a link is a prerequisite to help market actors to assure that all relevant parties are authorized to operate in the (new) PSD2-world. The central EBA register should include information about the qualified certificate for electronic seals, issued by the QTSP to minimise fraud risk. We propose to include the certificate issuing date and validity date, as well as the name of the QTSPs, who have issued the certificates.
members. Our members are payment services providers who are active on the Dutch market: banks (credit institutions), payment institutions and electronic money institutions. Our responsibilities lie in the areas of infrastructure, standards and shared product features. We seek to ensure a socially efficient, safe and reliable payment system, with room for innovation.
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
In generalWe welcome the opportunity to comment on both the proposed Draft RTS as well as the Draft ITS re. the central EBA register. We appreciate EBA’s efforts to develop these RTS and ITS. PSD2 requires ASPSPs (banks) to open up their payment account infrastructure to third party providers (TPPs), who provide payment initiation services (PIS) and/or account information services (AIS). To ensure that (only) duly licensed or registered TPPs access customer’s payment accounts, ASPSPs should be able to check promptly reliable and up-to-date information about the TPPs. PSD2 further requires TPPs to obtain a qualified certificate for electronic seals from a “trust center” (Qualified Trust Service Providers (QTSPs)), which is authorized to issue such certification. A reliable, legally-binding (e.g. legally prevailing over national registers), real-time updated and consolidated source is required to enable QTSPs to verify information about the TPP. We (still) believe that the central EBA register should provide this functionality. However, we are aware – and regret – that this will probably not be the case. In our view absence of a properly functioning central EBA register does not seem to match with PSD2’s ambitions. Hopefully, market-led initiatives will close the gap.
Q1. 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 can understand EBA’s rationale for preferring a combination of technical solutions, which support both manual insertion of data by NCA staff in the central EBA register via a web user interface, as well as an automated transmission of information. The latter, based on the application-to-application principle, reloads the complete set of information contained in the national public registers into EBA’s central register on a daily basis and using a single batch file. We prefer an automatic entry of the information into the register as default, and manual insertion of data as a backup.
In par. 15 of chapter 4 (p. 6 of its CP) EBA explains: “It would also guarantee that the information is transmitted from the NCAs to the EBA with a relatively short delay (a day after the information in the national registers is amended), which was considered by the EBA to be in line with Article 15(2) of the PSD2 which requires NCAs, “without delay”, to notify the EBA of the information entered in their public registers.” We believe that real-time transmission of data between the NCAs’ registers and central EBA register – instead of the proposed one day lead-time to update the register – is the best solution, e.g. that the central EBA register does not show any information-gaps as compared to the local NCAs’ registers. For example, when a TPP discontinues its license (PIS) or registration (AIS) on Friday, then the EBA register – if not processing and displaying information real-time – will be updated the next Monday (e.g. three days later). This is detrimental to the reliability of the central EBA register, as being a trusted source for information for PSPs, PSUs and other relevant parties. Relying on outdated information can result in serious risks for both customers and PSPs. It creates a risk that the payment transactions processed or payment information exchanged during the weekend might have been initiated by an unauthorized person. In this context, we consider it to be useful if EBA mandates the NCAs to update their local registers at specific times, for example twice a day, with simultaneous automated feed of any changes into the EBA register.
We notice that art. 10(7) of the Draft RTS (p. 21 of the CP) not specifies what happens when “the automatically transmitted information fails to be validated by the application of the electronic central register of the EBA”. We assume that the central EBA register will then show the information which was uploaded during the last successful transmitted batch. And if so, will it then contain a warning that the information as shown in the register, could be outdated? We recommend that EBA provides more clarity on this.
Furthermore, art. 11(5) of the Draft RTS (p. 22 of the CP) prescribes that NCAs “which provide information to the EBA manually shall, [NB: this comma is redundant and should be deleted] receive a response from the application of the electronic central register of the EBA about the outcome of the data validation process in real time”. Art. 11(6) and (7) of the Draft RTS mention that NCAs who provide information automatically receive a response from the central EBA register about the outcome of the data validation process of the whole batch file not later than the beginning of the next business day. We expect that it is technically realistic to provide this response on a (near) real-time basis; e.g. after the batch has been received and successfully – or unsuccessfully – processed by the central EBA register, instead of within one business day as proposed.
Art. 11(7) of the Draft RTS (p. 22 of the CP) states that “The competent authority shall transmit a corrected or updated file with the whole set of information without undue delay”. We wonder what happens if a NCA sends in incorrect batches (or even sends no batches at all) on a more often/ structural basis. The Draft RTS do not seem to provide EBA with any enforcement instruments to - when deemed necessary – ‘encourage’ NCAs to provide (correct) data batches. Maybe the enforcement powers of EBA are regulated in another Directive or Regulation. If so, a reference to that legislation would be welcome. Lastly, we wonder which timeframe(s) EBA considers to be appropriate when it speaks about “without undue delay”?
Finally, we recommend EBA to specify in its Final Draft RTS and ITS what exactly the added value of a central EBA register is as compared to the existing national registers. Maybe a referral to recital (42) of PSD2 can be made, which states: “in order to enhance 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, it is necessary to ensure easy public access to the list of the entities providing payment services. EBA should therefore develop and operate a central register in which it publishes a list of the names of the entities providing payment services. Member States should ensure that the data that they provide is kept up to date. Those measures should also contribute to the enhancement of the cooperation between the competent authorities.”.
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.
We take notice of EBA’s rationale, as explained in par. 21 to 24 (p. 10 of the CP), not to implement a “machine readable” functionality in its central register for the purpose of identifying PSP’s, as meant in the – almost(?) final - RTS on SCA and CSC. EBA assesses this “machine readable” functionality as being (too) expensive. We recommend EBA to clarify on this in its Final GLs. We believe that a “machine readable” register in the context of the RTS on SCA and CSC is needed to provide for a real-time look up capability by ASPSPs and/or QTSPs to check whether a particular TPP is duly licensed (PIS) or registered (AIS). This requires a highly automated, dynamic and up to date central register. When the central EBA register does not provide for a machine readable functionality, PSPs will incur significant additional costs. This because PSPs will then have to develop and implement individual (incl. manual) solutions and have to rely upon (commercial) third parties fulfilling the role of QTSPs. We wonder whether these additional costs are fully included in EBA’s cost-benefit-analysis made.Furthermore, EBA does not specify that its central register should have a clear link with QTSPs, re. whether a PSP has a valid license (PIS) or registration (AIS). We recommend EBA to include information in its central register re. qualified certificates for electronic seals as issued by QTSPs. This to minimise fraud risk and to help PSPs (both ASPSPs, PISPs and AISPs) validating each other, especially on a cross-border basis within the EU. We therefore propose EBA to include both certificate issuing dates and validity dates in its central register, as well as the names of the QTSPs, which have issued the certificates.
In our view the absence of the above mentioned functions of the central EBA register is not at par with PSD2’s ambitions.
Current market-driven initiatives (such as PRETA) could perhaps fill the above mentioned gaps, and develop solutions (directory services) for PSPs to verify other PSPs’ identities in light of PSD2’s XS2A. We believe that this also requires a link between these market-driven directories service(s) and the central EBA register; e.g. that market-driven initiatives are able to (automatically) read and export the information – required for the PSD2-directory services they provide – from the central EBA register. This also requires that the central EBA register has machine readable functionalities. As a minimum requirement the central EBA register should provide for a possibility of downloading the data into the CSV-format in order to be relied upon by ASPSPs for their checks on TPPs and vice versa. This allows PSPs to initiate regular scheduled requests to automatically download all EBA register and/or each individual home member register; create local copies of the register to verify and validate the TPP.
In such a context we believe that – when EBA stays with its decision not to it a implement machine readable functionalities – we consider it necessary that the NCAs are to be encouraged to align the format of their national registers. We therefore recommend EBA, when PSD2 and/or the EBA GL’s on the central EBA register are reviewed, to consider issuing minimum standards for national registers of NCAs to ensure that PSPs (incl. ASPSPs) and QTSPs can rely on a harmonized, standardized and automated local registers. These should at a minimum include a possibility to access national registers through automatic ways, signing up for notification of new entries/ updates of the register and machine-readable functions. However, implementing an automated machine readable functionality now, saves PSPs costs, because their staff will not have to do manual downloads each day; it will reduce the risk of manual errors and the time necessary to do the checks.
Furthermore, we recommend EBA to add a search criterion in its central register next to the ones as mentioned in par. 18 (p. 9 of the CP) and in art. 18(1) of the Draft RTS (p. 24 of the CP), namely the “brand (or commercial) name of the natural or legal person under which it provides its payment services to the market”. This because the statutory name of a PSP can be different as compared to the brand or commercial name under which the PSP offers its services in the market. Since the central EBA register is to be used by PSUs (consumers and businesses), and other interested parties– e.g. together being ‘the general public’ as mentioned in par. 25(b)) (p. 11 of the CP) and art 2(c) (p. 19 of the CP) of the Draft RTS, we believe it is important to add the brand or commercial name to the required information to be included in EBA’s central register.
Art. 19(2) of EBA’s draft RTS (p. 25 of the CP) sums-up the information which the central EBA register shows when a natural or legal person meets the search criteria filled in by the user of the register. In light of transparency and completeness, we believe it is useful to add the following information here: “The (host) Member States, next to its own (home) Member State, where the natural or legal person also provides, or intends to provide, its payment and electronic money services”. This information is already captured in the tables with the format of the information under art. 4 – 11 of the Draft ITS, as shown in its Annex I (p. 31 - 48 of the CP). Exempted payment institutions (table 2, p. 34 - 35), exempted EMIs (table 5, p. 41 - 42), agents (table 6, p. 43 - 44) and excluded service providers (table 8, p. 47 - 48) do – as per definition – not provide payment services on a cross-border basis in other (host) member states. Therefore, we agree on EBA’s choice not to capture this information (whether the natural or legal person also provides, or intends to provide, its payment and electronic money services in other (host) Member States) in table 2, 5, 6 and 8. With regard to table 7 (p. 45 – 46 pf EBA’s CP), which is meant for credit institutions “that are entitled under national law to provide payment services”, we would appreciate more clarity in this matter, as we explain in our answer on Q7.
We further recommend EBA that the search-functionalities in its central register will be able to deal with small typos and/or misspelled words (the human error factor). For example: the system ‘notices’ and notifies the user of the register that ‘paymnet’ could mean ‘payment’.
Regarding the “national identification number of the natural or legal person”, as mentioned in par. 18(c) (p. 9) and in art. 2(b) (p. 19) and art. 18(1) (p. 24) of the Draft RTS (and also in art. 2(d) of the Draft ITS on p. 28), we derive from art. 11(8) (p. 22) of the Draft RTS that every NCA uses a different structure for compiling these ID-numbers: “Competent authorities shall notify the EBA about the types of national identifiers and their format which competent authorities use in their national public registers and which the EBA shall use for validation purposes.”. To simplify the search for users of the central EBA register, we advocate that NCAs should structure these unique national ID-numbers in a consistent way across the EEA.
NB: Art. 4(1) (p. 20 of the CP) of the Draft RTS prescribes that each NCA “shall appoint at least one member of the staff who shall be responsible for inserting and modifying information manually via a web user interface in the electronic central register of the EBA.”. We recommend that, to prevent a ‘single point of capability”, that NCAs appoint at least two staff members in this matter. This to mitigate this risk, we suggest EBA to change the words “shall appoint at least one member of the staff who shall be responsible for inserting and modifying information manually via a web user interface in the electronic central register of the EBA.” into “shall set-up at least one staff function, where the responsibility for inserting and modifying information manually via a web user interface in the electronic central register of the EBA is assigned.” (a staff function can be shared between, for example, two staff members).
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.
As we explained in our answer to Q2, we believe that the central EBA-register should be updated via NCAs’ registers on a real-time basis. We further agree with EBA’s proposed non-functional requirements, which have to ensure that the central register functions robustly, reliably, efficiently, securely and user-friendly (both comprehensive and accessible), and that its data processing capacity will not turn out to be insufficient. We note that art. 15(3) of the Draft GLs (p. 23 of the CP) states: “The electronic central register of the EBA shall be with high level of availability”. The Draft RTS stay silent which availability percentage(s) are deemed to be “high”. We recommend EBA to be more specific here, by prescribing an availability percentage of at least 99,88% during prime time and 98,5% during non-prime-time. As an alternative, EBA could consider a requirement that its central register will adhere to the same requirements re. stability and performance as the requirements on stability and performance applicable to the dedicated interfaces (APIs) of ASPSPs, as the upcoming Final EBA RTS on SCA and CSC (most likely) will prescribe. Furthermore, art. 16(2) of the Draft GLs (p. 23 of the CP) describes that EBA “shall respond to the queries without undue delay within the working hours of the EBA business days.”. We advise EBA to formulate “without undue delay” more SMART, for example “within one working (EBA business) day”.As an additional risk mitigation feature, we suggest that the users of the central EBA register are offered a possibility to subscribe for receiving real-time alerts in case, for example, a PISP’s license or AISP’s registration has been withdrawn by its NCA. Alternatively, these alerts could be also send out by the individual NCAs.
Art 10 (2) (p. 21 of the CP) of the Draft RTS requires that EBA and NCAs apply secure encryption" when they implement automated provision of information for filling and updating the central EBA register. This to safeguard the integrity of the information processed. We note that encryption as such is primarily intended for safeguarding data-confidentiality, and not for safeguarding data-integrity. However, encryption seems to work quite well here as it is difficult to consciously manipulate an encrypted file. We recommend EBA to clearly describe its roles and responsibilities as well as those of NCAs with regard to assuring authenticity and integrity of data in the import- and update process. For example, will the EBA be able to "prove" that they used the originally sent single batch file to update its central register?
Furthermore, we recommend EBA to specify in its Final Draft RTS and ITS whether a difference in certain data held in a national register may exists for a limited period of time as compared to the central EBA register. In other words, how long may it maximally take for a data alteration in the national register to be imported and displayed in the central EBA register (for example: maximally one working day)? Ideally, this functions on a real-time basis.
Finally, we recommend EBA to add a requirement in its GLs that the non-functional requirements of its central register will be reviewed on a yearly basis, to check whether GL’s are still up-to-date and where improvements are necessary."
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.
We understand EBA’s rationale as explained in par. 33 to 35 (p. 13 of its CP) that it lacks a legal mandate to also include credit institutions (which can provide PIS and/or AIS too) in its central EBA register. However, we believe that credit institutions, at least those who offer PIS and/or AIS, should be included in the central EBA register as well. According to PSD2 art. 66(4)(a) and art. 98(1)(d) mutual authentication of PSPs is a requirement, once the RTS on SCA and CSC are applicable, as the secure communication between ASPSPs and TPPs shall allow for mutual identification and authentication, notification, information and implementation of security measures between all involved PSPs. This suggests the need for all ASPSPs (not only those which offer PIS and/or AIS) to be listed in the EBA central register, at least at a later stage (maybe when EBA has obtained legal mandate to do so in PSD3…). Current national NCAs registers for ASPSP do currently not seem to be ‘compliant’ with the EBA’s present Draft GL’s.In addition, we recommend EBA to design its central register “in such a way that it can be used for the purposes of Article 29 of the RTS on SCA and CSC, so that qualified trust service providers(QTSPs) will be able to identify properly all TPPs, including credit institutions, to whom they are requested to issue qualified certificates for electronic seals, and account servicing payment service providers will be able to check the credentials of these TPPs”, as stated in par. 34 (p. 13) of chapter 4 of EBA’s CP. This to ensure that all relevant PSD2 “XS2A” parties can interact with each other in a secure and effective manner.
NB: We noted that the letter ‘s’ is missing and the word ‘to’ is redundant in the text of art. 11 (3(a)) of the Draft RTS (p. 22 of EBA’s CP): “(…) electronic money institutions, exempted electronic money institution(s), the institutions referred to to (…).”.
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 agree, but strongly recommend that, next to the name of the institution as mentioned in par. 40 (a) (p. 14 of EBA’s CP), the brand (commercial) name of the natural or legal person under which its provides its payment services to the market should be recorded in EBA’s central register too. For our rationale, we refer to our response as provided under Q2. Adding the brand (commercial) name of the natural or legal person is in line with PSD2’s objectives related to the EBA register aiming at enhancing the transparency of the operations of payment institutions and ensuring a high level of consumer protection. For being able to add the brand (or commercial) name of the natural or legal person in the central EBA database, the brand (or commercial) name should also to be added in the national register of its NCA. After all, the registers of the NCAs ‘feed’ the central EBA register with information.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.
We are not sure. European legislation (already) prescribes PSPs (and other service providers) to provide their contact information to their clients. However, we believe that having access to contact details via the central EBA register could be helpful; for example in relation to PSD2 art. 73 (PSP’s liability for unauthorised payment transactions). This art. makes the ASPSP the PSU’s ‘first port of call’ in case of unauthorized payment transactions, also when a PISP is involved. When a payment transaction is initiated through a PISP, the ASPSP provider will have to refund the PSU. However, if the PISP is liable for the unauthorised payment transaction, it shall immediately compensate the ASPSP at its request – and therefore the ASPSP needs to know the contact details of the PISP concerned – for the losses incurred or sums paid as a result of the refund to the payer, incl. the amount of the unauthorised payment transaction. The burden of proof lies on the PISP that the payment transaction was authenticated, accurately recorded and not affected by a technical breakdown or other deficiencies – and therefore the PISP will need to know the contact details of the ASPSP too.We recommend EBA to include information about the qualified certificate for electronic seals, issued by the QTSP, in its central register. This to minimise fraud risk and to help PSPs (ASPSPs, PISPs and AISPs) validating each other, especially on a cross-border basis within the EU. We therefore propose to include certificate issuing dates and validity dates, as well as the names of the QTSPs, which have issued the certificate.
We further believe that the central EBA register should include dates of authorisation/registration, as well as the payment services provided in host member states. This because the central register is to be used by PSUs and other interested parties too. Knowing how long a PSP has been authorised/ registered in its home member state and/ or which payment services it provides in other (host) member states could be quite relevant information for the public. We believe this information provides additional transparency in the market, which will have a positive effect on consumers’ confidence in payment services offered on cross-border basis within the EU/ EEA, and is in line with PSD2’s objectives related to the central EBA register.
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.
We agree with EBA’s intention to also include information for service providers that are excluded from PSD2’s scope under the ‘limited network’-exemption (art. 3 (k(i)), ‘limited range of goods or services’ exemption’ (art. 3 (k(ii))) and ‘telecom’ exemption (art. 3 (l)). This will create enhanced transparency. However, for consistency-reasons, we favor to include information on agents and branches established in host member states as well.As we explained in our answer to Q4, we advocate that information of (credit) institutions referred to in points (4) to (23) of art. 2(5) of Directive 2013/36/EU (Capital Requirements Directive (CRD IV)) is also be included in the central EBA register, at least for those ASPSPs who offer PIS and/or AIS. However, EBA explains in par. 33 to 35 (p. 13 of its CP) that it lacks a legal mandate doing so. Art. 3(i) of the draft ITS (p. 29 of EBA’s CP) states that the central EBA register shall contain information about the following natural and legal persons: “i. the institutions referred to in points (4) to (23) of Article 2(5) of Directive 2013/36/EU, if they are entitled under national law to provide payment services;”. We recommend EBA to provide clarity on this; do NCAs also have to include the information as required by the Draft RTS and ITS, about credit institutions who also provide payment services, or not? Furthermore, we wonder what is exactly meant with “if they are entitled under national law to provide payment services;”.
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.
We tend to disagree with EBA’s approach to exclude the PSPs as addressed in Q8. When these PSPs offer PIS and/or AIS, we suggest to adopt the same approach as for excluded PSPs as indicated in Q7. This to minimise fraud risk and to help PSPs (ASPSPs, PISPs and AISPs) validating each other.We further recommend that, next to the name of the agent (as mentioned in par. 4 (a)) (p. 16 of EBA’s CP), the brand (commercial) name under which the service provider provides its payment services to the market should be recorded in EBA’s central register. This information needs to be captured in the tables with the format of the information under art. 4 – 11 of the Draft ITS as shown in its Annex I (p. 31 -48 of EBA’s CP). For our rationale, we refer to our answers to Q2 and Q5 (see above).
We also suggest EBA to clarify the relation between row 6, point 8 (‘Account information services’) of Table 1 (Format of the information on payment institutions) and Table 3 (Format of the information on AISPs) of Annex I of the draft ITS. We assume that when a PSP provides AIS only, e.g. no other payment services as mentioned in the Annex of PSD2, the NCA needs to provide EBA the information in the format as specified in Table 3. And when a PSP (also) provides other payment services (next to AIS) as mentioned in PSD2’s Annex, then the NCA needs to provide EBA the information about that PSP in the format as specified in Table 1 (and not in the format as specified in Table 3 also).
Finally, we reiterate the necessity of a clear link between the QTSP and the central EBA register (whether a PSP has a valid license (PIS) or registration (AIS) as granted by its NCA. We believe that such a link is a prerequisite to help market actors to assure that all relevant parties are authorized to operate in the (new) PSD2-world. The central EBA register should include information about the qualified certificate for electronic seals, issued by the QTSP to minimise fraud risk. We propose to include the certificate issuing date and validity date, as well as the name of the QTSPs, who have issued the certificates.
Please select which category best describes you and/or your organisation
[Other "]"If you selected "Other", please provide details
Betaalvereniging Nederland (Dutch Payments Association) organises the collective – noncompetitive - tasks in the national payment system for itsmembers. Our members are payment services providers who are active on the Dutch market: banks (credit institutions), payment institutions and electronic money institutions. Our responsibilities lie in the areas of infrastructure, standards and shared product features. We seek to ensure a socially efficient, safe and reliable payment system, with room for innovation.