Primary tabs

European Association of Co-operative Banks

General Comment:
The EACB welcomes the opportunity to contribute to this Public Consultation launched by the European Banking Authority (EBA) on the future EBA Register under the revised Payment Services Directive (PSD2). The EACB considers that many outstanding issues related to the usefulness and purpose of the Register remain open. Indeed we consider that one of the main shortfalls in the proposed design of the Register is that it will not function in real-time which clearly affects its usefulness and reliability.

The EACB would like to make the following comments regarding the option chosen by the EBA regarding the transmission of information by NCAs to the EBA:

 Article 4.1 of the Draft RTS: CA users of the register

The EACB considers that this article does not bring enough clarity on how a CA could, in a secure way, appoint a member of the staff to be responsible for manual insertion and modifications in the Register. For instance, we would welcome further details about the following points:

- whether or not this member of staff should be subject to any certification/authorisation procedure;
- How this decision should be communicated to EBA (letter, simple email, certified email, etc.)?
- It is not clear how CA should manage changes affecting the CA user. In the EACB’s view, a CA should communicate/update without any delay if the CA user has left this functions.

Additionally, the EACB thinks that only one member of the staff is not enough to ensure the continuity of the service. At least a backup should be appointed.

 Article 6.2 of the Draft RTS: Access by CA users
The meaning of the words “default username and password” is not clear. Are the default data all similar e.g. in a way that they could be deduced introducing as a result a potential security hole?
Which are the other security credentials? Physical or virtual token? Biometry?
How are these credentials communicated to users? (letter, simple email, certified email, etc.). The EACB would welcome additional means to minimize the risk of “phishing”.

 Article 10.5 of the Draft RTS: Automated provision of information
The EACB considers that it is important to ensure that available information in the Register is reliable and up-to-date. If the Register is only updated by the EBA once a day, we believe that there is an important risk that an ASPSPs continues to act on request of TPPs which are not authorized anymore. Updates should therefore be made available as they occur.

 Article 10.4 of the Draft RTS: Automated provision of information
We are not convinced that it is useful to specify the standard at this stage and in the way it is done. Either the standard is defined and then a lot more detail required or we leave the standard open. an .xls or .csv.

 Article 10.6 of the Draft RTS: Automated provision of information
As automatically transmitted information immediately replaces previous data just after a formal check, it is not clear how the risks of an error will be mitigated (e.g. a file containing only last updates and not the whole dataset: this could overwrite and delete also the previous correct data). Article 11.1 explains only in part how to avoid the risk of an accidental duplication but not the risk of an accidental deletion.
In order to be useful for PSPs, the EACB considers that the register should be “machine readable”. This would allow the applications of the users of the Register to extract automatically information from the application of the EBA Register for the identification of these PSPs. This functionality would be particularly relevant to fulfil the objectives of the RTS on strong customer authentication and common and secure communication.
Regarding the search criteria set in article 18 of the Draft RTS, the EACB believes that it would be useful to add ’’validity date range’’. This search criteria could be useful for instance to know in case of dispute whether or not a specific entity was authorized to operate within a certain period of time.
The EACB would like to comment on the safety requirements in Article 14.1 of the Draft RTS. Drawing a parallel with the request to PSPs in the context of the Guidelines on the notification of major incidents under PSD2, we would request that the EBA communicate to stakeholders if there has been a problem, the reasons behind the incident, if there could be a security risk (e.g. unauthorized subjects added) and the recovery timings and this preferably within 4 hours.
The EBA considers that credit institutions that provide payment initiation services and account information services cannot be covered by this Register because the mandate in article 15 (5) of PSD2 is limited to payment and electronic money institutions.
In contrast, the EACB considers that credit institutions providing PIS and AIS should be included in the register. Otherwise, this would create an obstacle to the PSP’s ability to check their identity at the expense of consumer protection. Additionally, this situation might also have a negative effect on cross-border transactions as consumers will lack the means to check the trustworthiness of foreign credit institutions acting as PSPs.
The EACB would like to note that in Annex 1 of the Draft ITS regarding standards and formats, a 50 characters length for the address could not be enough in certain circumstances. We propose to have instead a maximum length of the field of 75 characters.
The EACB does not agree with the approach taken by the EBA regarding the information to be included in the register. Indeed, the contact details of PSP’s should be part of the register in order to easily find a contact point if needed. The EACB considers that including information about the contact details of national competent authorities would also be beneficial.
We cannot see “user unfriendliness” in showing this information which would be in turn really valuable for any customer.
The EACB agrees with the extension of the information for the service providers excluded from the scope of the PSD2.
No comments.
[Trade association"]"
Pablo Lahoz Marco