Response to consultation on Guidelines on major incidents reporting under PSD2
Go back
The current definitions are not always fully clear. As an example there is a strong link between the terms “availability” and “continuity”. If EBA considers that both definitions are required, they should clarify in more detail the difference.
The definition of “Major operational or security incident” on page 21 does not clearly quantify what “Major” is, nor does it clarify what “material adverse impact” is. We advise to delete the term “major” from the definition here (it only specifies what an incident is) since “major” is defined in Guideline 1. Also the word “event” should be further explained.
The principle of neutrality and proportionality must be respected by the supervisory authorities to preserve the level playing field with respect to the implementation of the criteria and methodology provided by these guidelines.
However, the criteria need to be sometimes clarified especially to avoid too many declarations for large PSP. We would appreciate further clarifications as suggested below.
In general, PSPs currently need to respect already several incident reporting requirements from their national authorities. These new EBA guidelines will lead to new reporting requirements. The guidelines should make clear to the competent authorities in the Member States that the guidelines should replace similar reporting requirements to these authorities.
The criteria introduced do not distinguish between incidents leading to unavailability of the service (e.g. a DDoS attack, or an internal failure leading to unavailability of the service) and other types of incidents. We think that an unavailability of the service for a short period (e.g. 5min.) should not be categorised as major incident, even though this (potentially) may affect all customers.
Moreover, some criteria are not applicable on AISP: number of payment transactions, one of the three targeted objective thresholds, is not applicable to AISP as a triggering criteria. It could be necessary to define and put in place specific criteria regarding AISP activity (e.g., including loss of data). Specific provisions regarding AISP should be included in the guidelines (as opposed to the rationale only).
Another point of attention is the case of an external event which is leading to an incident (e.g. an example: telecommunication is unavailable for a number of days in (or part of) a country, leading to non-availability of internet, etc.). It is of course relevant to inform the domestic competent authority but what are the reporting requirements for such incidents? Intermediate reports from the PSP are not relevant if the root cause lies outside the PSP’s liabilities. Only initial and final report should be relevant in this case.
Different stakeholders including customers, TPPs and ASPSPs could be involved in the same payment chain. An incident might affect a TPP and that incident can potentially require reporting by the TPP to the competent authority. If this incident could impact the ASPSP, the competent authority should have to share information to the ASPSP on the basis of the information provided by the TPPs, to enable the ASPSPs to take all necessary actions in order to prevent other incidents or further breaches. The methodology applied should cater a 2-way communication: PSP to regulatory authority (ACPR in FRANCE) and ACPR to the other PSP interested. Each PSP (ASPSP as TPP) is interested in receiving “early warnings” about relevant major incidents that are affecting the payments industry, which would allow them to take pro-active measures.
With respect to thresholds, regarding cooperative PSPs members of the mutualists or cooperatives groups, we would appreciate that the trigger of criteria can be made on a consolidated basis, when consolidation is applicable as defined in the guidelines - Chapter 4 guideline 3-. The threshold of each criterion could be assessed with respect to the group rather than PSP by PSP.
We would like to be informed about the security measures that will be implement by authorities to keep safe the information sent by PSPs. What are the protections to avoid the data leakages (strengthening of the capacitation, authorisation/security of the channels used)? We are worried about the consequences if such reporting information was stolen. Reputational impact could be higher for the declaring PSP concerned.
The provisions specified 6.3 and 6.4 (page 33) are exposed at a very high level and their implementation does not seem sufficiently detailed to avoid any operating risk resulting in a fraudulent exploitation.
It could result attacks, for example,
… on PSPs having declared a major incident and, as such, having disclosed information on their vulnerability topics,
… on PSP’s authentication servers, vulnerable to the stress once identified.
Moreover, the data sharing within European or National agreed authorities should be made under the appliance of the same reciprocal rules of confidential and privacy, especially regarding PSP’s weakness topics reveled by the major incident they have declared.
Beyond the sharing of information between domestic authorities, French Banks feel the reporting would have an interest in a preventive aim but it seems that it is not the target of this document. The ultimate aim of the inflow for all these authorities is not very clear.
We would like the EBA to clarify what will be done with all the information gathered. Will it be analysed? If so, will those analyses be made available to PSPs? We are convinced that reporting will be most beneficial if used not only for statistical purposes, but also as source of experience feedback for all stakeholders.
In the same way, we feel very strongly that the Competent Authority should take the reports it receives as an opportunity to provide – anonymised – early warnings to other PSPs in a timely manner on security incidents and emerging threats. Those warnings should be sufficiently detailed so as to facilitate understanding of the specific cause and enable precautions to be taken if necessary and/or possible.
Last but not least, we would also be interested in knowing whether the data collected, as well as the analyses made on this database, will be used as a basis for the elaboration of future procedures, policies or regulations. If such is indeed the case, please clarify which (regulatory or legislative) institutions are likely to make use of this information.
Feedback on major incidents to PSP should be forecasted.
Transactions affected (p 23, 1.1): We need an example of calculation method to understand which level of transaction the PSP has to take into account. Especially, the denominator must be specified.
We understand that we have to calculate like this:
Example: Number of cards transactions compromised upon total number of card transactions by mark of payments (for example “Cartes Bancaires” are cobranded sometimes with VISA, sometimes with Master Card).
There is a need to specify as follows in the guidelines that: “PSP should determine the total value and the number of the transactions affected as a percentage of the regular level of payment transaction carried out with the same type of payment instruments.
“Client affected” (p 23 1.1.c) or “users”? : For clarification the wording “client” would have to be replaced by PSU “payment service user” as customers are mentioned as such in PSD2. The PSU reporting is understood to be on incidents with the final PSU only: Please thanks to confirm that interbank incidents are out of the scope.
French Banks feel that the ability to appreciate the criteria “clients affected” with respect to the number of client AND the percentage of clients is relevant. It allows identifying in an appropriate way major incident for a small as large PSPs.
Level 2 incidents: We agree on the wording “or” which must be kept (50 000 clients affected or > 25% of the payment PSP’s clients) because it allows to identify in an appropriate way major incident for a small as large PSPs.
For example: an incident may be major for an affiliate but minor at the group level.
The Guidelines have to remain open and adaptable whatever is the declaring PSP, according to the incidents.
The criteria mentioned don’t make distinction between large and smaller PSPs. We assume that the thresholds for “transactions affected” can be relevant for PSPs with a limited number of transactions or transaction amounts. However, for large PSPs the threshold to define level 1 for the transactions affected (10% of the payment service provider’s regular level of transactions”) is too low regarding our current experience.
Economic impact
There is no threshold to appreciate economic impact for level 1 incident, we understand that we don’t have to calculate economic impact when declaring level 1 of payment incident reporting and we agree on.
We underline that it is not easy (or even impossible) to calculate quickly the economic impact with the details required in the guidelines p 24 (“expropriated funds or assets” / fees due to non-compliance of contractual obligations, sanctions, etc). Those elements won’t be known straight away and staff in charge of incident reporting won’t be able to provide this information.
In addition, we don’t understand the relevance and the objective of providing information on direct and indirect costs to the national authority. We feel that only direct economic impact losses immediately determined should be reported.
Finally, we would suggest to align the thresholds with the thresholds of other regulations (e.g. for example the French banking supervisory authority (ACPR regulation) specifies that Economic Impact have to be higher than 25 M€ to be declared)
Reputational impact
We suggest that the criteria “reputational impact” is replaced by “high reputational impact”
High level of internal escalation
The reporting to the CISO (Chief Information Security Officer) should not be considered as a potential significance for the incident. In some financial institutions, all incidents are reported to the CISO. Some of them are mitigated, and others are non-significant (for example, a ransomware attack over one PC, which is mitigated using restore and backup techniques). A more reasonable approach would be that if the incident is reported to the Board of Directors or equivalent, then, it may be considered as potentially significant, but again, even so, the incident could end up being insignificant. For example, a DDOS attack, occurring during the night, which is mitigated in 180 mins, , service downtime is greater than 2 hours but affects no customer at all.
To conclude: each PSP should be responsible to assess whether the criterion « high level of internal escalation » is reached according to its own risk policy.
Instructions are very complete. They illustrate that it will take time to fulfil this reporting template.
General comments
Articulation between this reporting and reporting planed by other regulation:
The template is prepared for the reporting of major incident in the DSP2 framework only. French banks wish to stress that for the same single incident, each PSP will have to make several notification to several authorities:
- majors incidents reporting required by DSP2 to their supervisory banking authority (ACPR),
- incidents regarding the breach of personal data to their data protection authority (CNIL),
- and regarding EU directive 2016/1148 of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union (the NIS directive) they should have to report this same incident if it has a significant impact on the continuity of the service given to the French Agency for the security of information systems (ANSSI). Notwithstanding other reporting required at national level.
We would like to prevent overburdening PSPs with new different notification requirements.
Preferably, authorities should accept the same reporting template (maybe with a different reporting frequency). Too many reporting will damage efficiency of the PSP. We consider that PSP should focus first to solve the incident rather than to provide several different reporting in a very short time. So, it is necessary to harmonized all types of incidents reporting.
The guidelines do not mention the confidentiality of the information provided to the competent authority. We believe that this sensitive information should be considered confidential. No request, for example by a journalist, should potentially lead to the disclosure of any of the information provided to the competent authority.
The template
- Formal comments:
1) A clearer distinction than an asterisk (*) should be made between data that are mandatories or optional. For example in the chapter”Incident discovery”, field “actual date and time of recovery of the incident, if applicable”: we think this information should be optional as it is specified “if applicable”.
2) It would be useful to homogenize the presentation: check boxes are sometimes on the right of the item (e.g. report detail line 2) and sometimes on the left (line 3 Type of report individual / consolidated): an option has to be chosen and kept regarding the all document.
3) Report details “What is the ETA for next update”: We suggest to avoid abbreviation: “ETA” should be replaced by “Estimated Time of arrival”.
- First notification: In the event of a major incident, primary focus in an organisation will be to fix the incident. Whilst the notification is of upmost importance, we feel the timeline should be extended. If this is not possible, shorter details should be given as a first notification in the two hour time window after the qualification of the incident as major, with further detail to follow on in the next stages of communication. The EBA could achieve this by using only the “1 – General Details” section of the major incident report under Annex 1. Companies would remain free to provide further detail in the first notification as they wish.
- Incident discovery: The « date and time of beginning of incident, if known» should be optional. Only the « date and time of detection of the incident » should be mandatory.
- Economic impact: It would be useful for the EBA to include a currency drop down box in the form for non-euro currencies. The reportable currency within the template, should also allow for the host currency of the Member State. i.e. UK = GBP
- Reputational impact should be replaced by “high reputational impact”.
- System failure This section should be split into separate categories, for example, software or hardware failure, to allow a greater level of understanding across PSPs.
- Incident Impact: There should be a measure of “staff impact” as this may affect the ability to maintain services, for example, security incidents such as a terrorist attack where staff are unable to travel or are directly at risk.
1. It might be useful that each report be duly identified with a unique identification number, that needs to be specified by the Guidelines, (e.g. date and ID number, 2-1-2017/1, …), and that will be used as a unique reference for the incident reporting.
2. In the field “Economic impact”, “Indirect costs”: We do not understand the relevance and the objective of providing information on indirect costs to the national authority”. We feel only direct economic impact losses immediately determined should be reported in the template.
3. In the field “cause of incident”, in the “type of attack”, the choices “infection of internal systems” and “targeted intrusion” need more clarification and could be overlapping (e.g.: What choice should be made of a malware 0-day attack for stealing information?).
4. In the field “Systems and components affected”, it is suggested to also have “security infrastructure” as a choice (this would allow to include Hardware Security Modules used for authentication and transaction processing).
We further recommend including a support call center to clarify any doubts that may appear during the completion.
More explanation is needed to complete the template in case of “consolidated reporting”.
1) Grading a “major” incident can take time. It is better to take time properly to describe the major incident and to make relevant statements rather than to notify in mass incidents which will be requalified afterwards like “non-major”. It is necessary to take into account of the criticality of the environment impacted by the incident. The reactivity level depends on the incident environment. An incident on a less critical environment doesn’t need the same reactivity than an incident on an environment which is more critical.
Moreover, the aim of these guidelines is “to assess the success of applicable law and to identify good practices across the market”. To achieve these aims, it is not necessary to ask for an initial notification “in two hours”. As there are no “operational objectives”, to help the PSP to solve the incident, this reporting is not an urgent matter. It would be more efficient and reasonable to report an incident when it is analysed and classified as “major”, to be sure to report a pertinent incident.
2) The second aim of this reporting is to respond to a need of “common approach in European Union”. We agree on a common approach which is useful and will allow statistical analysis and European best practice. To have a useful and efficient European reporting, it has to be limited on selected relevant incidents and then focus only on major incidents.
3) Finally, the Guidelines are “aimed at preventing PSP from being overburdened with reporting duties while responding to an incident as well as avoiding to create undue distortions between the smaller and the bigger players in the market”. By asking 3 reports (i.e initial, intermediate and final), during the life cycle of the incident, the Guidelines are conflicting with the aim written above (“aimed at preventing PSP from being overburdened”) because it will overburdened the PSP with reporting duties.
4) At a practical point of view, the only way to make a safe and quick reporting would be the EBA request from the national supervisory authorities to put in place an extranet website apps duly secured, that would insure a sharing of information respecting its confidentiality as its integrity specially regarding the risk of disclosure to not concerned parties or regarding exchanges within national others supervisory boards. For national authorities, statistical analysis would be easier with this tool than email sent by hundreds of PSP. For French banks, the security issues raise by the notification of the incident is a key topic. It is really necessary to have a deeply secured gateway, protected by strict access conditions (qualified certificate) to reserve access only to people duly authorized.
Initial report
Initial report should be done from the moment when the PSP has qualified the incident as “major” and must be reported ASAP (as soon as possible). PSP should do its best effort to declare the major incident the same day when the incident is classified as major. 2H delay from the moment the incident was detected as such is too short. EBA has at least to take into account working days, the time of the incident (during the night or the day).
In the course of processing, the reporting cannot be made within too short lead times except penalizing the processing of the incident.
We would like to point that article 33 of regulation 2016/679 of the European parliament and of the council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, indicates that the notification of a personal data breach to the supervisory authority shall be done without undue delay and, where feasible, not later than 72 hours after having become aware of it and that where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay. We request that at least, times to report provided by the different regulation are the same.
In any case, the two hours deadline is to short, considering internal escalation procedures within the PSP or within the Group it belongs.
We request a 24h delay (business day) starting from the moment the incident is qualified by the PSP as “major” to declare it (instead of 2H delay).
Intermediate report
We think that intermediate reports are not necessary for national authority analysis. Reporting would be heavy to make and requires, especially within large PSP. « Intermediary report with a maximum limit of 3 days » is burdensome and could delay the management of the incident itself. EBA should have in mind that this kind of notification doesn’t exist in France yet and must be implemented from scratch. Therefore, there are resources issues to manage (IT and human resources).
The only way to make a safe and quick intermediate reporting would be the EBA allows to make the declaration of the incident via an extranet website or a dedicated application.
Final report
End date of a major incident: when the incident is no more considered as a major incident by PSPs because the incident is under the control of the PSP, banks expect than they can stop the reporting even if the business is not fully deemed back to normal.
As a conclusion, on the reporting, we request the following alternative proposals:
- Regarding the initial report, we request a 24h delay (business day) starting from the moment the incident is qualified by the PSP as “major” to declare it (instead of 2H delay).
- An highly secured dedicated extranet solution is requested to have a secured sharing solution (better than exchanges via secured email or secured on line document system (p 15, part 37)
- Only two reports (initial and final); intermediary report only on demand of the supervisory authority).
Nevertheless, the requirement consisting in informing the competent authority in the home Member State before the delegation of the reporting obligations does not seem relevant in the context of an ongoing pre contractual deal. 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 suggest to delete this requirement. We agree with the request to inform the Authority but after the signature of the contractual agreement.
We understand that, if a third party manages, for example, a payment processing platform used by several PSPs of a banking Group, the third party processing the platform could declare a major incident on its platform.
So it would provide PSPs (clients of this third party) an added value, if the declaration would be, as we understand:
-made by the operator of the platform at a global level, if all PSPs affected in the same manner (or by each affected PSP, if they are not affected in the same way).
- and based on consolidated thresholds for all PSPs affected with a global declaration to each of the competent national authority concerned.
in each case “banking PSPs group” by “banking PSPs group”.
Consolidated reporting procedure would be 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 be considered major for only one entity, without significantly impacting or endangering the entire group.
We understand that if a PSP’s common technical service provider manages, for example, a payment processing platform used by several PSPs, the PSP’s common technical service provider could declare a major incident on its platform as explained in rationale 28 and 29. (Guidelines article 3.2)
It would give PSPs an added value, if the declaration would be, as we understand:
-made by the PSP’s common technical service provider at a global level, if all PSPs are affected in the same manner (or by each affected PSP, if they are not affected in the same way).
-and based on the mandate received from PSPs and, regarding this mandate, sometimes based on consolidated thresholds with a consolidated declaration to each of the national competent authority.
We understand that such a report could be issued by a payment scheme or CSM when affected by a technical failure with repercussions on several participant PSPs. Indeed, in this case, it might be more efficient to provide the EBA with one consolidated report from the scheme rather than with several identical reports from individual PSPs.
Suggestions:
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 question why 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 capability of issuing consolidated reports for the whole group, even if the incident was not caused by a failure of the technical services provider.
Similarly, we fail to understand why consolidation should be limited to PSPs established in the same Member State. We feel that this would go against the harmonisation of the European market, in addition to being impractical for PSPs established in several Member States.
Question 1: Do you consider the definitions included in the draft Guidelines to be sufficiently clear?
We advise that EBA adopts definitions from international organizations such ENISA which are already widely used in the industry and in related regulations (e.g. GDPR, NIS Directive, eIDAS).The current definitions are not always fully clear. As an example there is a strong link between the terms “availability” and “continuity”. If EBA considers that both definitions are required, they should clarify in more detail the difference.
The definition of “Major operational or security incident” on page 21 does not clearly quantify what “Major” is, nor does it clarify what “material adverse impact” is. We advise to delete the term “major” from the definition here (it only specifies what an incident is) since “major” is defined in Guideline 1. Also the word “event” should be further explained.
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?
We consider that the methodology applicable for the assessment and classification of an incident as major is clear.The principle of neutrality and proportionality must be respected by the supervisory authorities to preserve the level playing field with respect to the implementation of the criteria and methodology provided by these guidelines.
However, the criteria need to be sometimes clarified especially to avoid too many declarations for large PSP. We would appreciate further clarifications as suggested below.
In general, PSPs currently need to respect already several incident reporting requirements from their national authorities. These new EBA guidelines will lead to new reporting requirements. The guidelines should make clear to the competent authorities in the Member States that the guidelines should replace similar reporting requirements to these authorities.
The criteria introduced do not distinguish between incidents leading to unavailability of the service (e.g. a DDoS attack, or an internal failure leading to unavailability of the service) and other types of incidents. We think that an unavailability of the service for a short period (e.g. 5min.) should not be categorised as major incident, even though this (potentially) may affect all customers.
Moreover, some criteria are not applicable on AISP: number of payment transactions, one of the three targeted objective thresholds, is not applicable to AISP as a triggering criteria. It could be necessary to define and put in place specific criteria regarding AISP activity (e.g., including loss of data). Specific provisions regarding AISP should be included in the guidelines (as opposed to the rationale only).
Another point of attention is the case of an external event which is leading to an incident (e.g. an example: telecommunication is unavailable for a number of days in (or part of) a country, leading to non-availability of internet, etc.). It is of course relevant to inform the domestic competent authority but what are the reporting requirements for such incidents? Intermediate reports from the PSP are not relevant if the root cause lies outside the PSP’s liabilities. Only initial and final report should be relevant in this case.
Different stakeholders including customers, TPPs and ASPSPs could be involved in the same payment chain. An incident might affect a TPP and that incident can potentially require reporting by the TPP to the competent authority. If this incident could impact the ASPSP, the competent authority should have to share information to the ASPSP on the basis of the information provided by the TPPs, to enable the ASPSPs to take all necessary actions in order to prevent other incidents or further breaches. The methodology applied should cater a 2-way communication: PSP to regulatory authority (ACPR in FRANCE) and ACPR to the other PSP interested. Each PSP (ASPSP as TPP) is interested in receiving “early warnings” about relevant major incidents that are affecting the payments industry, which would allow them to take pro-active measures.
With respect to thresholds, regarding cooperative PSPs members of the mutualists or cooperatives groups, we would appreciate that the trigger of criteria can be made on a consolidated basis, when consolidation is applicable as defined in the guidelines - Chapter 4 guideline 3-. The threshold of each criterion could be assessed with respect to the group rather than PSP by PSP.
We would like to be informed about the security measures that will be implement by authorities to keep safe the information sent by PSPs. What are the protections to avoid the data leakages (strengthening of the capacitation, authorisation/security of the channels used)? We are worried about the consequences if such reporting information was stolen. Reputational impact could be higher for the declaring PSP concerned.
The provisions specified 6.3 and 6.4 (page 33) are exposed at a very high level and their implementation does not seem sufficiently detailed to avoid any operating risk resulting in a fraudulent exploitation.
It could result attacks, for example,
… on PSPs having declared a major incident and, as such, having disclosed information on their vulnerability topics,
… on PSP’s authentication servers, vulnerable to the stress once identified.
Moreover, the data sharing within European or National agreed authorities should be made under the appliance of the same reciprocal rules of confidential and privacy, especially regarding PSP’s weakness topics reveled by the major incident they have declared.
Beyond the sharing of information between domestic authorities, French Banks feel the reporting would have an interest in a preventive aim but it seems that it is not the target of this document. The ultimate aim of the inflow for all these authorities is not very clear.
We would like the EBA to clarify what will be done with all the information gathered. Will it be analysed? If so, will those analyses be made available to PSPs? We are convinced that reporting will be most beneficial if used not only for statistical purposes, but also as source of experience feedback for all stakeholders.
In the same way, we feel very strongly that the Competent Authority should take the reports it receives as an opportunity to provide – anonymised – early warnings to other PSPs in a timely manner on security incidents and emerging threats. Those warnings should be sufficiently detailed so as to facilitate understanding of the specific cause and enable precautions to be taken if necessary and/or possible.
Last but not least, we would also be interested in knowing whether the data collected, as well as the analyses made on this database, will be used as a basis for the elaboration of future procedures, policies or regulations. If such is indeed the case, please clarify which (regulatory or legislative) institutions are likely to make use of this information.
Feedback on major incidents to PSP should be forecasted.
Transactions affected (p 23, 1.1): We need an example of calculation method to understand which level of transaction the PSP has to take into account. Especially, the denominator must be specified.
We understand that we have to calculate like this:
Example: Number of cards transactions compromised upon total number of card transactions by mark of payments (for example “Cartes Bancaires” are cobranded sometimes with VISA, sometimes with Master Card).
There is a need to specify as follows in the guidelines that: “PSP should determine the total value and the number of the transactions affected as a percentage of the regular level of payment transaction carried out with the same type of payment instruments.
“Client affected” (p 23 1.1.c) or “users”? : For clarification the wording “client” would have to be replaced by PSU “payment service user” as customers are mentioned as such in PSD2. The PSU reporting is understood to be on incidents with the final PSU only: Please thanks to confirm that interbank incidents are out of the scope.
French Banks feel that the ability to appreciate the criteria “clients affected” with respect to the number of client AND the percentage of clients is relevant. It allows identifying in an appropriate way major incident for a small as large PSPs.
Level 2 incidents: We agree on the wording “or” which must be kept (50 000 clients affected or > 25% of the payment PSP’s clients) because it allows to identify in an appropriate way major incident for a small as large PSPs.
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.
We consider that the methodology and the proposed thresholds will conduct to capture more incidents than those that are currently considered as major because those thresholds maybe too low, mostly for large PSPs. EBA really has to limit this reporting to major incidents. We suggest to apply highest thresholds levels.For example: an incident may be major for an affiliate but minor at the group level.
The Guidelines have to remain open and adaptable whatever is the declaring PSP, according to the incidents.
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.
Transactions affected:The criteria mentioned don’t make distinction between large and smaller PSPs. We assume that the thresholds for “transactions affected” can be relevant for PSPs with a limited number of transactions or transaction amounts. However, for large PSPs the threshold to define level 1 for the transactions affected (10% of the payment service provider’s regular level of transactions”) is too low regarding our current experience.
Economic impact
There is no threshold to appreciate economic impact for level 1 incident, we understand that we don’t have to calculate economic impact when declaring level 1 of payment incident reporting and we agree on.
We underline that it is not easy (or even impossible) to calculate quickly the economic impact with the details required in the guidelines p 24 (“expropriated funds or assets” / fees due to non-compliance of contractual obligations, sanctions, etc). Those elements won’t be known straight away and staff in charge of incident reporting won’t be able to provide this information.
In addition, we don’t understand the relevance and the objective of providing information on direct and indirect costs to the national authority. We feel that only direct economic impact losses immediately determined should be reported.
Finally, we would suggest to align the thresholds with the thresholds of other regulations (e.g. for example the French banking supervisory authority (ACPR regulation) specifies that Economic Impact have to be higher than 25 M€ to be declared)
Reputational impact
We suggest that the criteria “reputational impact” is replaced by “high reputational impact”
High level of internal escalation
The reporting to the CISO (Chief Information Security Officer) should not be considered as a potential significance for the incident. In some financial institutions, all incidents are reported to the CISO. Some of them are mitigated, and others are non-significant (for example, a ransomware attack over one PC, which is mitigated using restore and backup techniques). A more reasonable approach would be that if the incident is reported to the Board of Directors or equivalent, then, it may be considered as potentially significant, but again, even so, the incident could end up being insignificant. For example, a DDOS attack, occurring during the night, which is mitigated in 180 mins, , service downtime is greater than 2 hours but affects no customer at all.
To conclude: each PSP should be responsible to assess whether the criterion « high level of internal escalation » is reached according to its own risk policy.
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.
Template is quite well done elaborated in a manner close to what is currently used (when existing).Instructions are very complete. They illustrate that it will take time to fulfil this reporting template.
General comments
Articulation between this reporting and reporting planed by other regulation:
The template is prepared for the reporting of major incident in the DSP2 framework only. French banks wish to stress that for the same single incident, each PSP will have to make several notification to several authorities:
- majors incidents reporting required by DSP2 to their supervisory banking authority (ACPR),
- incidents regarding the breach of personal data to their data protection authority (CNIL),
- and regarding EU directive 2016/1148 of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union (the NIS directive) they should have to report this same incident if it has a significant impact on the continuity of the service given to the French Agency for the security of information systems (ANSSI). Notwithstanding other reporting required at national level.
We would like to prevent overburdening PSPs with new different notification requirements.
Preferably, authorities should accept the same reporting template (maybe with a different reporting frequency). Too many reporting will damage efficiency of the PSP. We consider that PSP should focus first to solve the incident rather than to provide several different reporting in a very short time. So, it is necessary to harmonized all types of incidents reporting.
The guidelines do not mention the confidentiality of the information provided to the competent authority. We believe that this sensitive information should be considered confidential. No request, for example by a journalist, should potentially lead to the disclosure of any of the information provided to the competent authority.
The template
- Formal comments:
1) A clearer distinction than an asterisk (*) should be made between data that are mandatories or optional. For example in the chapter”Incident discovery”, field “actual date and time of recovery of the incident, if applicable”: we think this information should be optional as it is specified “if applicable”.
2) It would be useful to homogenize the presentation: check boxes are sometimes on the right of the item (e.g. report detail line 2) and sometimes on the left (line 3 Type of report individual / consolidated): an option has to be chosen and kept regarding the all document.
3) Report details “What is the ETA for next update”: We suggest to avoid abbreviation: “ETA” should be replaced by “Estimated Time of arrival”.
- First notification: In the event of a major incident, primary focus in an organisation will be to fix the incident. Whilst the notification is of upmost importance, we feel the timeline should be extended. If this is not possible, shorter details should be given as a first notification in the two hour time window after the qualification of the incident as major, with further detail to follow on in the next stages of communication. The EBA could achieve this by using only the “1 – General Details” section of the major incident report under Annex 1. Companies would remain free to provide further detail in the first notification as they wish.
- Incident discovery: The « date and time of beginning of incident, if known» should be optional. Only the « date and time of detection of the incident » should be mandatory.
- Economic impact: It would be useful for the EBA to include a currency drop down box in the form for non-euro currencies. The reportable currency within the template, should also allow for the host currency of the Member State. i.e. UK = GBP
- Reputational impact should be replaced by “high reputational impact”.
- System failure This section should be split into separate categories, for example, software or hardware failure, to allow a greater level of understanding across PSPs.
- Incident Impact: There should be a measure of “staff impact” as this may affect the ability to maintain services, for example, security incidents such as a terrorist attack where staff are unable to travel or are directly at risk.
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.
We feel that some changes could be useful:1. It might be useful that each report be duly identified with a unique identification number, that needs to be specified by the Guidelines, (e.g. date and ID number, 2-1-2017/1, …), and that will be used as a unique reference for the incident reporting.
2. In the field “Economic impact”, “Indirect costs”: We do not understand the relevance and the objective of providing information on indirect costs to the national authority”. We feel only direct economic impact losses immediately determined should be reported in the template.
3. In the field “cause of incident”, in the “type of attack”, the choices “infection of internal systems” and “targeted intrusion” need more clarification and could be overlapping (e.g.: What choice should be made of a malware 0-day attack for stealing information?).
4. In the field “Systems and components affected”, it is suggested to also have “security infrastructure” as a choice (this would allow to include Hardware Security Modules used for authentication and transaction processing).
We further recommend including a support call center to clarify any doubts that may appear during the completion.
More explanation is needed to complete the template in case of “consolidated reporting”.
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.
General comments :1) Grading a “major” incident can take time. It is better to take time properly to describe the major incident and to make relevant statements rather than to notify in mass incidents which will be requalified afterwards like “non-major”. It is necessary to take into account of the criticality of the environment impacted by the incident. The reactivity level depends on the incident environment. An incident on a less critical environment doesn’t need the same reactivity than an incident on an environment which is more critical.
Moreover, the aim of these guidelines is “to assess the success of applicable law and to identify good practices across the market”. To achieve these aims, it is not necessary to ask for an initial notification “in two hours”. As there are no “operational objectives”, to help the PSP to solve the incident, this reporting is not an urgent matter. It would be more efficient and reasonable to report an incident when it is analysed and classified as “major”, to be sure to report a pertinent incident.
2) The second aim of this reporting is to respond to a need of “common approach in European Union”. We agree on a common approach which is useful and will allow statistical analysis and European best practice. To have a useful and efficient European reporting, it has to be limited on selected relevant incidents and then focus only on major incidents.
3) Finally, the Guidelines are “aimed at preventing PSP from being overburdened with reporting duties while responding to an incident as well as avoiding to create undue distortions between the smaller and the bigger players in the market”. By asking 3 reports (i.e initial, intermediate and final), during the life cycle of the incident, the Guidelines are conflicting with the aim written above (“aimed at preventing PSP from being overburdened”) because it will overburdened the PSP with reporting duties.
4) At a practical point of view, the only way to make a safe and quick reporting would be the EBA request from the national supervisory authorities to put in place an extranet website apps duly secured, that would insure a sharing of information respecting its confidentiality as its integrity specially regarding the risk of disclosure to not concerned parties or regarding exchanges within national others supervisory boards. For national authorities, statistical analysis would be easier with this tool than email sent by hundreds of PSP. For French banks, the security issues raise by the notification of the incident is a key topic. It is really necessary to have a deeply secured gateway, protected by strict access conditions (qualified certificate) to reserve access only to people duly authorized.
Initial report
Initial report should be done from the moment when the PSP has qualified the incident as “major” and must be reported ASAP (as soon as possible). PSP should do its best effort to declare the major incident the same day when the incident is classified as major. 2H delay from the moment the incident was detected as such is too short. EBA has at least to take into account working days, the time of the incident (during the night or the day).
In the course of processing, the reporting cannot be made within too short lead times except penalizing the processing of the incident.
We would like to point that article 33 of regulation 2016/679 of the European parliament and of the council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, indicates that the notification of a personal data breach to the supervisory authority shall be done without undue delay and, where feasible, not later than 72 hours after having become aware of it and that where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay. We request that at least, times to report provided by the different regulation are the same.
In any case, the two hours deadline is to short, considering internal escalation procedures within the PSP or within the Group it belongs.
We request a 24h delay (business day) starting from the moment the incident is qualified by the PSP as “major” to declare it (instead of 2H delay).
Intermediate report
We think that intermediate reports are not necessary for national authority analysis. Reporting would be heavy to make and requires, especially within large PSP. « Intermediary report with a maximum limit of 3 days » is burdensome and could delay the management of the incident itself. EBA should have in mind that this kind of notification doesn’t exist in France yet and must be implemented from scratch. Therefore, there are resources issues to manage (IT and human resources).
The only way to make a safe and quick intermediate reporting would be the EBA allows to make the declaration of the incident via an extranet website or a dedicated application.
Final report
End date of a major incident: when the incident is no more considered as a major incident by PSPs because the incident is under the control of the PSP, banks expect than they can stop the reporting even if the business is not fully deemed back to normal.
As a conclusion, on the reporting, we request the following alternative proposals:
- Regarding the initial report, we request a 24h delay (business day) starting from the moment the incident is qualified by the PSP as “major” to declare it (instead of 2H delay).
- An highly secured dedicated extranet solution is requested to have a secured sharing solution (better than exchanges via secured email or secured on line document system (p 15, part 37)
- Only two reports (initial and final); intermediary report only on demand of the supervisory authority).
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.
We welcome the capability opened by the Guidelines to delegate reporting obligations to a third party.Nevertheless, the requirement consisting in informing the competent authority in the home Member State before the delegation of the reporting obligations does not seem relevant in the context of an ongoing pre contractual deal. 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 suggest to delete this requirement. We agree with the request to inform the Authority but after the signature of the contractual agreement.
We understand that, if a third party manages, for example, a payment processing platform used by several PSPs of a banking Group, the third party processing the platform could declare a major incident on its platform.
So it would provide PSPs (clients of this third party) an added value, if the declaration would be, as we understand:
-made by the operator of the platform at a global level, if all PSPs affected in the same manner (or by each affected PSP, if they are not affected in the same way).
- and based on consolidated thresholds for all PSPs affected with a global declaration to each of the competent national authority concerned.
in each case “banking PSPs group” by “banking PSPs group”.
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.
We would welcome clarifications from the EBA on the concept of “consolidated reporting”. We would like EBA to better illustrate the opportunities opened up by the consolidated reporting procedure, specifically by giving examples of situations in which a consolidated report may be issued.Consolidated reporting procedure would be 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 be considered major for only one entity, without significantly impacting or endangering the entire group.
We understand that if a PSP’s common technical service provider manages, for example, a payment processing platform used by several PSPs, the PSP’s common technical service provider could declare a major incident on its platform as explained in rationale 28 and 29. (Guidelines article 3.2)
It would give PSPs an added value, if the declaration would be, as we understand:
-made by the PSP’s common technical service provider at a global level, if all PSPs are affected in the same manner (or by each affected PSP, if they are not affected in the same way).
-and based on the mandate received from PSPs and, regarding this mandate, sometimes based on consolidated thresholds with a consolidated declaration to each of the national competent authority.
We understand that such a report could be issued by a payment scheme or CSM when affected by a technical failure with repercussions on several participant PSPs. Indeed, in this case, it might be more efficient to provide the EBA with one consolidated report from the scheme rather than with several identical reports from individual PSPs.
Suggestions:
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 question why 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 capability of issuing consolidated reports for the whole group, even if the incident was not caused by a failure of the technical services provider.
Similarly, we fail to understand why consolidation should be limited to PSPs established in the same Member State. We feel that this would go against the harmonisation of the European market, in addition to being impractical for PSPs established in several Member States.