Response to consultation on Guidelines on major incidents reporting under PSD2
Go back
The definition of crisis mode" should exclusively refer to payment services.
Level 1 threshold values usually define critical reporting values: we therefore propose to switch the description "Level 1" and "Level 2"."
We see a need for the following explanations and/or adjustments regarding the criteria for classifying incidents (section 1.2):
a. Transaction affected
• Level 1: and" vs. Level 2: "or": should this not read "and" in both cases?
• Does the percentage refer to the quantity, or to a EUR value?
• Percentage formula: does the percentage refer to the ratio of affected transactions to daily averages for all payment transactions?
• The volume of affected transactions is generally different to estimate; making a valid statement in this respect is difficult, since transaction numbers are subject to strong fluctuations – both seasonally and on an intraday basis.
• Even the "normal level of daily transactions" is subject to fluctuations.
• The threshold values in euros are very low, and might even be reached by a single transaction.
b. Clients affected
• Level 1: "and" vs. Level 2: "or": should this not read "and" in both cases?
• Numerator: the number of clients actually affected by an outflow of data who wanted to use the service at the time of the incident; as a rule, the data outflow can only be validated at a later point in time.
c. Service downtime
• The "service downtime" definition on page 24 is not unequivocal: any service downtime outside the respective "service hours" is irrelevant.
d. Economic impact
• As a rule, it will be impossible to determine or estimate this criterion within the scope of incident processing; in our view, conducting a full-cost accounting exercise for each incident would be excessive.
e. High level of internal escalation
• Given the specific reference to "executive officers", the definition of "high level of internal escalation" is too specific, since it restricts the "internal escalation" approach. The definition should only refer to a "crisis", or to the highest internal escalation level, in accordance with the institution's own definition.
g. Reputational risk
• Additional comment to "transaction affected“: the wording “the daily annual average of payment transactions for all the payment services executed” should be amended, to read: “the daily annual average of payment transactions for the affected payment service”.
Regarding the methodology depicted in Diagram 1:
On a general note, it would be important to unify the various existing reporting requirements (ECB SSM Pilot, PSD2 incident reporting, NIS RL) in a single standard. What should be avoided is having to consider different templates and various reporting criteria for the very same security-related incidents.
It would be both important and expedient if EBA or national competent authorities provided feedback on the reports submitted, in regular intervals – either via an established platform with secure, encrypted data transmission, or in person-to-person meetings. In exceptional cases, where there is a significant threat of other institutions being affected by the same security incidents, supervisors should be disseminating information about potential incidents as broadly as possible.
In the event of security incidents affecting Third Party Service Providers, which are reported to supervisors, PSP potentially or indirectly affected should be informed accordingly, providing the following details:
a. whether identify/credentials was/were stolen;
b. whether clients behaved fraudulently;
c. whether client data was violated; and
d. whether the incident is the result of fraud.
So far, "Methodology" does not yet take any cut-off times into account. Whilst an incident within a cut-off period would be serious, an incident outside of cut-off times would be less critical."
Section 2 no. 13 provides for a significant deterioration of the protection objectives of integrity, availability, authenticity, confidentiality and continuity as a definition for serious incidents. We propose to define the criteria by reference to these protection objectives. Especially Level 2 criteria should be eligible for institution-specific application, considering these objectives.
We therefore recommend that the number of criteria be reduced, or to permit PSPs to use their own criteria, which reflect their individual risk strategy and risk appetite. Hence, the thresholds provided should only constitute a guideline.
Given that payments for corporate clients tend to have higher volumes, the criteria should distinguish between retail payments and corporate payments.
We propose the following amendments to the thresholds provided in Table 1:
-> Transaction affected
Level 1: > 10% of the PSP's regular level of transactions [Change:] and > 10,000 transactions
Level 2: > 25 % of the PSP's regular level of transactions [Change:] and > 1,000,000 transactions
Comment:
• Percentage based on quantities (number of transactions)
• Lower threshold for Levels 1 and 2 to be based on the number of transactions, rather than euro figures
-> Clients affected
Level 1: > 10% of the PSP's clients and > 5,000 clients
Level 2: > 25% of the PSP's clients [Change:] and > 500,000 clients (in accordance with the German IT Security Act)
Comment:
• Lower threshold to apply to Level 2 as well
-> Service downtime
Level 1: > 2 hours
Level 2: --
-> Economic impact
Level 1: -
Level 2: [delete:] --
Comment:
• This criterion should be deleted altogether (alternatively, use > 25,000,000 € as a threshold)
-> High level of internal escalation
Level 1: Yes
Level 2: Yes + Crisis Mode
-> Other PSPs or relevant infrastructures affected
Level 1: Yes
Level 2: --
Comment:
• The attribute potentially" should be deleted, since it cannot be determined."
According to our estimate, preparing the initial submission will involve about an hour – with another three to twelve hours (plus the efforts required for pure reporting) involved in compiling and formulating all other information.
The plethora of details makes the form too complex: sections 4 to 7 should be aggregated (and streamlined significantly), with the remaining mandatory details shown in a vertical sequence. Overall, the form should be substantially reduced, to enhance clarity and shorten processing time required.
We would also suggest separating the forms (or parts of forms) required for initial submission from those required for an interim or final report.
Comments on the individual fields of the reporting template in Annex 1:
2 – Date and time of the start of the incident, if known (*)
Comment: this must be changed into an optional field, since it can only be filled if known. .
Proposal: optional field
2 - If still ongoing, when is it expected to be over? (*)
Comment: within the scope of incident management, the end of any fault can only be predicted in very rare cases. Therefore, the field cannot be meaningfully filled.
Proposal: delete field
2 – ETA for next update
Comment: it is impossible to predict when relevant information will be available.
Proposal: delete field
5 – Commercial channels affected
Comment: in practice, no distinction is made between electronic and mobile banking.
Proposal: combine fields
5 – Payment services affected
Comment: Operations required for operating a payment account" refers to cash deposits or disbursements; this is not a separate category in accordance with the PSD2. Cash deposits and disbursements, as well as direct debits and payment transfers, are related services.
The total number of twelve selection fields appears to be very extensive and confusing.
Proposal: reduce the number of selection fields
• Delete "Operations required for operating a payment account"
• "Cash deposits/disbursements" as a check box
• "Credit transfer/direct debit" as a check box
• Show "Issuing" and "Acquiring of payment instruments below one another
5 – Functional areas affected
Comment: the selection of functions appears arbitrary – it is impossible to fully cover all options through selection fields. Moreover, this information will not usually be available for an initial submission.
Proposal: delete field
6 – Actions/measures / 7 Main corrective actions
Comment: focus details onto main actions and measures.
Proposal: see the comments to 7 Main corrective actions
6 – Investigation still ongoing
Comment: this is superfluous, given the structure of initial, interim, and final submissions.
Proposal: delete field
6 – Controls
Comment: the added value of this information detail is unclear.
Proposal: delete field
7 – Root cause
Comment: the "cause of incident" is already required in section 4.
Proposal: delete "root cause" from section 7
7 – Main corrective actions
Comment: information is already required under section 6 Actions/measures
Proposal: delete this requirement (and hence, the entire section 7)"
Furthermore, in our view it would be expedient having to submit an interim report only in the event of a significant change to the assessment, or when material new insights concerning the details indicated on the form become available. For example, assuming there are two weeks between rectification of a fault and submission of the final report (following an analysis of causes), four interim reports would need to be submitted – without any material additional insights.
Having to submit an interim report with identical content every three days would therefore appear an unnecessary bureaucratic burden. We recommend setting the maximum distance between two reports to two weeks.
Irrespective of the resolution of a fault, an analysis of facts might well take longer than two weeks. The maximum of two weeks specified in section 2.17 should be deleted – otherwise, a final report might have to be submitted without the exact causes being known.
The diagram shown on page 12 suggests that the displayed process for incident reporting to supervisors needs to be set up as a separate sub-process having exactly the same structure. The diagram should be removed, or exchanged against a sample view of norms and standards for incident management and reporting. It is much more important that the facts outlined here be integrated into a normal/existing incident management environment."
With regard to the German Banking Landscape, consisting of more than 400 savings banks and more than 1000 (partly very small) cooperative banks, these banks strongly need the possibility that their central IT service providers can create and send one common (aggregated) incident report to the NCA. With regard to the reporting process under EBA Guidelines on the security of internet payments this possibility does exist today and has proven to be efficient. For instance, reports are being submitted by the central institution of the German cooperative banking sector (or the sector's IT services provider) – instead of around 1,000 reports by individual cooperative banks, which offer the services as PSPs.
The claim for absolute impact values in the reporting template (Part 3 – Incident Classification) might impede this. Costs and efforts resulting from this requirement will be disproportionate to the benefits. Compiling criteria and details separately for each PSP would render the procedure useless, given the bureaucratic efforts involved (30 minutes, multiplied by the number of PSPs). In particular, the procedure should not provide for figures regarding affected clients and transactions, and regarding the economic impact, at the PSP level – instead, it should be possible to provide details for all PSPs connected to the service provider, using aggregated figures or by way of a summary assessment. We would welcome some more flexibility in this context (e.g. allowing average values or value ranges).
Question 1: Do you consider the definitions included in the draft Guidelines to be sufficiently clear?
The definitions set out in chapter 2 are sufficiently detailed, and comprehensible.The definition of crisis mode" should exclusively refer to payment services.
Level 1 threshold values usually define critical reporting values: we therefore propose to switch the description "Level 1" and "Level 2"."
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?
As a matter of principle, the approach for the classification of major incidents is transparent.We see a need for the following explanations and/or adjustments regarding the criteria for classifying incidents (section 1.2):
a. Transaction affected
• Level 1: and" vs. Level 2: "or": should this not read "and" in both cases?
• Does the percentage refer to the quantity, or to a EUR value?
• Percentage formula: does the percentage refer to the ratio of affected transactions to daily averages for all payment transactions?
• The volume of affected transactions is generally different to estimate; making a valid statement in this respect is difficult, since transaction numbers are subject to strong fluctuations – both seasonally and on an intraday basis.
• Even the "normal level of daily transactions" is subject to fluctuations.
• The threshold values in euros are very low, and might even be reached by a single transaction.
b. Clients affected
• Level 1: "and" vs. Level 2: "or": should this not read "and" in both cases?
• Numerator: the number of clients actually affected by an outflow of data who wanted to use the service at the time of the incident; as a rule, the data outflow can only be validated at a later point in time.
c. Service downtime
• The "service downtime" definition on page 24 is not unequivocal: any service downtime outside the respective "service hours" is irrelevant.
d. Economic impact
• As a rule, it will be impossible to determine or estimate this criterion within the scope of incident processing; in our view, conducting a full-cost accounting exercise for each incident would be excessive.
e. High level of internal escalation
• Given the specific reference to "executive officers", the definition of "high level of internal escalation" is too specific, since it restricts the "internal escalation" approach. The definition should only refer to a "crisis", or to the highest internal escalation level, in accordance with the institution's own definition.
g. Reputational risk
• Additional comment to "transaction affected“: the wording “the daily annual average of payment transactions for all the payment services executed” should be amended, to read: “the daily annual average of payment transactions for the affected payment service”.
Regarding the methodology depicted in Diagram 1:
On a general note, it would be important to unify the various existing reporting requirements (ECB SSM Pilot, PSD2 incident reporting, NIS RL) in a single standard. What should be avoided is having to consider different templates and various reporting criteria for the very same security-related incidents.
It would be both important and expedient if EBA or national competent authorities provided feedback on the reports submitted, in regular intervals – either via an established platform with secure, encrypted data transmission, or in person-to-person meetings. In exceptional cases, where there is a significant threat of other institutions being affected by the same security incidents, supervisors should be disseminating information about potential incidents as broadly as possible.
In the event of security incidents affecting Third Party Service Providers, which are reported to supervisors, PSP potentially or indirectly affected should be informed accordingly, providing the following details:
a. whether identify/credentials was/were stolen;
b. whether clients behaved fraudulently;
c. whether client data was violated; and
d. whether the incident is the result of fraud.
So far, "Methodology" does not yet take any cut-off times into account. Whilst an incident within a cut-off period would be serious, an incident outside of cut-off times would be less critical."
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.
Institutions have already established incident reporting systems providing for a classification of incidents, depending upon the nature of the service affected, and the degree of risk involved. A classification using some quantitative criteria may therefore lead to more incidents being classified as serious.Section 2 no. 13 provides for a significant deterioration of the protection objectives of integrity, availability, authenticity, confidentiality and continuity as a definition for serious incidents. We propose to define the criteria by reference to these protection objectives. Especially Level 2 criteria should be eligible for institution-specific application, considering these objectives.
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.
When dealing with incidents, fighting the causes has utmost priority. Given the proposed rules, PSPs would be under an obligation – in a situation which may be difficult – to determine various indicators in order to decide whether a notice must be given, requiring an estimated 30 minutes of effort for each PSP to compile the relevant data.We therefore recommend that the number of criteria be reduced, or to permit PSPs to use their own criteria, which reflect their individual risk strategy and risk appetite. Hence, the thresholds provided should only constitute a guideline.
Given that payments for corporate clients tend to have higher volumes, the criteria should distinguish between retail payments and corporate payments.
We propose the following amendments to the thresholds provided in Table 1:
-> Transaction affected
Level 1: > 10% of the PSP's regular level of transactions [Change:] and > 10,000 transactions
Level 2: > 25 % of the PSP's regular level of transactions [Change:] and > 1,000,000 transactions
Comment:
• Percentage based on quantities (number of transactions)
• Lower threshold for Levels 1 and 2 to be based on the number of transactions, rather than euro figures
-> Clients affected
Level 1: > 10% of the PSP's clients and > 5,000 clients
Level 2: > 25% of the PSP's clients [Change:] and > 500,000 clients (in accordance with the German IT Security Act)
Comment:
• Lower threshold to apply to Level 2 as well
-> Service downtime
Level 1: > 2 hours
Level 2: --
-> Economic impact
Level 1: -
Level 2: [delete:] --
Comment:
• This criterion should be deleted altogether (alternatively, use > 25,000,000 € as a threshold)
-> High level of internal escalation
Level 1: Yes
Level 2: Yes + Crisis Mode
-> Other PSPs or relevant infrastructures affected
Level 1: Yes
Level 2: --
Comment:
• The attribute potentially" should be deleted, since it cannot be determined."
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.
The information to be provided is excessive, and redundant in part. This will not only complicate populating the template, but also analysis by supervisors – in fact, this contradicts the notion of quickly gaining a precise impression of the incident.According to our estimate, preparing the initial submission will involve about an hour – with another three to twelve hours (plus the efforts required for pure reporting) involved in compiling and formulating all other information.
The plethora of details makes the form too complex: sections 4 to 7 should be aggregated (and streamlined significantly), with the remaining mandatory details shown in a vertical sequence. Overall, the form should be substantially reduced, to enhance clarity and shorten processing time required.
We would also suggest separating the forms (or parts of forms) required for initial submission from those required for an interim or final report.
Comments on the individual fields of the reporting template in Annex 1:
2 – Date and time of the start of the incident, if known (*)
Comment: this must be changed into an optional field, since it can only be filled if known. .
Proposal: optional field
2 - If still ongoing, when is it expected to be over? (*)
Comment: within the scope of incident management, the end of any fault can only be predicted in very rare cases. Therefore, the field cannot be meaningfully filled.
Proposal: delete field
2 – ETA for next update
Comment: it is impossible to predict when relevant information will be available.
Proposal: delete field
5 – Commercial channels affected
Comment: in practice, no distinction is made between electronic and mobile banking.
Proposal: combine fields
5 – Payment services affected
Comment: Operations required for operating a payment account" refers to cash deposits or disbursements; this is not a separate category in accordance with the PSD2. Cash deposits and disbursements, as well as direct debits and payment transfers, are related services.
The total number of twelve selection fields appears to be very extensive and confusing.
Proposal: reduce the number of selection fields
• Delete "Operations required for operating a payment account"
• "Cash deposits/disbursements" as a check box
• "Credit transfer/direct debit" as a check box
• Show "Issuing" and "Acquiring of payment instruments below one another
5 – Functional areas affected
Comment: the selection of functions appears arbitrary – it is impossible to fully cover all options through selection fields. Moreover, this information will not usually be available for an initial submission.
Proposal: delete field
6 – Actions/measures / 7 Main corrective actions
Comment: focus details onto main actions and measures.
Proposal: see the comments to 7 Main corrective actions
6 – Investigation still ongoing
Comment: this is superfluous, given the structure of initial, interim, and final submissions.
Proposal: delete field
6 – Controls
Comment: the added value of this information detail is unclear.
Proposal: delete field
7 – Root cause
Comment: the "cause of incident" is already required in section 4.
Proposal: delete "root cause" from section 7
7 – Main corrective actions
Comment: information is already required under section 6 Actions/measures
Proposal: delete this requirement (and hence, the entire section 7)"
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.
The explanations regarding the form are sufficiently comprehensible.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.
As implementation practice regarding EBA's Guideline on security of internet payments" on a national level has shown, classification as to whether an incident is a "major" is not necessarily feasible within the specified period of time. To achieve a qualified assessment and classification of Level 1 and Level 2 criteria, the deadline should be extended to three or four hours.Furthermore, in our view it would be expedient having to submit an interim report only in the event of a significant change to the assessment, or when material new insights concerning the details indicated on the form become available. For example, assuming there are two weeks between rectification of a fault and submission of the final report (following an analysis of causes), four interim reports would need to be submitted – without any material additional insights.
Having to submit an interim report with identical content every three days would therefore appear an unnecessary bureaucratic burden. We recommend setting the maximum distance between two reports to two weeks.
Irrespective of the resolution of a fault, an analysis of facts might well take longer than two weeks. The maximum of two weeks specified in section 2.17 should be deleted – otherwise, a final report might have to be submitted without the exact causes being known.
The diagram shown on page 12 suggests that the displayed process for incident reporting to supervisors needs to be set up as a separate sub-process having exactly the same structure. The diagram should be removed, or exchanged against a sample view of norms and standards for incident management and reporting. It is much more important that the facts outlined here be integrated into a normal/existing incident management environment."
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.
Yes – delegated reporting is especially useful for banking unions or banking groups, given their supply chain (including outsourcing relationships). Where services have been outsourced, delegated reporting offers significant advantages, especially with regard to obtaining first-hand information about an incident.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.
Providing a single, coherent report regarding a single incident involving a service provider acting on behalf of several PSPs is highly rational. Requiring PSPs to submit individual reports would trigger multiple reports for the same incident (without such reports being clearly recognisable as referring to that incident); this would distort the entire reporting system. In individual cases, this might lead to a distorted assessment of the situation, which might affect the setting of priorities by regulators.With regard to the German Banking Landscape, consisting of more than 400 savings banks and more than 1000 (partly very small) cooperative banks, these banks strongly need the possibility that their central IT service providers can create and send one common (aggregated) incident report to the NCA. With regard to the reporting process under EBA Guidelines on the security of internet payments this possibility does exist today and has proven to be efficient. For instance, reports are being submitted by the central institution of the German cooperative banking sector (or the sector's IT services provider) – instead of around 1,000 reports by individual cooperative banks, which offer the services as PSPs.
The claim for absolute impact values in the reporting template (Part 3 – Incident Classification) might impede this. Costs and efforts resulting from this requirement will be disproportionate to the benefits. Compiling criteria and details separately for each PSP would render the procedure useless, given the bureaucratic efforts involved (30 minutes, multiplied by the number of PSPs). In particular, the procedure should not provide for figures regarding affected clients and transactions, and regarding the economic impact, at the PSP level – instead, it should be possible to provide details for all PSPs connected to the service provider, using aggregated figures or by way of a summary assessment. We would welcome some more flexibility in this context (e.g. allowing average values or value ranges).