Response to consultation on Guidelines on major incidents reporting under PSD2
Go back
• Definition of incident: There appears to be a mismatch in the definition of incident. In the Guidelines (page 21, paragraph 13) it specifies “Payment Related services” but in the Rationale (page 7, paragraph 13) it states incidents affecting transactions, processes, data or funds". We would welcome clarification from the EBA as to whether any incident impacting a non-payment service would need to be reported. Our assumption is that non-payment related incidents and planned system outages are deemed out of scope of PSD2 reporting to Competent Authorities. Additionally, we would welcome clarity on whether an impact to customer payments in the event of an external incident (i.e. security, national disaster), would be classed as a ‘reportable’ incident. Under these guidelines the scope should be explicitly defined to include out of scope incidents.
• Incident classification: In terms of reporting major incidents that could impact payment services provided to Third Party Providers by firms and in absence of any contractual obligations (as stated under the directive), perhaps Incident Classification section within the template (Annex 1) could somehow reference this, if needed?
• A more detailed definition would be welcomed for the terms 'domestic authorities' with some examples.
• Scope of Reporting: Could the EBA provide clarity in terms of whether there is any cross-over with the scope and reporting timelines of other regulatory/legislative requirements such as the GDPR requirements? We would appreciate the EBA views on this."
Assessment of Major Incident:
It is implied in the guidelines that an incident is ranked as major when a certain number of the thresholds are reached or exceeded. It is not clear from the definitions as to whether the thresholds must actually be exceeded before the incident is classified as a major incident, or whether incidents should be classified as major if there is a potential that thresholds may be exceeded. Based upon the size of the organization different thresholds may be appropriate. Sometimes an incident which starts as major ends up becoming minor or totally mitigated.
Table 1: Thresholds (page 25)
1. Transactions Affected
(a) Level 1 states: >10% of the payment service provider’s regular level of transactions and >EUR 100,000
Level 2 states: 25% of the payment service provider’s regular level of transactions OR
>EUR 1,000,000
This should be AND for Both scenarios.
A transaction of €1,000,000 particularly in the context of correspondent banking could be reached very easily and relate possibly to only one transaction and shouldn’t warrant a report.
(b) Greater clarity is required as to what constitutes “percentage of the regular level of payment transactions carried out”.
Does this mean transactions of the same type or product, or the overall level of payment transactions? e.g. mobile payments are impacted by an issue
Is the threshold calculated on the basis of the percentage of a payment service provider’s regular level of mobile payments or all payments?
2. Clients Affected: Depending on the individual interpretation of the guidance this could result in very different numbers which could make comparison across different organisations/incidents meaningless. We assume that those in scope would be all clients within the scope of PSD2 under ‘payments service user’, with other financial institutions out of scope.
3. Transactions/Clients impacted: Further clarity may be required by firms as to whether this is 10% or 25% of
(a) the total client base
(b) total number of payment transactions
(c) the client base using the specific payment service that is impacted, or
(d) the transactions processed by the impacted payment service.
4. Thresholds levels Indicators: It would generally be assumed by firms that level 1 incidents are the highest priority incidents and therefore we would recommend that the level 1/level 2 indicators are swapped, so that the Level (1) measures are the highest standards of reporting and Level (2) the lower level.
5. Service Downtime:
The proposed service downtime criteria of 2 hours is very short. At what point is the service downtime deemed to have started? Is this at the point that an initial alert is received or at the point when investigation has determined that there is a system issue?
Often it is not possible to determine how many clients may be impacted etc. Does the analysis need to be completed within the 2 hour window? This would be very short, as sometimes it could take up to a week to determine how major an incident may be.
It is important to note in considering time-frames that certain online/mobile services are available 24 hours a day, therefore the time-frame within which the service is down is relevant in the reporting of an incident.
Does this same criteria applies to partial system outages, e.g. if the system is operational but with reduced functionality or where functionality can be carried out in alternative locations, or on alternative systems to process a payment. For example, a payments system incident has the potential impact that a significant volume of same day payments may not be processed if the incident is not resolved before payment cut off times, however the impact may not materialise if the system is recovered ahead of payment cut-off times. We would welcome further clarification around service downtime and what constitutes ‘service not available’, for example, where there are multiple channels and services.
It should be noted that the current CBI Major Operational Risk Reporting criteria allows a 4 hour window for system outages.
6. Internal Level of Escalation:
We believe that a “high level of internal escalation” is not an appropriate trigger point for reporting to regulators under the guidelines. It can be very subjective and therefore is likely to lead to inconsistent reporting across payment service providers and indeed the EU. Perhaps, more clarity could be included to make the classifications less open to interpretation, for example the seniority of the CIO may vary per firm therefore should be clearer on the level of visibility of escalation expected to be reached within the organisation?
A possible alternative is Payment Service Providers should determine whether this incident has required direct input from their CIO/COO or Executive officers in the decision making process relating to the incident.
Many institutions maintain robust internal procedures which necessitate escalation of incidents internally, but they would not necessarily require reporting to external authorities.
7. Incident Notification: 3 Implementation: Guideline 2 Notification Process 2.7 & 2.8 - Perhaps the guidance could stipulate that notification should take place when an incident, deemed to be major, is first detected. For reclassified incidents, do the same criteria apply (e.g. impact figures and timing)?
8. Delegated Reporting: 3.1 - We assume this refers to the European Union.
It is recommended that higher thresholds should be defined for a near miss of the threshold (where there is a potential for thresholds to be breached) and if these are required to be reported.
9. Reputational Impact: We consider this to be very subjective and would welcome greater clarity in the guidelines on this topic.
We acknowledge the objectives of the EBA in relation to the draft guidelines which as stated throughout the paper is to ensure the harmonisation of incident classification, reporting and escalation across the EU.
The guidelines outline on page 9 (3.2.19) that the “thresholds mainly echo current practices …carried out across supervisors and overseers and take into account the experience gained by the ECB as a result of the pilot exercise on cyber-security incident reporting”. At a practical level however, we believe that the current proposed guidelines would in an Irish context lead to more duplication and fragmentation rather than harmonisation of reporting of Major Operational Risk Incidents.
This can be demonstrated through the variety of existing obligations particularly for large PSPs which may also touch point the proposed PSD2 guidelines e.g. members’ who are currently subject to the Central Bank of Ireland Major Operational Risk Incident Reporting obligations, the ECB Security Reporting Obligations, NIS Reporting Obligations, and Data Protection Reporting requirements.
It is important to note, for example, that the thresholds and time-frames contained within these requirements are not aligned with those proposed under PSD2. In particular, the time-frame for notifying the regulatory authorities of an incident under the Central Bank of Ireland Major Operational Risk obligations is currently 24 hours, for PSD2 initial reporting time-frame is 2 hours.
The methodology seems to be aligned with ECB pilot of cyber incidents. The scope seems to be larger as all types of incidents are included under the PSD2 scope. We think more incidents will be captured based on:
• “Service Downtime”
• Prescriptive nature of the thresholds
• If there is no discretion allowed
With regard to proportionality, for entities with a small number of customers the criteria may bring a disproportionate burden on these firms. What is deemed major by one firm may be out of line with other firms and may be unnecessarily bringing incidents to the attention of the competent authorities.
Whilst the criticality guidelines some firms operate internally are not exactly the same as the proposed thresholds, the methodology for determining a major incident is in line with these firms’ definition of a criticality 1 incident. The proposed guidelines will lead to increased reporting, however, due to the following:
The value threshold for transactions to trigger a level 2 major incident seems very low. One large corporate payment can easily be in excess of this amount and this could lead to an increased number of incidents being reported if a single payment incident can trigger the major incident classification. Firms would typically rate impact based on actual or potential financial impact, not on transaction value. For example, if a €1bn payment is late, then the financial impact of the incident would be, for example, the interest, fees or compensation associated with the late payment, not the actual value of the payment. It would be helpful for values to be completed for both levels of each threshold.
Reputational impact is very subjective and some guidance would be required here. With reputational impact you could argue that a number of other thresholds have already been breached and there is a double count for example:
• Large number of customers affected
• Other PSP or relevant infrastructures potentially affected
• COO/CIO directly affected
The thresholds expressed in percentage seem adequate, the others might lead to an over reporting of incidents by the larger institutions. As most of the minor incident could reach the thresholds despite affecting a small number of transactions or clients in relative terms. However the value threshold of €1,000,000 to trigger a level 2 major incident seams very low. We would propose that this threshold and the % of clients affected and service downtime outlined in Level 1 and Level 2 be increased.
Service downtime: The two hour threshold is a short period of time for an outage and we feel this should be longer with the time of day also taken into consideration. There should also be recognition that different services/systems present different levels of impact if taken out of service. For example, a four hour outage of a system that processes direct debits has a lower impact on customers than a four hour outage to debit card or instant payment systems.
Reporting to the CISO might be a problem as most CISO would like all incidents to be reported to them. Some of them are mitigated, and others are of no significance.
Although the volume of information specified is reasonable for later reports, this volume is onerous for an initial report (2 hours) and will be difficult to ensure completeness especially in relation to section 6. Clarity is required on the following:
• Is it that you only complete the information you have to hand in the initial report and then in subsequent reports expand on that as information is available?
• Will CBI Trigger reporting templates be aligned to the proposed report in Annex 1 to ensure multiple reports do not have to be completed for the same incident?
Perhaps the reporting process would benefit from a separate short form" incident template version which could be used for the initial escalation within 2 hours. This would allow payment providers to focus on rectifying the solution rather than trying to complete as much of the full form as possible
However, our preference would be to retain the current time-frame for notifying the regulatory authorities of an incident under the CBI Major Operational Risk obligations which allows a 4 hour window for system outages with 24 hour reporting.
Incident Impact: There should be a measure of staff impact as this may affect the ability to maintain services. For example a security incident such as a terrorist attack where staff are unable to travel or are directly at risk.
Incident Classification: For 'Reputational' - this appears to be very subjective and response will be dependent on Author. Explicit questions should be included. As an example some firms may state that the incident could impact the PSP's share price.
Cause of Incident: Attack Type: This does not seem to be a complete list e.g. malware attack is missing (e.g. external system infected as in most attacks against online banking systems).
Suggested additional Information: Has the security incident (in the context of payment service impact e.g. DDOS) been reported to law enforcement / other agencies?
Further Guidance in terms of reporting Economic impact would be welcomed. The Economic impact is typically dependent upon and determined on the nature of an incident. Dependent upon the incident, firms won’t necessarily notify on direct or indirect costs to Competent Authorities, however, the overall Economic Impact of a Major Incident, would be dependent on the nature of those costs. For example, firms would advise the financial impacts to its customers and any direct/indirect costs associated with the remediation and redress activity, including a total value and average amount of redress paid. We would welcome further clarity via the EBA surrounding this."
It seems detailed. How it works in practice may need to be tested.
Some of the very specific requests e.g. Start of incident" may be difficult for firms to confirm. The EBA should accept reasonable estimated times, based on investigation and internal/external intelligence, where exact start time of an Incident cannot be confirmed."
We recommend that clarity is included within the guidelines to fully explain what is meant by 'the incident discovery point' in direct relation to the incident cycle, for example:
a) From the moment the incident was first detected for example through an incident alerting process. At this time, investigation and assessment would be required to determine the nature of the incident alert and the impact of the issue, including whether it meets major status. This investigation will reasonably take a period of time to conclude depending on the nature of the incident; or
b) From the moment the incident was assessed or reclassified as a Major Incident.
Initial Reporting:
The initial reporting period of two hours is extremely onerous as the first two hours are the most critical after an incident, and the information that can be gathered and collated in the 2 hours will be basic. It takes time to analyse an incident and determine its materiality particularly against the 8 detailed criteria as set out in the proposed guidelines. We would suggest the General Details Section only should be completed in the initial notification and reported to the competent authority.
However, our preference would be to retain the current time-frame for notifying the regulatory authorities of an incident under the CBI Major Operational Risk obligations which allows a 4 hour window for system outages with 24 hour reporting.
Intermediate Reporting:
Again there may be limited information but ongoing actions will enable sight of a plan in place for investigation and recovery. Is it required to send a report every 3 days until the issue is resolved? This may be excessive.
Final Reporting:
The full report should be sent within two weeks of recovery and back to normal". However, it may not always be possible to determine root cause within this period, for example, if the firms needs to carry out forensic analysis following a complex cyber-attack, or detailed diagnostics are required by a 3rd party supplier to assess a hardware failure. It is recommended that an indication of when the final report would be available is provided when the final interim report is completed.
We would also like to expressly point out that the final report time-frames should not necessitate any restitution/refunds to be carried out in this period. The final report time-frame should relate to the rectification and resolution of the issue.
Classification triggers:
We are of the opinion that these seem low, if trigger is hit, does that automatically mean we have to notify the incident to the Competent authority (even if a firm have mitigation/fix in place)?
If all incidents that meet the triggers are notifiable to Competent authorities, (irrespective of whether any impact is felt or not), then this effectively would generate a new class of ‘notification’ and it would be beneficial if the EBA could clarify this.
Should the EBA wish to have the information on all ‘bumps’ in the payments road, these will result in additional work for firms to complete the notification template, updates and final reports.
Overall it is unclear what they will use this information for, and what will be gained by sight of incidents which do not result in any customer impact.
In addition this will result in a larger volume of notifications being made to Regulators, which do not currently meet our reporting criteria (impact and proportionality being key criteria for these)."
We understand that the information provided will be anonymised by the competent authority when being shared with other domestic authorities (ref 6.3, p33), however, in reference to Section 35 (p15), we would like to understand what is in place to ensure the confidentiality and/or intellectual property rights are upheld and anonymised?
In jurisdictions where this option is presently a common practice, it has proved useful for reducing the reporting burden on small payment service providers (in particular when they rely on the technical services provided by external parties).
In circumstances where consolidated reporting is feasible/permitted this would make reporting more efficient by being able to fill out one single report and specifying in the dedicated table of the template the list of the impacted parties.
We believe that to be able to truly get value from this we should also be able to share this information with other financial institutions. The sharing of knowledge between financial institutions would increase the chance to fight off any attack or resolve incidents fast and efficiently.
By letting other PSPs know of a DDOS attack, they are able to prepare themselves against similar attacks e.g. ask us what we did to mitigate the attack, what worked and what did not work.
Giving an immediate overview of an incident across a number of PSPs will benefit the competent authorities forming a view on its criticality to consumers. It will also reduce the number of individual reports from firms.
ADDITIONAL COMMENTS
We would welcome clarity on the following point:
Scope of Application: 10 (Page20): “These draft guidelines apply also where the major operational or security incident originates outside the Union ….and affects, either directly or indirectly the payment services provider located within the Union”.
Could specific examples be provided of a direct and indirect impact, including an example of a security incident occurring outside the Union and affecting a subsidiary indirectly within the Union?
Question 1: Do you consider the definitions included in the draft Guidelines to be sufficiently clear?
Yes - The definitions are sufficiently clear regarding a Major Incident, however further clarity is recommended on the following points:• Definition of incident: There appears to be a mismatch in the definition of incident. In the Guidelines (page 21, paragraph 13) it specifies “Payment Related services” but in the Rationale (page 7, paragraph 13) it states incidents affecting transactions, processes, data or funds". We would welcome clarification from the EBA as to whether any incident impacting a non-payment service would need to be reported. Our assumption is that non-payment related incidents and planned system outages are deemed out of scope of PSD2 reporting to Competent Authorities. Additionally, we would welcome clarity on whether an impact to customer payments in the event of an external incident (i.e. security, national disaster), would be classed as a ‘reportable’ incident. Under these guidelines the scope should be explicitly defined to include out of scope incidents.
• Incident classification: In terms of reporting major incidents that could impact payment services provided to Third Party Providers by firms and in absence of any contractual obligations (as stated under the directive), perhaps Incident Classification section within the template (Annex 1) could somehow reference this, if needed?
• A more detailed definition would be welcomed for the terms 'domestic authorities' with some examples.
• Scope of Reporting: Could the EBA provide clarity in terms of whether there is any cross-over with the scope and reporting timelines of other regulatory/legislative requirements such as the GDPR requirements? We would appreciate the EBA views on this."
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?
Yes, overall, we agree that the criteria and methodology applicable is clear, however we would welcome some clarity on the following:Assessment of Major Incident:
It is implied in the guidelines that an incident is ranked as major when a certain number of the thresholds are reached or exceeded. It is not clear from the definitions as to whether the thresholds must actually be exceeded before the incident is classified as a major incident, or whether incidents should be classified as major if there is a potential that thresholds may be exceeded. Based upon the size of the organization different thresholds may be appropriate. Sometimes an incident which starts as major ends up becoming minor or totally mitigated.
Table 1: Thresholds (page 25)
1. Transactions Affected
(a) Level 1 states: >10% of the payment service provider’s regular level of transactions and >EUR 100,000
Level 2 states: 25% of the payment service provider’s regular level of transactions OR
>EUR 1,000,000
This should be AND for Both scenarios.
A transaction of €1,000,000 particularly in the context of correspondent banking could be reached very easily and relate possibly to only one transaction and shouldn’t warrant a report.
(b) Greater clarity is required as to what constitutes “percentage of the regular level of payment transactions carried out”.
Does this mean transactions of the same type or product, or the overall level of payment transactions? e.g. mobile payments are impacted by an issue
Is the threshold calculated on the basis of the percentage of a payment service provider’s regular level of mobile payments or all payments?
2. Clients Affected: Depending on the individual interpretation of the guidance this could result in very different numbers which could make comparison across different organisations/incidents meaningless. We assume that those in scope would be all clients within the scope of PSD2 under ‘payments service user’, with other financial institutions out of scope.
3. Transactions/Clients impacted: Further clarity may be required by firms as to whether this is 10% or 25% of
(a) the total client base
(b) total number of payment transactions
(c) the client base using the specific payment service that is impacted, or
(d) the transactions processed by the impacted payment service.
4. Thresholds levels Indicators: It would generally be assumed by firms that level 1 incidents are the highest priority incidents and therefore we would recommend that the level 1/level 2 indicators are swapped, so that the Level (1) measures are the highest standards of reporting and Level (2) the lower level.
5. Service Downtime:
The proposed service downtime criteria of 2 hours is very short. At what point is the service downtime deemed to have started? Is this at the point that an initial alert is received or at the point when investigation has determined that there is a system issue?
Often it is not possible to determine how many clients may be impacted etc. Does the analysis need to be completed within the 2 hour window? This would be very short, as sometimes it could take up to a week to determine how major an incident may be.
It is important to note in considering time-frames that certain online/mobile services are available 24 hours a day, therefore the time-frame within which the service is down is relevant in the reporting of an incident.
Does this same criteria applies to partial system outages, e.g. if the system is operational but with reduced functionality or where functionality can be carried out in alternative locations, or on alternative systems to process a payment. For example, a payments system incident has the potential impact that a significant volume of same day payments may not be processed if the incident is not resolved before payment cut off times, however the impact may not materialise if the system is recovered ahead of payment cut-off times. We would welcome further clarification around service downtime and what constitutes ‘service not available’, for example, where there are multiple channels and services.
It should be noted that the current CBI Major Operational Risk Reporting criteria allows a 4 hour window for system outages.
6. Internal Level of Escalation:
We believe that a “high level of internal escalation” is not an appropriate trigger point for reporting to regulators under the guidelines. It can be very subjective and therefore is likely to lead to inconsistent reporting across payment service providers and indeed the EU. Perhaps, more clarity could be included to make the classifications less open to interpretation, for example the seniority of the CIO may vary per firm therefore should be clearer on the level of visibility of escalation expected to be reached within the organisation?
A possible alternative is Payment Service Providers should determine whether this incident has required direct input from their CIO/COO or Executive officers in the decision making process relating to the incident.
Many institutions maintain robust internal procedures which necessitate escalation of incidents internally, but they would not necessarily require reporting to external authorities.
7. Incident Notification: 3 Implementation: Guideline 2 Notification Process 2.7 & 2.8 - Perhaps the guidance could stipulate that notification should take place when an incident, deemed to be major, is first detected. For reclassified incidents, do the same criteria apply (e.g. impact figures and timing)?
8. Delegated Reporting: 3.1 - We assume this refers to the European Union.
It is recommended that higher thresholds should be defined for a near miss of the threshold (where there is a potential for thresholds to be breached) and if these are required to be reported.
9. Reputational Impact: We consider this to be very subjective and would welcome greater clarity in the guidelines on this topic.
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.
If the current obligations remain as is, it will lead to more reporting of ‘major’ incidents than those which are currently reported via domestic Operational Risk reporting, however we would like to make the following observations in this regard.We acknowledge the objectives of the EBA in relation to the draft guidelines which as stated throughout the paper is to ensure the harmonisation of incident classification, reporting and escalation across the EU.
The guidelines outline on page 9 (3.2.19) that the “thresholds mainly echo current practices …carried out across supervisors and overseers and take into account the experience gained by the ECB as a result of the pilot exercise on cyber-security incident reporting”. At a practical level however, we believe that the current proposed guidelines would in an Irish context lead to more duplication and fragmentation rather than harmonisation of reporting of Major Operational Risk Incidents.
This can be demonstrated through the variety of existing obligations particularly for large PSPs which may also touch point the proposed PSD2 guidelines e.g. members’ who are currently subject to the Central Bank of Ireland Major Operational Risk Incident Reporting obligations, the ECB Security Reporting Obligations, NIS Reporting Obligations, and Data Protection Reporting requirements.
It is important to note, for example, that the thresholds and time-frames contained within these requirements are not aligned with those proposed under PSD2. In particular, the time-frame for notifying the regulatory authorities of an incident under the Central Bank of Ireland Major Operational Risk obligations is currently 24 hours, for PSD2 initial reporting time-frame is 2 hours.
The methodology seems to be aligned with ECB pilot of cyber incidents. The scope seems to be larger as all types of incidents are included under the PSD2 scope. We think more incidents will be captured based on:
• “Service Downtime”
• Prescriptive nature of the thresholds
• If there is no discretion allowed
With regard to proportionality, for entities with a small number of customers the criteria may bring a disproportionate burden on these firms. What is deemed major by one firm may be out of line with other firms and may be unnecessarily bringing incidents to the attention of the competent authorities.
Whilst the criticality guidelines some firms operate internally are not exactly the same as the proposed thresholds, the methodology for determining a major incident is in line with these firms’ definition of a criticality 1 incident. The proposed guidelines will lead to increased reporting, however, due to the following:
The value threshold for transactions to trigger a level 2 major incident seems very low. One large corporate payment can easily be in excess of this amount and this could lead to an increased number of incidents being reported if a single payment incident can trigger the major incident classification. Firms would typically rate impact based on actual or potential financial impact, not on transaction value. For example, if a €1bn payment is late, then the financial impact of the incident would be, for example, the interest, fees or compensation associated with the late payment, not the actual value of the payment. It would be helpful for values to be completed for both levels of each threshold.
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.
Please see feedback on thresholds under Questions 2 & 3.Reputational impact is very subjective and some guidance would be required here. With reputational impact you could argue that a number of other thresholds have already been breached and there is a double count for example:
• Large number of customers affected
• Other PSP or relevant infrastructures potentially affected
• COO/CIO directly affected
The thresholds expressed in percentage seem adequate, the others might lead to an over reporting of incidents by the larger institutions. As most of the minor incident could reach the thresholds despite affecting a small number of transactions or clients in relative terms. However the value threshold of €1,000,000 to trigger a level 2 major incident seams very low. We would propose that this threshold and the % of clients affected and service downtime outlined in Level 1 and Level 2 be increased.
Service downtime: The two hour threshold is a short period of time for an outage and we feel this should be longer with the time of day also taken into consideration. There should also be recognition that different services/systems present different levels of impact if taken out of service. For example, a four hour outage of a system that processes direct debits has a lower impact on customers than a four hour outage to debit card or instant payment systems.
Reporting to the CISO might be a problem as most CISO would like all incidents to be reported to them. Some of them are mitigated, and others are of no significance.
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.
We believe that the information is generally sufficient, as outlined. We would suggest that the reporting process would be streamlined to include a secure online channel, rather than excel templates.Although the volume of information specified is reasonable for later reports, this volume is onerous for an initial report (2 hours) and will be difficult to ensure completeness especially in relation to section 6. Clarity is required on the following:
• Is it that you only complete the information you have to hand in the initial report and then in subsequent reports expand on that as information is available?
• Will CBI Trigger reporting templates be aligned to the proposed report in Annex 1 to ensure multiple reports do not have to be completed for the same incident?
Perhaps the reporting process would benefit from a separate short form" incident template version which could be used for the initial escalation within 2 hours. This would allow payment providers to focus on rectifying the solution rather than trying to complete as much of the full form as possible
However, our preference would be to retain the current time-frame for notifying the regulatory authorities of an incident under the CBI Major Operational Risk obligations which allows a 4 hour window for system outages with 24 hour reporting.
Incident Impact: There should be a measure of staff impact as this may affect the ability to maintain services. For example a security incident such as a terrorist attack where staff are unable to travel or are directly at risk.
Incident Classification: For 'Reputational' - this appears to be very subjective and response will be dependent on Author. Explicit questions should be included. As an example some firms may state that the incident could impact the PSP's share price.
Cause of Incident: Attack Type: This does not seem to be a complete list e.g. malware attack is missing (e.g. external system infected as in most attacks against online banking systems).
Suggested additional Information: Has the security incident (in the context of payment service impact e.g. DDOS) been reported to law enforcement / other agencies?
Further Guidance in terms of reporting Economic impact would be welcomed. The Economic impact is typically dependent upon and determined on the nature of an incident. Dependent upon the incident, firms won’t necessarily notify on direct or indirect costs to Competent Authorities, however, the overall Economic Impact of a Major Incident, would be dependent on the nature of those costs. For example, firms would advise the financial impacts to its customers and any direct/indirect costs associated with the remediation and redress activity, including a total value and average amount of redress paid. We would welcome further clarity via the EBA surrounding this."
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, however, we would recommend other ways of communication should also be used to clarify any doubts that may arise during review/completion of the template e.g. email or telephone.It seems detailed. How it works in practice may need to be tested.
Some of the very specific requests e.g. Start of incident" may be difficult for firms to confirm. The EBA should accept reasonable estimated times, based on investigation and internal/external intelligence, where exact start time of an Incident cannot be confirmed."
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.
Incident Discovery Point:We recommend that clarity is included within the guidelines to fully explain what is meant by 'the incident discovery point' in direct relation to the incident cycle, for example:
a) From the moment the incident was first detected for example through an incident alerting process. At this time, investigation and assessment would be required to determine the nature of the incident alert and the impact of the issue, including whether it meets major status. This investigation will reasonably take a period of time to conclude depending on the nature of the incident; or
b) From the moment the incident was assessed or reclassified as a Major Incident.
Initial Reporting:
The initial reporting period of two hours is extremely onerous as the first two hours are the most critical after an incident, and the information that can be gathered and collated in the 2 hours will be basic. It takes time to analyse an incident and determine its materiality particularly against the 8 detailed criteria as set out in the proposed guidelines. We would suggest the General Details Section only should be completed in the initial notification and reported to the competent authority.
However, our preference would be to retain the current time-frame for notifying the regulatory authorities of an incident under the CBI Major Operational Risk obligations which allows a 4 hour window for system outages with 24 hour reporting.
Intermediate Reporting:
Again there may be limited information but ongoing actions will enable sight of a plan in place for investigation and recovery. Is it required to send a report every 3 days until the issue is resolved? This may be excessive.
Final Reporting:
The full report should be sent within two weeks of recovery and back to normal". However, it may not always be possible to determine root cause within this period, for example, if the firms needs to carry out forensic analysis following a complex cyber-attack, or detailed diagnostics are required by a 3rd party supplier to assess a hardware failure. It is recommended that an indication of when the final report would be available is provided when the final interim report is completed.
We would also like to expressly point out that the final report time-frames should not necessitate any restitution/refunds to be carried out in this period. The final report time-frame should relate to the rectification and resolution of the issue.
Classification triggers:
We are of the opinion that these seem low, if trigger is hit, does that automatically mean we have to notify the incident to the Competent authority (even if a firm have mitigation/fix in place)?
If all incidents that meet the triggers are notifiable to Competent authorities, (irrespective of whether any impact is felt or not), then this effectively would generate a new class of ‘notification’ and it would be beneficial if the EBA could clarify this.
Should the EBA wish to have the information on all ‘bumps’ in the payments road, these will result in additional work for firms to complete the notification template, updates and final reports.
Overall it is unclear what they will use this information for, and what will be gained by sight of incidents which do not result in any customer impact.
In addition this will result in a larger volume of notifications being made to Regulators, which do not currently meet our reporting criteria (impact and proportionality being key criteria for these)."
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 is very unlikely that firms would delegate reporting obligations for incidents but may report on behalf of third parties to provide details of the incident, incident impact etc. which will be relevant to the market and add value by ensuring accuracy and consistency of information. The reporting guidelines provide a standard process which allows all PSPs to work to the same process.We understand that the information provided will be anonymised by the competent authority when being shared with other domestic authorities (ref 6.3, p33), however, in reference to Section 35 (p15), we would like to understand what is in place to ensure the confidentiality and/or intellectual property rights are upheld and anonymised?
In jurisdictions where this option is presently a common practice, it has proved useful for reducing the reporting burden on small payment service providers (in particular when they rely on the technical services provided by external parties).
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 suggest more clarity is required on how the consolidated reporting process will work and the information which could be shared with other payment providers. There is too little detail to be able to determine potential benefit at this stage. It would be beneficial to the Industry if the competent authority plans to provide anonymised early warning to other PSPs in a timely manner on security incidents and emerging threats, with sufficient detail to facilitate understanding of the specific cause, to enable precautions to be taken if necessary/possible.In circumstances where consolidated reporting is feasible/permitted this would make reporting more efficient by being able to fill out one single report and specifying in the dedicated table of the template the list of the impacted parties.
We believe that to be able to truly get value from this we should also be able to share this information with other financial institutions. The sharing of knowledge between financial institutions would increase the chance to fight off any attack or resolve incidents fast and efficiently.
By letting other PSPs know of a DDOS attack, they are able to prepare themselves against similar attacks e.g. ask us what we did to mitigate the attack, what worked and what did not work.
Giving an immediate overview of an incident across a number of PSPs will benefit the competent authorities forming a view on its criticality to consumers. It will also reduce the number of individual reports from firms.
ADDITIONAL COMMENTS
We would welcome clarity on the following point:
Scope of Application: 10 (Page20): “These draft guidelines apply also where the major operational or security incident originates outside the Union ….and affects, either directly or indirectly the payment services provider located within the Union”.
Could specific examples be provided of a direct and indirect impact, including an example of a security incident occurring outside the Union and affecting a subsidiary indirectly within the Union?