Primary tabs

Dutch Payments Association/Betaalvereniging

Betaalvereniging Nederland (Dutch Payments Association) organises the collective – non competitive – tasks in the national payment system for its members. Our members are providers of payment services: banks, payment institutions and electronic money institutions. The Dutch Payments Association’s responsibilities lie in the areas of infrastructure, standards and shared product features. We seek to ensure a socially efficient, safe and reliable payment system, with room for innovation.

The definitions used are high-level definitions and are not fully in line with the definitions used in, for example ISO 27001/27002. The Dutch Payments Association strongly advises EBA to adopt the relevant definitions from well-known international organisations such as ISO, BIS or ENISA, which are already widely used in the industry and used in relevant EU-regulation (e.g. eIDAS Regulation (Regulation (EU) No 910/2014), GDPR (Regulation (EU) 2016/679), NIS Directive (Directive (EU) 2016/1148)).
We believe the following definitions should be further clarified.

1. Definition of “availability” and “continuity”
There is a strong link between the terms “availability” and “continuity”. Why do the proposed Guidelines use two definitions? And if EBA considers that both definitions are required, we would welcome more clarity in detailing the difference between those two. Reading and interpreting the definition of continuity, we advise to replace the term “continuity” by “recovery”. In that case the consequence of a short (to be defined) period of recovery, will lead to a short(er) time of unavailability;

2. Major operational or security incident
The definition does not clarify what “major” constitutes. Nor does it clarify what “material adverse impact” is. We assume that an “event” can either be in an internal issue or an attack by a cybercriminal (in whatever form). Please clarify this definition.
Furthermore, we advise to delete the term “major” from the definition. In our opinion it is more appropriate to explain what kind of major incident EBA expects banks to report to the competent authority in their Member State. This is further described in the Guidelines; in our view it should not be part of a definition of “operational or security incident”. Is the definition “event” equal to the definition used by the Bank of Internal Settlements (?) (BIS) for an “operational risk incident”?

3. Major operational or security incident (2)
We propose to delete the wording “may have”. In our opinion only materialized incidents should be reported, and not all (potential) vulnerabilities that potentially have impact.

4. Please add a definition for “crisis mode or equivalent” as used in Table 1 on page 26
PSD2 will further open up the EU-market for payment services and create a network effect. New service providers, like PIS and AIS, will be part of the payment chain. How will ASPSPs be notified on security breaches by for example other PSPs which offer AIS or PIS, so further damage can be prevented for the ASPSPs’ customers? Can we expect that the knowledge that is shared between individual PSPs with the competent authorities regarding security incidents is timely shared with other financial institutions?

In general, PSPs currently have to deal with all kinds of incident reporting requirements as demanded by their local authorities. The current proposed EBA Guidelines will lead to additional reporting requirements. The Guidelines should clarify for Member State’s competent authorities that the new required reporting replaces similar national reporting requirements as prescribed by the competent authorities.
The criteria do not distinguish between different kinds of incidents that can lead to unavailability of the service (e.g. due to a DDoS attack, or an internal failure leading to unavailability of the service). For example, we do not consider the unavailability of a service for a short period of time (e.g. 15 minutes) an incident that is categorized as a major incident, even though this (potentially) affects all customers.
Therefore, we suggest to use two different thresholds: one for unavailability and continuity of the service and one for incidents related to integrity, confidentiality and authenticity. The current set of criteria are related to the second group of incidents. Service downtime relates to the first group of incidents. In the case of unavailability of the service most of the current set of questions are not relevant.
It is unclear why EBA decided to use a “-“ for the criteria “Other PSP or relevant infrastructures protected” and “Reputational risk” on level 2. We believe that these two criteria in itself are never sufficient to classify an incident as a major incident. If our interpretation is correct, we request EBA to clarify this in these Guidelines.

Especially for large banks the mentioned amounts are too low. Given these criteria large banks will become overburdened with incident reporting. For example, batch payments, where the batch sums to an amount above the limit and that are postponed for a short period of time would qualify for reporting. We strongly advise to increase the limits for the amounts.

We would like to mention another point of attention regarding an external event leading to an incident that should be reported. A (quite extreme) example: Telecommunication is unavailable for a number of days in a country, leading to non-availability of internet, etc. In that case, it is relevant to inform the national competent authority. The question is: are intermediate and final reports required if the root cause lies outside the informant’s circle of influence?
The current set of criteria will lead to significantly more incidents that will require reporting. Two large Dutch banks and one payment institution performed an internal check over a period of one month. Extrapolating the result from one month to one year would lead to an estimated 400 to500 additional incidents that would require reporting. This is a huge increase as compared with the current number of incidents reported.
Note that ,most of these incidents - that would require reporting according to the proposed Guidelines - did not impact any customer. In most cases, the problem consisted of a delay in the processing of a batch of payment transactions (representing a total value per batch of more than EUR 1.000.000). The delays were timely resolved, meaning that customer’s did not noticed any delay in the processing of their payments.

Taking the above into consideration, we advise EBA to exemplify that only incidents are considered as major incidents in which clients or the PSP suffers actual material damage due to these incidents. Ways to measure this is either fraud related and/or the criterion that the service level as agreed between client and PSP is not met. For example, if the PSP uses a third party concentrator for a number of clients and that clients concentrator or the public infrastructure is not available, we consider that the PSP only has to report if the PSP cannot meet its service level as agreed with its clients.
We advise EBA to clarify that only reporting is required if the service levels of the PSP’s services are affected and the level 1 (or level 2) criteria are met.

On page 47, in chapter 5.C.2 is stated: “for the duration of the incident, a major incident is reached if the incident hinders the operations for more than two hours”. We advise EBA to clarify how the two hours should be defined:
- From the moment the incident occurs?
- From the moment the incident is detected?
- Or from the moment the incident is classified as major?
We strongly advise EBA to use the third definition (from the moment the incident is classified as major).

Furthermore, we believe that the mentioned distinction between availability and integrity/confidentiality has to be made (see our remarks in question 1). Without this distinction the qualification of incidents can potentially lead to even more “major incidents” requiring reporting according to the Guidelines.
We believe that the threshold as mentioned in the proposed Guidelines for amounts and number of transactions affected for level 1 and level 2 criteria are set too low. This can potentially lead to the result that relatively small incidents require reporting (see also our answer to question 3). The proposed amount (level 2) for transactions affected for larger PSPs is a very low amount. Basically the choice of any specific amount is arbitrary. We advise EBA to limit the criterion “transactions affected” to only the mentioned percentage and to delete the amount as criterion.
In that case more important is what EBA defines as “economic impact”. We advise EBA to rename “economic impact” in “financial impact for the PSP”, as the description in the draft guidelines describes it as the financial impact for the PSP.
This aspect also relates to our answer to question 1 (third point) in which we strongly advise not to use the term “may have” in the definition of a major operational or security incident, as an incident can potentially have (“may have”) consequences for more customers and a higher transaction amount affected.
We advise EBA to take into account the impact of additional notification requirements for incidents that also meet the criteria of the General Data Protection Regulation (GDPR) in case of a data breach. We would like to prevent overburdening PSPs with different and potentially overlapping notification requirements. Confidentiality incidents can also lead to the requirement to report these to the domestic privacy authority. Preferably, the competent domestic authority and the domestic privacy authority should accept the same reporting template and information (maybe with a different reporting frequency).
Further clarification is needed on what EBA means with “Other PSPs or relevant infrastructures potentially affected”. In our opinion it is quite clear that an incident affecting one PSP should be shared (e.g.. in a financial ISAC) with other PSPs: they could potentially experience the same attack now or in the near future. We believe that such information is not meant here. Even in the case when an incident can (potentially) directly impact other PSPs, it should be reported here.
The proposed EBA Guidelines do not elaborate on the confidentiality of the information provided to the competent authority. We believe that this information should be considered as (highly) confidential.

We advise EBA to also take into account the NIS Directive’s reporting requirements. We advise EBA to ensure that the proposed EBA Guidelines and the NIS Directive’s reporting requirements do not lead to a double administrative burden for PSP’s.
On the content of the major reporting template, we have a the following questions:
1. What is the added value as mentioned in question 4 regarding the difference between an “operational” and a “security” type of incident? In practice, it can be difficult for a PSP to make this distinction.

2. We believe “Causes of incident” is the wrong phrase. We would prefer that EBA uses the term “Event”, as this has the same meaning as the Bank of International Settlements (BIS).
3. Question 6 asks when the BCM / DRP process has been activated. This information is already requested via question 1.

If the competent authority in the Member State considers the information relevant to be shared with other PSPs: how will the competent authority take care that it will be shared with all relevant PSPs and other relevant parties?
In general, the template does not clarify what is mandatory to report and what is optional. In case of both the initial report and the intermediate report, information can still be unavailable for the reporting PSP.
In our opinion all questions, with the exception of question 1, should be considered optional for the PSP to answer.
See our answer regarding question 5 above. If EBA agrees on the reporting of “Other PSPs or relevant infrastructures potentially affected”, then we believe this should be made clear in the instructions.
Also the instruction should clarify that almost all answers to be provided by the reporting PSP are deemed optional and not mandatory (see also our answer as provided to question 5).

Additionally, we have the following remarks on the instructions:
- It is unclear what is meant by using a “Unique identification number”;
- Service downtime can only be determined afterwards and – in most cases - not yet at the moment of filing-in the initial report;
- What exactly is the purpose of reporting indirect costs to EBA? Furthermore, the indirect costs will be quite hard to estimate.
- Please add a box in the template to indicate whether the numbers are estimated or actual measured values (facts).
We consider the maximum timelines as proposed for the initial and intermediate report to be too short. They should be more flexible, case related and with a longer maximum period. Any choice for a maximum timeline is quite arbitrary, but we propose:
- A timeline of maximum 12-24 hours for the initial report
- A timeline of maximum 5 working days (excluding bank holidays and weekends) between the initial report and the intermediate report and between intermediate reports.

EBA states in the proposed EBA Guidelines that the final report needs to be sent to national competent authority after root cause analysis, without requiring this analysis to be reported. We agree that it should not be reported, since root cause analysis is part of incident management. In that line of reasoning, we argue that the final report should focus on the impact of the incident, and that final reporting should not be made dependent of the root cause analysis.

In point 2.7 of the proposed EBA Guidelines on page 27 “initial report” is mentioned And in 2.8 and 2.9 “initial notification” is mentioned. We assume that this all refers to the initial report. We advise EBA to use the same terminology since the current terminology can be quite confusing and holds the impression that a notification is required before or after the initial report.
The delegated reporting procedure potentially adds value to the market, specifically for those services that have been outsourced to other parties.
See our answer as provided to question 8
Michael Samson; Marco Doeland
31.6.5572 0696