Response to consultation on Guidelines on major incidents reporting under PSD2
Go back
The current definitions are not 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. Maybe the term “continuity” should be replaced by “recovery”, which is the term more generally used. A quick recovery will lead to a short period of unavailability.
The usage of the word “event” in the definition of “major operational or security incident” on page 21 should be further explained. Is the definition of an “event” equal to the definition used by the BIS for an “operational risk incident”?
In the definition of “Major operational or security incident” it is proposed to delete the wording “may have” given that this is very subjective. In our opinion only materialised incidents should be reported and not vulnerabilities that potentially may have impact.
Moreover, the guidelines themselves (on page 21) should comprehensively define and explain the concepts used (to define the methodology, criteria and thresholds) some of which are currently covered in the rationale section only.
Please add a definition of “crisis mode or equivalent” as used in Table 1 on page 26.
The EPC believes that what could provide added value to the market would be that information on incidents was not only reported from financial institutions to supervisors and regulators, but also shared with other financial institutions on a confidential basis. This act of sharing information or distribute early warnings on major incidents between financial institutions would increase information intelligence within the other financial institutions, which would allow them to take pro-active measures to avoid or prevent those or similar incidents. For example, if another financial institution is under a DDOS or a phishing campaign, other financial institutions would like to know the attack vectors and who is attacking that institution so as to become proactive in case they are the next in the line. However, because PSPs cannot formally share all relevant incident information, it prevents them from having a more collective pro-active approach with respect to risk and fraud management and protecting their customers.
The EPC understands the need to report incidents to the relevant competent authority, but also is seeing an increase in demand on PSPs to report the same type of incidents to the different regulators which is going to increase the burden for all PSPs (being large or small PSPs). There is definitely a need for harmonisation and a one-stop-shop mechanism for incident reporting to all relevant authorities and regulators (including overseers of payment schemes and instruments) regarding regulations impacting payments (PSD2, GDPR, eIDAS, etc.). The guidelines should make clear to the competent authorities in the Member States that the guidelines should replace similar reporting requirements from these authorities. Moreover the reporting process and tools used in the different Member States should be streamlined and made consistent.
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. The EPC would like to suggest to develop a separate dedicated table for this type of incidents.
Therefore we suggest using two different threshold matrices: one for incidents related to availability / continuity of the payment related service and one for incidents related to integrity, confidentiality and authenticity.
It is unclear why EBA decided in the 2nd column – Level 2 to leave the entries void for the criteria “Other PSPs or relevant infrastructures potentially affected” and “Reputational risk”. Our interpretation is, that these two criteria themselves are never sufficient to classify an incident as a major incident. If this interpretation is correct, we request EBA to clarify this in the guidelines or provide an alternative explanation.
The criteria mentioned do not make a distinction between large and small PSPs. We assume that the percentages for “transactions affected” can be relevant for PSPs with a low number of customers and/or a limited number of transactions numbers / low total of transactions amount. However, for large PSPs the numbers and amounts mentioned are too low - we advise to increase the limits of the absolute amounts / numbers (see also response to Question 4).
Corporate clients tend to generate much higher transaction amounts. Currently these clients are not separated in Table 1, there is however need to define different criteria for those.
Some criteria being not applicable on AISPs (e.g., transactions affected), it might be appropriate to define a special threshold matrix for those (e.g., including loss of data).
It is further to be noted that reputational and economic costs (mainly indirect) are hard to estimate in most of the cases (see also response to Question 4).
Another point of attention is the case of an external event which is leading to an incident; what are the reporting requirements for such incidents (e.g., as 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. However, the question is: are intermediate and final reports required if the root cause lies outside the PSP’s circle of influence?
A payment chain consists of different stakeholders including customers, TPPs and ASPSPs. An incident might affect a TPP and that incident can potentially require reporting by the TPP to the competent authority. However, there should also be information sharing on major incidents at TPPs towards the ASPSPs concerned. It is suggested that this would be done by the regulators 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. This information sharing may include the following topics:
• Identification data /credentials were stolen;
• Clients behaved fraudulently;
• Customer data violation;
• The incident is the result of fraud.
The data sharing amongst European and / or National Authorities / PSPS should be made under the appliance of reciprocal rules of confidentiality and privacy.
The narrative around reputational impact on page 25 gives lots of examples of what could be considered reputational impact but does not give any recognition that reputational impact is not binary. The narrative refers to national media coverage but does not recognise the differing nature and corresponding gravitas attached to different coverage: for example national media coverage is very different to a blog article.
Likewise in point g. ii) “security credential compromised” (on page 25), it is unclear if any consumer social engineering attack where individual authentication is compromised would meet the reputational impact trigger.
On “transactions affected”: This is measured in value and volume of transactions. Is value to be considered the value of financial loss (e.g. a fraud / cyber theft event) or the value of genuine payment traffic that is impacted by a security incident? If the former, we believe the values are broadly OK but the values would be too low if it relates to genuine payment value. For genuine payments only a small delay or block period could easily exceed the $1MM threshold.
On “economic impact”: the economic impact to a large financial institution is not the same as the impact to a small institution.
On “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 which is mitigated in 180 mins occurring during the night (service downtime is greater than 2 hours) and which affects only a few customers.
There is no clarity for clients affected. For examples, if a payment application was put down, it is unclear what rules would apply for calculating the number of clients affected. It might be all clients that potentially have access to an application, or the number of clients whose transactions failed because they could not access the application, etc. Furthermore it is not clear whether the percentage refers to (a). All clients of the PSP, (b). All clients potentially using the affected payment service or (c). All clients usually using the affected payment service at the time of the incident.
The EPC would like to suggest to align the thresholds with the thresholds of other regulations, e.g. Economic Impact > 25.000.000. (according to the Single Supervisory Mechanism). In addition, for “Transactions affected” it is suggested to do the calculation by type of service. Change “the daily annual average of payment transactions for all the payment services executed” into “the daily annual average of payment transactions for the affected payment service”.
Moreover, it is strongly suggested not to use absolute amounts for “transactions affected” but only to consider percentages. As an example, transaction amounts involved with operational incidents at a PSP may be high, although it does not imply significant losses or decrease of service to the customers of the PSP.
In the template, it should be possible to leave topics uncommented. Confidentiality related incidents can also lead to the requirement to report these to the local privacy authority. Preferably, both authorities should accept the same reporting information (maybe with a different reporting frequency).
Further clarification is required what EBA means with “Other PSPs or relevant infrastructures potentially affected”. It is clear in our opinion that some incidents affecting one PSP should be shared with other PSPs: they could potentially experience the same attack now or in the near future (see also response to question 2). However, we believe that such information is not meant here. Even in the case when an attack can (potentially) directly impact other PSPs, it should be reported here.
The guidelines do not mention the confidentiality of the information provided to the competent authority. We believe that the 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.
A more clear distinction should also be made between data that is mandatory to be reported and data which is optionally reported.
1. It might be useful for each report to have an ID, provided by the PSP (e.g. date and ID number, 2-1-2017/1, version number) to be used as a reference for the intermediate and final reports of each incident.
2. In the field “Incident status”, the “repair” and “restoration” choices need more clarification.
3. In the field “Economic impact”, “Indirect costs” are several times difficult to be estimated.
4. 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 for a malware 0-day attack for stealing information).
5. 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.
6. The field “Did the PSP had to cancel….” needs more clarification.
7. Does the field “Was a civil complaint filed against the PSP” also include legal actions against the PSP before the customer goes to a court?
8. Introduce a box in the template to indicate whether the numbers are estimates or measured values.
We further recommend to include a support line or email to clarify any doubts that may appear during the completion.
More explanation is needed with respect to completing the template in case of “consolidated reporting”.
If EBA agrees on the reporting of “Other PSPs or relevant infrastructures potentially affected” (see response to Question 5), this should be made clear in the instructions as well.
The experience of our members shows that investigations for major incidents might be very complex (e.g. forensic analyses of major incidents usually require more than two weeks) and numbers for direct and indirect impact may be hard to calculate in a couple of weeks. Therefore the proposed two weeks for the final report is definitely too short.
In the guidelines on page 27, item 2.7 mentions “initial report” while clauses 2.8 and 2.9 use the wording “initial notification”. We assume that also the initial report is meant. Please use the same terminology across the guidelines.
The EPC acknowledges that in some circumstances individual PSPs will have a better understanding of the impact of an incident and will therefore be better placed to quantify it. Moreover, the PSP is responsible towards the competent authority, even if the reporting is made by a third party.
Having said that, as the EBA stressed in the Rationale section of the Consultation Paper (paragraph 28), ’’practical experience shows that the delegation of reporting obligations is commonly used by groups of payment service providers (be they legally defined ‘groups’ or not)’’. Indeed, the delegated reporting under Guideline 3, is a reasonable and useful option to be specially considered in the framework of some banking models where one or more credit institutions are permanently affiliated to a central body. However, the concept of a ‘third party’ in the context of the proposed Guidelines should not include entities that are part of the same ‘group’ (be they legal groups or not).
Question 1: Do you consider the definitions included in the draft Guidelines to be sufficiently clear?
The EPC would strongly advise that EBA adopts definitions from international organisations such ISO, BIS or ENISA which are already widely used in the industry and as used in related regulations (e.g. GDPR, NIS Directive, eIDAS).The current definitions are not 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. Maybe the term “continuity” should be replaced by “recovery”, which is the term more generally used. A quick recovery will lead to a short period of unavailability.
The usage of the word “event” in the definition of “major operational or security incident” on page 21 should be further explained. Is the definition of an “event” equal to the definition used by the BIS for an “operational risk incident”?
In the definition of “Major operational or security incident” it is proposed to delete the wording “may have” given that this is very subjective. In our opinion only materialised incidents should be reported and not vulnerabilities that potentially may have impact.
Moreover, the guidelines themselves (on page 21) should comprehensively define and explain the concepts used (to define the methodology, criteria and thresholds) some of which are currently covered in the rationale section only.
Please add a definition of “crisis mode or equivalent” as used in Table 1 on page 26.
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?
No, please see the comments and requests for further clarifications below.The EPC believes that what could provide added value to the market would be that information on incidents was not only reported from financial institutions to supervisors and regulators, but also shared with other financial institutions on a confidential basis. This act of sharing information or distribute early warnings on major incidents between financial institutions would increase information intelligence within the other financial institutions, which would allow them to take pro-active measures to avoid or prevent those or similar incidents. For example, if another financial institution is under a DDOS or a phishing campaign, other financial institutions would like to know the attack vectors and who is attacking that institution so as to become proactive in case they are the next in the line. However, because PSPs cannot formally share all relevant incident information, it prevents them from having a more collective pro-active approach with respect to risk and fraud management and protecting their customers.
The EPC understands the need to report incidents to the relevant competent authority, but also is seeing an increase in demand on PSPs to report the same type of incidents to the different regulators which is going to increase the burden for all PSPs (being large or small PSPs). There is definitely a need for harmonisation and a one-stop-shop mechanism for incident reporting to all relevant authorities and regulators (including overseers of payment schemes and instruments) regarding regulations impacting payments (PSD2, GDPR, eIDAS, etc.). The guidelines should make clear to the competent authorities in the Member States that the guidelines should replace similar reporting requirements from these authorities. Moreover the reporting process and tools used in the different Member States should be streamlined and made consistent.
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. The EPC would like to suggest to develop a separate dedicated table for this type of incidents.
Therefore we suggest using two different threshold matrices: one for incidents related to availability / continuity of the payment related service and one for incidents related to integrity, confidentiality and authenticity.
It is unclear why EBA decided in the 2nd column – Level 2 to leave the entries void for the criteria “Other PSPs or relevant infrastructures potentially affected” and “Reputational risk”. Our interpretation is, that these two criteria themselves are never sufficient to classify an incident as a major incident. If this interpretation is correct, we request EBA to clarify this in the guidelines or provide an alternative explanation.
The criteria mentioned do not make a distinction between large and small PSPs. We assume that the percentages for “transactions affected” can be relevant for PSPs with a low number of customers and/or a limited number of transactions numbers / low total of transactions amount. However, for large PSPs the numbers and amounts mentioned are too low - we advise to increase the limits of the absolute amounts / numbers (see also response to Question 4).
Corporate clients tend to generate much higher transaction amounts. Currently these clients are not separated in Table 1, there is however need to define different criteria for those.
Some criteria being not applicable on AISPs (e.g., transactions affected), it might be appropriate to define a special threshold matrix for those (e.g., including loss of data).
It is further to be noted that reputational and economic costs (mainly indirect) are hard to estimate in most of the cases (see also response to Question 4).
Another point of attention is the case of an external event which is leading to an incident; what are the reporting requirements for such incidents (e.g., as 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. However, the question is: are intermediate and final reports required if the root cause lies outside the PSP’s circle of influence?
A payment chain consists of different stakeholders including customers, TPPs and ASPSPs. An incident might affect a TPP and that incident can potentially require reporting by the TPP to the competent authority. However, there should also be information sharing on major incidents at TPPs towards the ASPSPs concerned. It is suggested that this would be done by the regulators 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. This information sharing may include the following topics:
• Identification data /credentials were stolen;
• Clients behaved fraudulently;
• Customer data violation;
• The incident is the result of fraud.
The data sharing amongst European and / or National Authorities / PSPS should be made under the appliance of reciprocal rules of confidentiality and privacy.
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.
The EPC members believe that the high level criteria will lead to significantly more reporting of incidents compared to what is considered major today, more in particular related to operational incidents. Some thresholds might need to be revisited for large PSPs to result in the reporting of truly major incidents rather than getting involved in “business as usual” incident reporting and investigation.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.
In our opinion the quantitative criteria are not sufficiently explained in order to determine the operational risk. A “yes/no” answer is not sufficient to measure this; for example a reputational risk will, although it may be low, always result in a “yes” answer.The narrative around reputational impact on page 25 gives lots of examples of what could be considered reputational impact but does not give any recognition that reputational impact is not binary. The narrative refers to national media coverage but does not recognise the differing nature and corresponding gravitas attached to different coverage: for example national media coverage is very different to a blog article.
Likewise in point g. ii) “security credential compromised” (on page 25), it is unclear if any consumer social engineering attack where individual authentication is compromised would meet the reputational impact trigger.
On “transactions affected”: This is measured in value and volume of transactions. Is value to be considered the value of financial loss (e.g. a fraud / cyber theft event) or the value of genuine payment traffic that is impacted by a security incident? If the former, we believe the values are broadly OK but the values would be too low if it relates to genuine payment value. For genuine payments only a small delay or block period could easily exceed the $1MM threshold.
On “economic impact”: the economic impact to a large financial institution is not the same as the impact to a small institution.
On “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 which is mitigated in 180 mins occurring during the night (service downtime is greater than 2 hours) and which affects only a few customers.
There is no clarity for clients affected. For examples, if a payment application was put down, it is unclear what rules would apply for calculating the number of clients affected. It might be all clients that potentially have access to an application, or the number of clients whose transactions failed because they could not access the application, etc. Furthermore it is not clear whether the percentage refers to (a). All clients of the PSP, (b). All clients potentially using the affected payment service or (c). All clients usually using the affected payment service at the time of the incident.
The EPC would like to suggest to align the thresholds with the thresholds of other regulations, e.g. Economic Impact > 25.000.000. (according to the Single Supervisory Mechanism). In addition, for “Transactions affected” it is suggested to do the calculation by type of service. Change “the daily annual average of payment transactions for all the payment services executed” into “the daily annual average of payment transactions for the affected payment service”.
Moreover, it is strongly suggested not to use absolute amounts for “transactions affected” but only to consider percentages. As an example, transaction amounts involved with operational incidents at a PSP may be high, although it does not imply significant losses or decrease of service to the customers of the PSP.
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.
Has the EBA taken into account the impact of additional notification requirements for incidents that also meet the criteria of the GDPR in case of a data breach? We would like to prevent overburdening PSPs with different notification requirements.In the template, it should be possible to leave topics uncommented. Confidentiality related incidents can also lead to the requirement to report these to the local privacy authority. Preferably, both authorities should accept the same reporting information (maybe with a different reporting frequency).
Further clarification is required what EBA means with “Other PSPs or relevant infrastructures potentially affected”. It is clear in our opinion that some incidents affecting one PSP should be shared with other PSPs: they could potentially experience the same attack now or in the near future (see also response to question 2). However, we believe that such information is not meant here. Even in the case when an attack can (potentially) directly impact other PSPs, it should be reported here.
The guidelines do not mention the confidentiality of the information provided to the competent authority. We believe that the 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.
A more clear distinction should also be made between data that is mandatory to be reported and data which is optionally reported.
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.
Yes they are, but some changes could be useful as follows:1. It might be useful for each report to have an ID, provided by the PSP (e.g. date and ID number, 2-1-2017/1, version number) to be used as a reference for the intermediate and final reports of each incident.
2. In the field “Incident status”, the “repair” and “restoration” choices need more clarification.
3. In the field “Economic impact”, “Indirect costs” are several times difficult to be estimated.
4. 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 for a malware 0-day attack for stealing information).
5. 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.
6. The field “Did the PSP had to cancel….” needs more clarification.
7. Does the field “Was a civil complaint filed against the PSP” also include legal actions against the PSP before the customer goes to a court?
8. Introduce a box in the template to indicate whether the numbers are estimates or measured values.
We further recommend to include a support line or email to clarify any doubts that may appear during the completion.
More explanation is needed with respect to completing the template in case of “consolidated reporting”.
If EBA agrees on the reporting of “Other PSPs or relevant infrastructures potentially affected” (see response to Question 5), this should be made clear in the instructions as well.
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.
The EPC members believe the requirement for the first report to be issued within 2 hours of identification to be unrealistic and whilst it may be warranted for very major incidents the thresholds provided go to a much lower level. We believe a timeline of within 12-24 hours to be more realistic, since resources will have as priority to contain the incident. Regarding the intermediate report that should not go beyond 5 to 8 days: we believe this is would be a reasonable approach but we disagree with the requirement for “intermediate reports every time they consider there is a relevant status update” (2.11). Instead we suggest a requirement to update max every 5 to 8 days unless there is a material increase in exposure to be more reasonable.The experience of our members shows that investigations for major incidents might be very complex (e.g. forensic analyses of major incidents usually require more than two weeks) and numbers for direct and indirect impact may be hard to calculate in a couple of weeks. Therefore the proposed two weeks for the final report is definitely too short.
In the guidelines on page 27, item 2.7 mentions “initial report” while clauses 2.8 and 2.9 use the wording “initial notification”. We assume that also the initial report is meant. Please use the same terminology across the guidelines.
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.
It will provide added value for small PSPs or for PSPs having outsourced services but not for those that have a CERT (Computer Emergency Response Team) in place, working 24x7 in different countries around the world.The EPC acknowledges that in some circumstances individual PSPs will have a better understanding of the impact of an incident and will therefore be better placed to quantify it. Moreover, the PSP is responsible towards the competent authority, even if the reporting is made by a third party.
Having said that, as the EBA stressed in the Rationale section of the Consultation Paper (paragraph 28), ’’practical experience shows that the delegation of reporting obligations is commonly used by groups of payment service providers (be they legally defined ‘groups’ or not)’’. Indeed, the delegated reporting under Guideline 3, is a reasonable and useful option to be specially considered in the framework of some banking models where one or more credit institutions are permanently affiliated to a central body. However, the concept of a ‘third party’ in the context of the proposed Guidelines should not include entities that are part of the same ‘group’ (be they legal groups or not).