Response to consultation on Guidelines on major incidents reporting under PSD2
Go back
We would welcome further guidance regarding the criteria and methodology applicable for the assessment and classification of an incident.
In our view, some of the terminology used would benefit from additional clarification. In particular, one would usually expect, that “Level 1” specifies the highest criticality level. In this regard we suggest that the lesser major incidents (currently referred to as Level 1) is swapped and instead called Level 2.
In addition, “Crisis Mode” is an undefined term which appears in the draft Guidelines. We understand that Crisis Mode can be triggered by various events and not necessarily affect payment services. Therefore, we suggest clarifying that only Crisis Mode instigated in relation to its effects on payment services (solely, or together with other events) should be taken into account for the purpose of qualifying an incident as major under Level 2 threshold, “High Level of Internal Escalation”.
Assessment Indicators: Determining the number of affected clients
We would welcome further clarification of the indicators for the assessment of an incident, in particular the indicator for the number of affected clients.
As a banking institution conducting various businesses, our clients receive large variety of services. Where payment services may or may not be part of their products offering, we do not believe that including the total number of clients using the bank’s brokerage services would be relevant to payment services. In this regard, we would welcome the clarification that for the purpose of calculation of the thresholds, the total amount of clients should not include clients that do not receive payment services. We suggest that the calculation of total number of clients is made on the basis of “users” of the application if the incident in question affects the functioning of such applications (services).
Similarly, for banking groups, we would benefit from further clarity on how the clients of different entities belonging to the same group would be treated for the purposes of thresholds calculation.
Calculating the total number of clients and the number of affected clients by the office location can make a difference, particularly as the client base of a bank in one EU office could be larger than that of another EU office. If a location is servicing a small number of clients, the number of affected clients might not reach the set thresholds even if all of the clients of the office are impacted by an incident. Our suggestion is that such an incident, should be treated as major.
Further, we would like to note that it may be challenging to define the number of the affected clients if, for example, an application was not working. Theoretically, it might be that the impacted clients would be: i) all of the clients that have access to such application; or ii) only those clients that tried accessing the application. However, client activity may differ depending on the time and day (an ordinary business day night or pre-Christmas), and the bank may not have the information about the clients who have attempted to use such application (especially considering that for some applications these might also include the client of other banks).
We therefore suggest that this measurement should instead be the bank’s estimate of average number of clients who might have been using such specific application and those who do not have access to such applications should not be counted in as affected clients.
Assessment Indicators: Determining the number of affected transactions
Similar difficulties might arise when calculating the amount of affected transactions. As the type of transactions in question would have an impact, we believe it should be taken into account. For example, due to the volumes of corporate payments, one single transaction may be greater than EUR 5,000,000. This means that an incident affecting only one of such high value payment transactions will have to be reported as major (as it satisfies one of the criteria in Level 2 thresholds).
However, we do not believe that such incident should called major as it affects only one transaction for one client. Likewise, counting such high value payment transactions for the purposes of defining regular level of transactions would set the bar too high for the incident affecting smaller transactions. Therefore, our suggestion would be to introduce separate thresholds calculations which differ by transactions type and account for the client type (based on the average amount of its transactions, or systems used to initiate payments transaction).
Assessment Indicators: Reputational Impact
The draft Guidelines currently suggest that “how the incident can undermine user’s trust in the payment service provider itself and, more generally, in the underlying service or the market as a whole” (1.1.g), should serve as an indicator determining if the reputational impact represents a major incident. In addition, PSPs are expected to consider the likelihood that the incident could cause harm to society, look into the media coverage it has received (e.g. in blogs and social networks) and whether the payment service provider has been put in a competitive disadvantage as a result of the incident (1.2.g).
Some of the suggested indicators proposed are subjective / dependent on individual user experience, or reliant on assessment of future events. These indicators would be hard to assess and predict without any evidence.
Instead, we suggest that the reputational damage should be assessed against publicly available factual information about the incident, e.g. if such incident:
• Attracts significant negative attention in national media (more than one mention),
• Results in continuous, repeating criticism via various media channels,
• Is opposed by significant cross-section of the public expressed in various media channels,
• Results in criticism of the PSP from the state authorities.
With regards to the EBA’s suggestion to track media coverage in blogs and social networks, we understand that the intention was to be able to track major incidents and not to oblige the PSPs to track all the coverage of the incident appearing in “blogs and social networks”. In our view this is not feasibly practical as it would involve major resources.
In addition, if the matter becomes major, the incident is likely to be found in national press, making the requirement to track media coverage in “blogs and social networks” unnecessary.
In addition, the obligation of a PSP to assess whether it has been put at a competitive disadvantage, will be very difficult to achieve in practice. We understand that it was not the intention of the EBA to require the PSP to establishing the fact of competitive disadvantage as it represents a complex matter of “anti-trust” law which is subject to an opinion of a respective state authority. At the same time the clarification on what exactly would need to be established by PSP (what would be the criteria) are very welcomed. When defining these rules, the short timing (two hours) allowed for completion of the initial assessment and report should be also taken into account, as well as the expertise and information readily available to a PSP for such assessment.
Threshold Calculation: Cut-off times
In our view, cut-off times should be taken into account for the assessment of incidents. The criticality of an incident is considerably higher when it occurs before a cut-off time, than when it happens after it. We therefore welcome respective amendments to address this.
All of these rules provide a higher threshold for reporting, meaning that thresholds suggested in the draft Guidelines will dramatically increase the number of incidents to be reported as “major”. These current reporting requirements, that DB is already subject to, specify the information and templates of the reports which differ from those in these draft Guidelines.
In this regard, we suggest that the EBA harmonises the draft Guidelines with the existing rules and requirements. The requirements should be brought into one single standard to follow the established reporting thresholds, avoid double reporting of the same incidents and different reporting standards (e.g. format of the files and the content).
Therefore, we suggest that Level 2 thresholds are amended as follows (that would be also in line with thresholds provided under other regulations):
a. Economic Impact > EUR 25,000,000 (according to the Single Supervisory Mechanism),
b. Affected clients > 250,000 (according to the IT Security Act Germany),
c. Transactions affected > 10,000.000 (according to our internal incident classification),
d. Transactions affected: we suggest this is calculated by the type of service by changing “the daily annual average of payment transactions for all the payment services executed” to “the daily annual average of payment transactions for the affected payment service”.
Following the requirements specified in the draft Guidelines on the Security of Internet Payments, we suggest that all incidents solved within one hour do not require reporting.
The draft Guidelines require incident reporting by the TPPs to be delivered to the state authorities. However, it does not provide any mechanisms to make a bank aware of such incidents, particularly when a major incident with a TPP may significantly impact security of the bank and its clients. Major incidents of a TPP may lead to further misuse of client information and money.
To address this, we believe a mechanism should be introduced which allows the bank to be made aware of such incidents where major incident of a TPPs affects clients of the bank and their accounts. This notification will allow the bank to take the necessary actions to protect clients and reduce negative consequences of such incidents. This is especially relevant where identity/credentials, or any other data of the clients were stolen, or in cases where the incident was a result of fraudulent actions.
We suggest that wording be included in the draft Guidelines which accepts that there will be missing information in the initial report. In addition, we believe that clarification is required on what the EBA means by two hours as it could be interpreted as either “working hours” or “24x7”.
We suggest that the draft Guidelines specify that the reporting is expected within two working hours, taking into account the timezone of where the application is hosted. For example, if an incident takes place on Friday at 5pm, the time period for the submission of the report should be Monday morning.
We suggest that the EBA consider introducing security requirements for third parties who are responsible for safeguarding client data. Third parties’ compliance with security procedures similar to those provided to banks and TPPs when dealing with client confidential information seems to be a reasonable expectation.
At the same time, we believe that such consolidation can help stop the spread of incidents if they are made available to other PSPs. This will enable PSPs to react and take all necessary measures to protect the incident from happening to their clients. It would be especially important if the incident in question resulted from a fraud, or compromised data security.
Question 1: Do you consider the definitions included in the draft Guidelines to be sufficiently clear?
While in general we agree that the definitions are sufficiently clear, we would suggest expanding the current definition of major operational or security incident with reference to the potential impact an event may have on client data. Compromising data integrity, availability, confidentiality and authenticity risks exposing the amount in client accounts and available overdrafts affecting not only services but also security of clients’ funds.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?
TerminologyWe would welcome further guidance regarding the criteria and methodology applicable for the assessment and classification of an incident.
In our view, some of the terminology used would benefit from additional clarification. In particular, one would usually expect, that “Level 1” specifies the highest criticality level. In this regard we suggest that the lesser major incidents (currently referred to as Level 1) is swapped and instead called Level 2.
In addition, “Crisis Mode” is an undefined term which appears in the draft Guidelines. We understand that Crisis Mode can be triggered by various events and not necessarily affect payment services. Therefore, we suggest clarifying that only Crisis Mode instigated in relation to its effects on payment services (solely, or together with other events) should be taken into account for the purpose of qualifying an incident as major under Level 2 threshold, “High Level of Internal Escalation”.
Assessment Indicators: Determining the number of affected clients
We would welcome further clarification of the indicators for the assessment of an incident, in particular the indicator for the number of affected clients.
As a banking institution conducting various businesses, our clients receive large variety of services. Where payment services may or may not be part of their products offering, we do not believe that including the total number of clients using the bank’s brokerage services would be relevant to payment services. In this regard, we would welcome the clarification that for the purpose of calculation of the thresholds, the total amount of clients should not include clients that do not receive payment services. We suggest that the calculation of total number of clients is made on the basis of “users” of the application if the incident in question affects the functioning of such applications (services).
Similarly, for banking groups, we would benefit from further clarity on how the clients of different entities belonging to the same group would be treated for the purposes of thresholds calculation.
Calculating the total number of clients and the number of affected clients by the office location can make a difference, particularly as the client base of a bank in one EU office could be larger than that of another EU office. If a location is servicing a small number of clients, the number of affected clients might not reach the set thresholds even if all of the clients of the office are impacted by an incident. Our suggestion is that such an incident, should be treated as major.
Further, we would like to note that it may be challenging to define the number of the affected clients if, for example, an application was not working. Theoretically, it might be that the impacted clients would be: i) all of the clients that have access to such application; or ii) only those clients that tried accessing the application. However, client activity may differ depending on the time and day (an ordinary business day night or pre-Christmas), and the bank may not have the information about the clients who have attempted to use such application (especially considering that for some applications these might also include the client of other banks).
We therefore suggest that this measurement should instead be the bank’s estimate of average number of clients who might have been using such specific application and those who do not have access to such applications should not be counted in as affected clients.
Assessment Indicators: Determining the number of affected transactions
Similar difficulties might arise when calculating the amount of affected transactions. As the type of transactions in question would have an impact, we believe it should be taken into account. For example, due to the volumes of corporate payments, one single transaction may be greater than EUR 5,000,000. This means that an incident affecting only one of such high value payment transactions will have to be reported as major (as it satisfies one of the criteria in Level 2 thresholds).
However, we do not believe that such incident should called major as it affects only one transaction for one client. Likewise, counting such high value payment transactions for the purposes of defining regular level of transactions would set the bar too high for the incident affecting smaller transactions. Therefore, our suggestion would be to introduce separate thresholds calculations which differ by transactions type and account for the client type (based on the average amount of its transactions, or systems used to initiate payments transaction).
Assessment Indicators: Reputational Impact
The draft Guidelines currently suggest that “how the incident can undermine user’s trust in the payment service provider itself and, more generally, in the underlying service or the market as a whole” (1.1.g), should serve as an indicator determining if the reputational impact represents a major incident. In addition, PSPs are expected to consider the likelihood that the incident could cause harm to society, look into the media coverage it has received (e.g. in blogs and social networks) and whether the payment service provider has been put in a competitive disadvantage as a result of the incident (1.2.g).
Some of the suggested indicators proposed are subjective / dependent on individual user experience, or reliant on assessment of future events. These indicators would be hard to assess and predict without any evidence.
Instead, we suggest that the reputational damage should be assessed against publicly available factual information about the incident, e.g. if such incident:
• Attracts significant negative attention in national media (more than one mention),
• Results in continuous, repeating criticism via various media channels,
• Is opposed by significant cross-section of the public expressed in various media channels,
• Results in criticism of the PSP from the state authorities.
With regards to the EBA’s suggestion to track media coverage in blogs and social networks, we understand that the intention was to be able to track major incidents and not to oblige the PSPs to track all the coverage of the incident appearing in “blogs and social networks”. In our view this is not feasibly practical as it would involve major resources.
In addition, if the matter becomes major, the incident is likely to be found in national press, making the requirement to track media coverage in “blogs and social networks” unnecessary.
In addition, the obligation of a PSP to assess whether it has been put at a competitive disadvantage, will be very difficult to achieve in practice. We understand that it was not the intention of the EBA to require the PSP to establishing the fact of competitive disadvantage as it represents a complex matter of “anti-trust” law which is subject to an opinion of a respective state authority. At the same time the clarification on what exactly would need to be established by PSP (what would be the criteria) are very welcomed. When defining these rules, the short timing (two hours) allowed for completion of the initial assessment and report should be also taken into account, as well as the expertise and information readily available to a PSP for such assessment.
Threshold Calculation: Cut-off times
In our view, cut-off times should be taken into account for the assessment of incidents. The criticality of an incident is considerably higher when it occurs before a cut-off time, than when it happens after it. We therefore welcome respective amendments to address this.
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.
Compulsory reporting procedures for payment-related incidents are already in place across the European Union. As a German credit institution, DB is subject to reporting requirements established by SecurePay, EU Information Security Directive (in Germany – “IT Security Act” to be transposed into national laws in 2017), Network and Infrastructure Security (‘NIS’), Single Supervisory Mechanism (‘SSM’).All of these rules provide a higher threshold for reporting, meaning that thresholds suggested in the draft Guidelines will dramatically increase the number of incidents to be reported as “major”. These current reporting requirements, that DB is already subject to, specify the information and templates of the reports which differ from those in these draft Guidelines.
In this regard, we suggest that the EBA harmonises the draft Guidelines with the existing rules and requirements. The requirements should be brought into one single standard to follow the established reporting thresholds, avoid double reporting of the same incidents and different reporting standards (e.g. format of the files and the content).
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.
Some of the thresholds aim to address the incidents related to accounts of individual clients, which results in almost any incident being classified as “major” in the context of corporate clients. While corporate clients tend to operate much higher volumes of money, different criteria should be introduced for them. In addition, we believe that the thresholds would benefit from harmonisation with the thresholds provided under other regulations.Therefore, we suggest that Level 2 thresholds are amended as follows (that would be also in line with thresholds provided under other regulations):
a. Economic Impact > EUR 25,000,000 (according to the Single Supervisory Mechanism),
b. Affected clients > 250,000 (according to the IT Security Act Germany),
c. Transactions affected > 10,000.000 (according to our internal incident classification),
d. Transactions affected: we suggest this is calculated by the type of service by changing “the daily annual average of payment transactions for all the payment services executed” to “the daily annual average of payment transactions for the affected payment service”.
Following the requirements specified in the draft Guidelines on the Security of Internet Payments, we suggest that all incidents solved within one hour do not require reporting.
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.
From a user perspective, it is not currently clear which pieces of information (if any) are considered to be the minimum necessary for the initial high level report, which has to be submitted in 2 hours, or the intermediate report. In addition, it is not specified whether the initial/high level template document should be updated as matters progress, or whether a new report should be submitted each time.The draft Guidelines require incident reporting by the TPPs to be delivered to the state authorities. However, it does not provide any mechanisms to make a bank aware of such incidents, particularly when a major incident with a TPP may significantly impact security of the bank and its clients. Major incidents of a TPP may lead to further misuse of client information and money.
To address this, we believe a mechanism should be introduced which allows the bank to be made aware of such incidents where major incident of a TPPs affects clients of the bank and their accounts. This notification will allow the bank to take the necessary actions to protect clients and reduce negative consequences of such incidents. This is especially relevant where identity/credentials, or any other data of the clients were stolen, or in cases where the incident was a result of fraudulent actions.
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, we believe that the instructions provided are sufficiently clear.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 number of affected transactions or affected clients is not always known at the beginning of an incident and more than two hours may be needed to obtain this information. Therefore, in such cases the incident cannot be reported within the required two hours.We suggest that wording be included in the draft Guidelines which accepts that there will be missing information in the initial report. In addition, we believe that clarification is required on what the EBA means by two hours as it could be interpreted as either “working hours” or “24x7”.
We suggest that the draft Guidelines specify that the reporting is expected within two working hours, taking into account the timezone of where the application is hosted. For example, if an incident takes place on Friday at 5pm, the time period for the submission of the report should be Monday morning.
Question 8: Do you consider I that the delegated reporting procedure proposed in the draft Guidelines will provide added value to the market? Please explain your reasoning.
We believe that this is a function that some PSPs may consider useful. However, the delegated reporting procedure proposed by the EBA raises an important question of security in terms of the data being in possession of such a third party delegated with reporting obligations.We suggest that the EBA consider introducing security requirements for third parties who are responsible for safeguarding client data. Third parties’ compliance with security procedures similar to those provided to banks and TPPs when dealing with client confidential information seems to be a reasonable expectation.
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 welcome the EBA’s suggestion to allow consolidated reporting. In our view, presenting one single report has certain benefits: it will facilitate the analysis of the information by the regulations, and provide a bigger picture of the impact of the incident.At the same time, we believe that such consolidation can help stop the spread of incidents if they are made available to other PSPs. This will enable PSPs to react and take all necessary measures to protect the incident from happening to their clients. It would be especially important if the incident in question resulted from a fraud, or compromised data security.