Response to consultation on Guidelines on major incidents reporting under PSD2
Go back
Beyond the sharing of information between Member States, the ultimate objective of the reporting of operational and security incidents is not very clear (i.e. only best practices sharing is mentioned). Members of the EACB would appreciate some feedback from national authorities on the identification of such good practices for example.
Additionally, PSPs should be entitled to receive warnings from their competent authority about major incidents that could affect them in order to tackle them proactively.
Regarding question 1, the definition of ’’major operational or security incident’’ provided in page 21 of the Draft Guidelines is a good starting point but considering that other incident reporting procedures have spread across many different areas of EU legislation (e.g. NIS Directive or GDPR) the EACB would like to call for a consistency check between all existing definitions of incident. Indeed, it is crucial that the EBA makes sure that the definition provided in the Draft Guidelines does not imply an unintended duplication of the reporting obligations of PSPs.
Having said that, we consider that the Draft Guidelines should provide for the definition of an ’’operational or security incident’’ instead of the current definition of a ’’major operational or security incident’’. Indeed, the EACB believes that the classification of an incident as major or non – major is only the result of the assessment that PSPs should perform according to the criteria established in Guideline 1. The starting point should be to know what is an ’’operational or security incident’’ and then to have clear tools to classify it depending on its materiality.
Finally, it could also be useful to add a definition of “payment service user” or to refer to the one provided in PSD2 art. 4[10] with the objective to consistently use it in the Guidelines instead of the word “clients” (e.g. Guideline 1: Incident classification, 1.1., b.).
1) Need for a proportional reporting system:
- The Draft Guidelines should achieve a balance between what is essential to notify and a realistic timeframe to do so. This principle is particularly relevant for smaller organisations (e.g. many co-operative banks) which resources are limited. In practice, in smaller organisations, the employees that are investigating the incident are the same ones who have to fill in the reports relating to the incident. Therefore, oversize reporting and notification requirements mean less time for investigating the problem and preventing its harmful consequences. The current version of the Draft Guidelines require very detailed notification of incidents within a very short timeframe.
- Additionally, for some co-operative banks the reporting is made by the central body which needs to verify the information with regional cooperative banks (qualification of the incident, quantification of the impacts: number of customers, number of transactions and amounts, … ). In this context, reporting obligations need to consider the existing diversity within the European banking sector. Emphasis should be given at any time on investigating and repairing the incident rather than in following complex notification procedures. In this context, the EACB proposes a lighter notification procedure that is fit for purpose, feasible and realistic for all kind of PSPs (please, see answers to questions below).
2) Detailed comments on the criteria for the assessment of the materiality of an incident:
We would like to inform EBA that some of the criteria provided in the Draft Guidelines are already used by some co-operative banks and that based on the experience of using them, we would request the following changes:
• Clients affected – (assuming that “clients” are “payment service users”)
The feasibility will depend on the availability of the information required. For instance co-operative banks established at regional level might not have direct access to the identifying information related to each customer of a local co-operative bank for which the services are provided.
It is uncertain whether the total amount of the customers of the payment service provider or merely the customers that use the relevant payment service should be considered. Regarding the consolidated reporting process, it is uncertain whether the customers (total/service) of each payment service provider or the overall amount of customers of all the consolidated payment service providers should be considered.
Finally, it would be helpful to clarify the calculation of the threshold in case of several PSPs aggregation if they show very different size among each others. In particular, it would be helpful to clarify if PSPs have to take into account not only the number of clients but also the dimension and the qualification of the clients affected (i.e. physical person or corporate or big clients).
• Economic impact:
It might not be possible to determine exhaustively, in two weeks since business is deemed back to normal, the indirect economic impact of an incident (e.g. insurance refunds, lost revenues, customers complaints, etc.). Indeed, the normal time needed to assess a possible insurance refund and/or a submission of a claim by a customer exceeds two weeks (expected timing to deliver the final report). Overall, difficulties linked to determine indirect economic impact might lead to a situation where incidents are first classified as non-major" because of lack of actual data. The guidelines should be reduced to ask only for the direct costs linked to an incident (e.g. call a technician to replace a piece of hardware) which can be assessed within these deadlines.
Finally, it would be helpful to clarify why there is no “Level 1” economic impact threshold in Guideline 1.3.
• High level of internal escalation:
Using this criteria for the identification of a major incident may cause misleading internal behaviours when there is no clear evidence of a major incident state. The quantitative (objective) criteria most often already trigger internal escalation procedures, so there is no need to add a subjective criteria and mix internal and external communication procedures.
In addition we suggest not to use the “crisis mode” in Guideline 1.3 (table 1) for the initial classification of the incident because it is not necessarily known whether an incident triggers a ’’crisis mode’’ until more than two hours have gone by.
• Reputational impact:
Reputational impact is an unquantifiable factor and it is difficult to implement it especially when it comes to define the time frame to be considered. Furthermore, it would be helpful to clarify which are the “types of incident” (Guideline 1.2. g. v.) that should be recorded in order to search the same type of incident in the past.
Finally, the reputational risk assessment could be too expensive for PSPs if the regular social network monitoring is required.
3) Need to reduce the number of reports:
Regarding Guideline 2, the EACB would like to ask EBA that only 2 reports are compulsory for the notification of major incidents: an initial report and a final report. The EACB believes that intermediary reports do not bring any added value regarding the management of the incident itself while they create substantial administrative burdens for PSPs. Therefore, a reasonable reporting system would be:
• Initial report to be provided within the 24 hours from the moment when the incident is first classified as ’’major’’ using a simplified version of the template in Annex 1 (please, see answer to Question 7). Indeed, we believe that providing an initial report with all the information requested in the template (Annex1) within two hours is not materially feasible.
• Final report to be provided in a maximum of two weeks after business is deemed back to normal according to the Template in Annex 1 (please, find below our answer to question 5 to see the EACB proposal for the structure and content of the template)."
1) Stress that Guideline 2 should clearly state that the incidents that need to be reported are only those classified as ‘’major’’;
2) Reduce the amount of data to notify, the number of reports to provide and extend the time limits for doing so.
If not, we believe that the proposed methodology might capture less major incidents than those which are currently considered major according to the internal procedures of members of the EACB. Therefore, we would like to request EBA an extension of the time limits established to provide the reports which are too strict in the current Draft Guidelines.
Template: Major Incident Report (Page 36 - 37 of the Draft Guidelines)
1. GENERAL DETAILS
Report details:
EACB proposes to eliminate the obligation to present intermediary reports (see answer to question 2). The following fields should be deleted from the current version of the template - Section 1- :
• ''Is this an update of a previous incident report ? ''
• ''What is the ETA for next update? ''
2. INCIDENT DISCOVERY
EACB believes that it is necessary to eliminate the obligation to present intermediary reports. In line with this approach, we would propose the deletion of the following information field: ''If still ongoing, when is it expected to be over? (*).''
The EACB would like to replace ’’Actual date and time of recovery of the incident, if applicable (*)’’ by Date and Time of end of incident".
4. INCIDENT DESCRIPTION
The EACB would like to propose the deletion of ’’under investigation’’ as a suggested ’’causes of incident’’ because the words “under investigation” reflect a status description and not a cause.
The EACB would also like to request EBA to clarify what is meant with an ’’external event’’ as cause of the incident (e.g. natural disasters, strikes, pandemic, public unrest?).
5. INCIDENT IMPACT:
The EACB would like to request EBA to further clarify that filling the field ’’Building(s) affected (Address), if applicable (*)’’ is only mandatory if the situation effectively happens.
Furthermore, the EACB would like to suggest the addition of the following fields:
• Number of employees affected (specifically for external events, e.g. a percentage of employees cannot work because of unavailability of building, strike etc.);
• With regard to the field “Systems and components affected’’, we consider that the choices provided are too broad, please add subcategories (e.g.: OS: Linux, Windows.../ Application: Webserver/Tomcat, Network: router, switch, firewall...).
6. INCIDENT MITIGATION
Please, remove the following questions (no added value - and is part of root cause analysis):
• Is an investigation still ongoing?
If still ongoing: When is it planned to be concluded? How is the incident investigated and what are the priorities? Please provide additional details, if needed.
Furthermore, we have noticed a typographical error:
Did the PSP have (instead of had) to cancel or weaken ...?
8. ADDITIONAL INFORMATION:
The EACB would like to replace the following sentence ’’has the incident been shared with other PSPs for information purposes?’’ by ’’Has the incident been shared with other parties for information purposes (e.g.: other PSPs, CERTS, Cyber Threat Intelligence providers, Law Enforcement, Other - please explain?)’’. This because in some instances (if part of our NIS Directive obligations we may have to report to other instances.)"
Our suggestion in order to implement a reasonable reporting system is:
• Reduce the number of reports: We would ask EBA to request PSPs to provide only two reports:
Initial report to be submitted according to a simplified version of the Template in Annex 1 (please, see above) which would include only the following sections:
1 – General Details (all information fields);
2 - Incident Discovery: only short description of the incident;
3 - Incident Classification.
Final report to be submitted according to the Template in Annex 1 (please, find the EACB proposal for the structure and content of the template in the answer to question 5).
• Extend the deadlines to send the reports:
Initial report to be provided within the 24 hours from the moment when the incident is first classified;
Final report to be provided in a maximum of two weeks after business is deemed back to normal.
The EACB appreciates the interpretation that the EBA makes in the rationale section (paragraph 28) of the Consultation Paper about the delegated reporting procedure. Indeed, according to EBA ’’practical experience shows that the delegation of reporting obligations is most commonly used by groups of payment service providers (be they legal or not) that rely on one common IT-group service centre or one common technical service provider offering them the same services/processes/infrastructures.’’ This is the case for a number of cooperative banking groups where the individual local or regional banks delegate the reporting obligation to the central institution.
Having said that, the EACB is of the view that the requirements formulated under Guideline 3 do not fit the specific case of cooperative groups and networks. Indeed, article 4.40 of PSD2 defines ’’group’’ as a group of undertakings which are linked to each other by a relationship referred to in article 10. 1, 113.6 and 113.7 of the Regulation 575/2013/EU (i.e. Capital Requirements Regulation).
Considering the definitions provided by the EU legislator in articles 10.1, 113. 6 and 113.7 of the Capital Requirements Regulation, some of the conditions set in Guideline 3.1 for the delegated reporting are irrelevant for co-operative groups and networks as the delegation taking place is not to a “third party” but to a member of the group. Our concerns are in particular with the following:
• Guideline 3.1 b: definition of liabilities in the formal contract underpinning the delegated reporting; Indeed, when the reporting obligations are delegated to a body within the co-operative group or network, there is no need of a ’’formal contract underpinning the delegated reporting’’ which ’’unambiguously defines the allocation of responsibilities of all parties’’. According to the provisions of articles 10.1, 113.6 and 113.7 of the Capital Requirements Regulation, a co-operative group or network is characterised by a system which clearly allocates the liabilities between its members. Therefore, the EACB would like to request EBA to allow co-operative groups and networks which delegate their reporting obligations according to Guideline 3, to be exempted from the requirement of concluding such a contract.
• Guideline 3.1 c: compliance with the requirements for the outsourcing of important operational functions as set forth by Article 19 of the PSD2. The EACB would also request the EBA, to exempt co-operative groups and networks which delegate their reporting obligations according to Guideline 3, from the obligation to comply with PSD2 outsourcing requirements. Indeed, co-operative groups and networks should not be required to provide the competent authorities with all the information listed in Article 19. 1 of PSD2 because the management and the internal control mechanisms used are already unified within this kind of banking structures.
• Nevertheless, if a PSP delegates to third party, the EACB does not agree with the requirement consisting in informing the competent authority in the home Member State before the delegation of the reporting obligations. We believe that this burden is against the freedom of contract (also considering that PSPs remain fully responsible for the fulfilment of the obligation and of the requirements provided in art. 96 of PSD2). We agree with the request to inform the Authority but we believe that it’s sufficient to inform after the signature of the agreement.
Finally, it would be helpful to clarify the calculation of the threshold in case of consolidated reporting. In fact, it is not completely clear if it is necessary to consider the customers of a single PSP or the customers of the consolidated PSPs.
Having said that, the EACB would like to request the EBA to provide further clarity on the concept of “consolidated reporting”.
We gather from Guideline 3.2. b (p. 30) that a consolidated report can only be made on the basis of a “disruption in the technical services provided by the third party” to which the affected PSPs have delegated their reporting obligations. We don’t really understand why the consolidation should be made conditional on the incident being caused by a disruption in the technical services provided by the third party. In fact, a group consisting of several smaller PSPs could well benefit from the possibility of issuing consolidated reports for the whole group, even if the incident was not caused by a failure of the technical services provider. Such an opportunity would be even more interesting if thresholds for each criterion could be calculated for the whole group on a consolidated basis: this way, the PSP would not have to issue a report for an incident that can only be considered major for one entity, without significantly impacting or endangering the entire group.
Furthermore, the EACB would welcome a better illustration from EBA of the opportunities opened up by the consolidated reporting procedure, specifically by giving examples of situations in which a consolidated report may be issued. Is consolidation an option for a group consisting of many subsidiaries? What about a PSP wishing to issue a consolidated report with a non-capitalistic third party?
Besides, we are unsure of the way thresholds should be calculated in the context of consolidated reporting. Should they be calculated for each PSP or on a consolidated basis?
Finally, the EACB would like to stress that the added value for the market comes from further research and analysis based on information provided by the reports – but only if this is shared with the market participants. Thus it would be very valuable for all PSP's to get some kind of information from competent authorities relating to these major incident. Information at least at a certain extent should be shared in order to learn how to avoid same kind of incidents in the future.
Question 1: Do you consider the definitions included in the draft Guidelines to be sufficiently clear?
The EACB welcomes the opportunity to participate in the public consultation on Draft Guidelines on major incidents reporting under the Payment Services Directive 2. We would like to stress our concern about the volume and the extreme sensitivity of data and information to be gathered by the authorities. The EACB believes that PSPs should be informed about the security measures implemented by the authorities to keep safe all the information sent in the framework of these reporting obligations. Data leakages could lead to attacks, and reputational impact may be very high. As regards to competent authorities, the Draft Guidelines mention the confidentiality and integrity of the information exchanged but not the confidentiality of the information stored.Beyond the sharing of information between Member States, the ultimate objective of the reporting of operational and security incidents is not very clear (i.e. only best practices sharing is mentioned). Members of the EACB would appreciate some feedback from national authorities on the identification of such good practices for example.
Additionally, PSPs should be entitled to receive warnings from their competent authority about major incidents that could affect them in order to tackle them proactively.
Regarding question 1, the definition of ’’major operational or security incident’’ provided in page 21 of the Draft Guidelines is a good starting point but considering that other incident reporting procedures have spread across many different areas of EU legislation (e.g. NIS Directive or GDPR) the EACB would like to call for a consistency check between all existing definitions of incident. Indeed, it is crucial that the EBA makes sure that the definition provided in the Draft Guidelines does not imply an unintended duplication of the reporting obligations of PSPs.
Having said that, we consider that the Draft Guidelines should provide for the definition of an ’’operational or security incident’’ instead of the current definition of a ’’major operational or security incident’’. Indeed, the EACB believes that the classification of an incident as major or non – major is only the result of the assessment that PSPs should perform according to the criteria established in Guideline 1. The starting point should be to know what is an ’’operational or security incident’’ and then to have clear tools to classify it depending on its materiality.
Finally, it could also be useful to add a definition of “payment service user” or to refer to the one provided in PSD2 art. 4[10] with the objective to consistently use it in the Guidelines instead of the word “clients” (e.g. Guideline 1: Incident classification, 1.1., b.).
Question 2: Do you consider the criteria and methodology applicable for the assessment and classification of an incident as major to be sufficiently clear? If not, what should be further clarified?
The EACB would like to put forward the following comments about the criteria and methodology applicable for the assessment and classification of an incident as major:1) Need for a proportional reporting system:
- The Draft Guidelines should achieve a balance between what is essential to notify and a realistic timeframe to do so. This principle is particularly relevant for smaller organisations (e.g. many co-operative banks) which resources are limited. In practice, in smaller organisations, the employees that are investigating the incident are the same ones who have to fill in the reports relating to the incident. Therefore, oversize reporting and notification requirements mean less time for investigating the problem and preventing its harmful consequences. The current version of the Draft Guidelines require very detailed notification of incidents within a very short timeframe.
- Additionally, for some co-operative banks the reporting is made by the central body which needs to verify the information with regional cooperative banks (qualification of the incident, quantification of the impacts: number of customers, number of transactions and amounts, … ). In this context, reporting obligations need to consider the existing diversity within the European banking sector. Emphasis should be given at any time on investigating and repairing the incident rather than in following complex notification procedures. In this context, the EACB proposes a lighter notification procedure that is fit for purpose, feasible and realistic for all kind of PSPs (please, see answers to questions below).
2) Detailed comments on the criteria for the assessment of the materiality of an incident:
We would like to inform EBA that some of the criteria provided in the Draft Guidelines are already used by some co-operative banks and that based on the experience of using them, we would request the following changes:
• Clients affected – (assuming that “clients” are “payment service users”)
The feasibility will depend on the availability of the information required. For instance co-operative banks established at regional level might not have direct access to the identifying information related to each customer of a local co-operative bank for which the services are provided.
It is uncertain whether the total amount of the customers of the payment service provider or merely the customers that use the relevant payment service should be considered. Regarding the consolidated reporting process, it is uncertain whether the customers (total/service) of each payment service provider or the overall amount of customers of all the consolidated payment service providers should be considered.
Finally, it would be helpful to clarify the calculation of the threshold in case of several PSPs aggregation if they show very different size among each others. In particular, it would be helpful to clarify if PSPs have to take into account not only the number of clients but also the dimension and the qualification of the clients affected (i.e. physical person or corporate or big clients).
• Economic impact:
It might not be possible to determine exhaustively, in two weeks since business is deemed back to normal, the indirect economic impact of an incident (e.g. insurance refunds, lost revenues, customers complaints, etc.). Indeed, the normal time needed to assess a possible insurance refund and/or a submission of a claim by a customer exceeds two weeks (expected timing to deliver the final report). Overall, difficulties linked to determine indirect economic impact might lead to a situation where incidents are first classified as non-major" because of lack of actual data. The guidelines should be reduced to ask only for the direct costs linked to an incident (e.g. call a technician to replace a piece of hardware) which can be assessed within these deadlines.
Finally, it would be helpful to clarify why there is no “Level 1” economic impact threshold in Guideline 1.3.
• High level of internal escalation:
Using this criteria for the identification of a major incident may cause misleading internal behaviours when there is no clear evidence of a major incident state. The quantitative (objective) criteria most often already trigger internal escalation procedures, so there is no need to add a subjective criteria and mix internal and external communication procedures.
In addition we suggest not to use the “crisis mode” in Guideline 1.3 (table 1) for the initial classification of the incident because it is not necessarily known whether an incident triggers a ’’crisis mode’’ until more than two hours have gone by.
• Reputational impact:
Reputational impact is an unquantifiable factor and it is difficult to implement it especially when it comes to define the time frame to be considered. Furthermore, it would be helpful to clarify which are the “types of incident” (Guideline 1.2. g. v.) that should be recorded in order to search the same type of incident in the past.
Finally, the reputational risk assessment could be too expensive for PSPs if the regular social network monitoring is required.
3) Need to reduce the number of reports:
Regarding Guideline 2, the EACB would like to ask EBA that only 2 reports are compulsory for the notification of major incidents: an initial report and a final report. The EACB believes that intermediary reports do not bring any added value regarding the management of the incident itself while they create substantial administrative burdens for PSPs. Therefore, a reasonable reporting system would be:
• Initial report to be provided within the 24 hours from the moment when the incident is first classified as ’’major’’ using a simplified version of the template in Annex 1 (please, see answer to Question 7). Indeed, we believe that providing an initial report with all the information requested in the template (Annex1) within two hours is not materially feasible.
• Final report to be provided in a maximum of two weeks after business is deemed back to normal according to the Template in Annex 1 (please, find below our answer to question 5 to see the EACB proposal for the structure and content of the template)."
Question 3: Do you consider that the methodology will capture all of / more than / less than those incidents that are currently considered major? Please explain your reasoning.
(see also our comments under Q 2) In order to ensure that the right number of incidents are reported, in EACB’s view it is necessary to:1) Stress that Guideline 2 should clearly state that the incidents that need to be reported are only those classified as ‘’major’’;
2) Reduce the amount of data to notify, the number of reports to provide and extend the time limits for doing so.
If not, we believe that the proposed methodology might capture less major incidents than those which are currently considered major according to the internal procedures of members of the EACB. Therefore, we would like to request EBA an extension of the time limits established to provide the reports which are too strict in the current Draft Guidelines.
Question 4: In particular, do you propose to add, amend and/or remove any of the thresholds referred to in Guideline 1.3? If so, please explain your reasoning.
No comments.Question 5: Do you think that the information depicted in the template in Annex 1 is sufficient to provide competent authorities in the home Member State with a suitable picture of the incident? If not, which changes would you introduce? Please explain your reasoning.
(see also our comments on question 2) The EACB considers that the template in Annex 1 is not suitable for a timely notification of an incident to the competent authorities. We believe that the template should be shortened in general (see answer to question 3) and in particular for the initial report. With regard to the specific fields that the template proposes to fill in, we would have the following comments:Template: Major Incident Report (Page 36 - 37 of the Draft Guidelines)
1. GENERAL DETAILS
Report details:
EACB proposes to eliminate the obligation to present intermediary reports (see answer to question 2). The following fields should be deleted from the current version of the template - Section 1- :
• ''Is this an update of a previous incident report ? ''
• ''What is the ETA for next update? ''
2. INCIDENT DISCOVERY
EACB believes that it is necessary to eliminate the obligation to present intermediary reports. In line with this approach, we would propose the deletion of the following information field: ''If still ongoing, when is it expected to be over? (*).''
The EACB would like to replace ’’Actual date and time of recovery of the incident, if applicable (*)’’ by Date and Time of end of incident".
4. INCIDENT DESCRIPTION
The EACB would like to propose the deletion of ’’under investigation’’ as a suggested ’’causes of incident’’ because the words “under investigation” reflect a status description and not a cause.
The EACB would also like to request EBA to clarify what is meant with an ’’external event’’ as cause of the incident (e.g. natural disasters, strikes, pandemic, public unrest?).
5. INCIDENT IMPACT:
The EACB would like to request EBA to further clarify that filling the field ’’Building(s) affected (Address), if applicable (*)’’ is only mandatory if the situation effectively happens.
Furthermore, the EACB would like to suggest the addition of the following fields:
• Number of employees affected (specifically for external events, e.g. a percentage of employees cannot work because of unavailability of building, strike etc.);
• With regard to the field “Systems and components affected’’, we consider that the choices provided are too broad, please add subcategories (e.g.: OS: Linux, Windows.../ Application: Webserver/Tomcat, Network: router, switch, firewall...).
6. INCIDENT MITIGATION
Please, remove the following questions (no added value - and is part of root cause analysis):
• Is an investigation still ongoing?
If still ongoing: When is it planned to be concluded? How is the incident investigated and what are the priorities? Please provide additional details, if needed.
Furthermore, we have noticed a typographical error:
Did the PSP have (instead of had) to cancel or weaken ...?
8. ADDITIONAL INFORMATION:
The EACB would like to replace the following sentence ’’has the incident been shared with other PSPs for information purposes?’’ by ’’Has the incident been shared with other parties for information purposes (e.g.: other PSPs, CERTS, Cyber Threat Intelligence providers, Law Enforcement, Other - please explain?)’’. This because in some instances (if part of our NIS Directive obligations we may have to report to other instances.)"
Question 6: Are the instructions provided along with the template sufficiently clear and helpful to remove any doubts that could arise when completing the required fields? If not, please explain your reasoning.
No comments.Question 7: As a general rule, do you consider the deadlines and circumstances that should trigger the submission of each type of report (i.e. initial, intermediate and final) feasible? If not, please provide a reasoning and justify any alternative proposal.
In general, the EACB believes that the deadlines for the submission of each type of report are too short. In particular, it is not feasible to submit an initial report in 2 hours including all the information set in Annex1.Our suggestion in order to implement a reasonable reporting system is:
• Reduce the number of reports: We would ask EBA to request PSPs to provide only two reports:
Initial report to be submitted according to a simplified version of the Template in Annex 1 (please, see above) which would include only the following sections:
1 – General Details (all information fields);
2 - Incident Discovery: only short description of the incident;
3 - Incident Classification.
Final report to be submitted according to the Template in Annex 1 (please, find the EACB proposal for the structure and content of the template in the answer to question 5).
• Extend the deadlines to send the reports:
Initial report to be provided within the 24 hours from the moment when the incident is first classified;
Final report to be provided in a maximum of two weeks after business is deemed back to normal.
Question 8: Do you consider I that the delegated reporting procedure proposed in the draft Guidelines will provide added value to the market? Please explain your reasoning.
The EACB considers that the possibility to delegate reporting obligations adds value to the market. Indeed, it speeds up the reporting process, while keeping the affected PSPs fully responsible.The EACB appreciates the interpretation that the EBA makes in the rationale section (paragraph 28) of the Consultation Paper about the delegated reporting procedure. Indeed, according to EBA ’’practical experience shows that the delegation of reporting obligations is most commonly used by groups of payment service providers (be they legal or not) that rely on one common IT-group service centre or one common technical service provider offering them the same services/processes/infrastructures.’’ This is the case for a number of cooperative banking groups where the individual local or regional banks delegate the reporting obligation to the central institution.
Having said that, the EACB is of the view that the requirements formulated under Guideline 3 do not fit the specific case of cooperative groups and networks. Indeed, article 4.40 of PSD2 defines ’’group’’ as a group of undertakings which are linked to each other by a relationship referred to in article 10. 1, 113.6 and 113.7 of the Regulation 575/2013/EU (i.e. Capital Requirements Regulation).
Considering the definitions provided by the EU legislator in articles 10.1, 113. 6 and 113.7 of the Capital Requirements Regulation, some of the conditions set in Guideline 3.1 for the delegated reporting are irrelevant for co-operative groups and networks as the delegation taking place is not to a “third party” but to a member of the group. Our concerns are in particular with the following:
• Guideline 3.1 b: definition of liabilities in the formal contract underpinning the delegated reporting; Indeed, when the reporting obligations are delegated to a body within the co-operative group or network, there is no need of a ’’formal contract underpinning the delegated reporting’’ which ’’unambiguously defines the allocation of responsibilities of all parties’’. According to the provisions of articles 10.1, 113.6 and 113.7 of the Capital Requirements Regulation, a co-operative group or network is characterised by a system which clearly allocates the liabilities between its members. Therefore, the EACB would like to request EBA to allow co-operative groups and networks which delegate their reporting obligations according to Guideline 3, to be exempted from the requirement of concluding such a contract.
• Guideline 3.1 c: compliance with the requirements for the outsourcing of important operational functions as set forth by Article 19 of the PSD2. The EACB would also request the EBA, to exempt co-operative groups and networks which delegate their reporting obligations according to Guideline 3, from the obligation to comply with PSD2 outsourcing requirements. Indeed, co-operative groups and networks should not be required to provide the competent authorities with all the information listed in Article 19. 1 of PSD2 because the management and the internal control mechanisms used are already unified within this kind of banking structures.
• Nevertheless, if a PSP delegates to third party, the EACB does not agree with the requirement consisting in informing the competent authority in the home Member State before the delegation of the reporting obligations. We believe that this burden is against the freedom of contract (also considering that PSPs remain fully responsible for the fulfilment of the obligation and of the requirements provided in art. 96 of PSD2). We agree with the request to inform the Authority but we believe that it’s sufficient to inform after the signature of the agreement.
Finally, it would be helpful to clarify the calculation of the threshold in case of consolidated reporting. In fact, it is not completely clear if it is necessary to consider the customers of a single PSP or the customers of the consolidated PSPs.
Question 9: Do you consider that the consolidated reporting procedure proposed in the draft Guidelines will provide added value to the market? Please explain your reasoning.
Yes, it provides added value to the market but it should stay optional as it often depends on existing legal frameworks and SLAs which add complexity and might actually delay reporting.Having said that, the EACB would like to request the EBA to provide further clarity on the concept of “consolidated reporting”.
We gather from Guideline 3.2. b (p. 30) that a consolidated report can only be made on the basis of a “disruption in the technical services provided by the third party” to which the affected PSPs have delegated their reporting obligations. We don’t really understand why the consolidation should be made conditional on the incident being caused by a disruption in the technical services provided by the third party. In fact, a group consisting of several smaller PSPs could well benefit from the possibility of issuing consolidated reports for the whole group, even if the incident was not caused by a failure of the technical services provider. Such an opportunity would be even more interesting if thresholds for each criterion could be calculated for the whole group on a consolidated basis: this way, the PSP would not have to issue a report for an incident that can only be considered major for one entity, without significantly impacting or endangering the entire group.
Furthermore, the EACB would welcome a better illustration from EBA of the opportunities opened up by the consolidated reporting procedure, specifically by giving examples of situations in which a consolidated report may be issued. Is consolidation an option for a group consisting of many subsidiaries? What about a PSP wishing to issue a consolidated report with a non-capitalistic third party?
Besides, we are unsure of the way thresholds should be calculated in the context of consolidated reporting. Should they be calculated for each PSP or on a consolidated basis?
Finally, the EACB would like to stress that the added value for the market comes from further research and analysis based on information provided by the reports – but only if this is shared with the market participants. Thus it would be very valuable for all PSP's to get some kind of information from competent authorities relating to these major incident. Information at least at a certain extent should be shared in order to learn how to avoid same kind of incidents in the future.