Response to consultation on Guidelines on major incidents reporting under PSD2
Go back
We consider incident related information sharing as a useful tool, however:
- It is necessary to define in advance what kind of information will be part of the real-time information sharing scheme,
- In general, screening/assessment of the information to be shared beforehand is a must. Without the approval of the reporting ASPSP, the information should not be distributed, except perhaps in case of events of international significance.
As an example: based on “transactions affected” – according to the current practice – special, individual cases occur where the amount could reach the LEVEL 2 threshold but due to the special parameters of the transaction, the event will not be considered as an incident.
Due to the subjective nature of the criteria mentioned below, in practice every incident may be considered as major, for that reason we recommend treating these as one criterion all together or taking them into account on a less significant level:
- High level of internal escalation: it should not be considered as an adequate indicator of the severity of the incident as it is entirely based on an internal process. The Chief Information Officer (or equivalent position) will be notified according to the internal processes of the PSPs, therefore the implementation of this criterion could differ significantly. We recommend the removal or further clarification of the criterion.
- Reputational risk: it is also not an objectively measurable criterion, any incident that gets press attention, causes some kind of failure, et cetera, will inherently carry reputational risk. In our view, this point needs further clarification.
- Potential to affect other payment service providers or relevant infrastructures: from our perspective, potential effect on other PSPs may not be straightforward; also initially it cannot be identified, assessed. The “potential to affect” phrase should be further explained; also level of effect which should be positively considered is not clearly defined.
We recommend taking into account whether the negative impact of the incident can be eliminated in the short run (such as the customer changing the leaked password) or will have a lingering effect (such as the home addresses of the customers were leaked).
In case of a data breach, based on the regulation of the GDPR the incident will also have to be reported, so it would be advisable to bring the different reporting obligations in line in order to avoid duplications.
Question 1: Do you consider the definitions included in the draft Guidelines to be sufficiently clear?
The definitions do not include enough specifics, more detailed explanations would be necessary for accurate interpretations.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?
We recommend that an incident list should be published in the RTS and also available in a dropdown menu on the template. It also needs to be clarified what constitutes a separate incident (that needs to be reported as one incident) as an example: same root cause, same attack vector in a given timeframe. When determining the criteria it should also be considered that in case of subsidiaries due to their size limitations the outlined criteria and methodology cannot be interpreted correctly.We consider incident related information sharing as a useful tool, however:
- It is necessary to define in advance what kind of information will be part of the real-time information sharing scheme,
- In general, screening/assessment of the information to be shared beforehand is a must. Without the approval of the reporting ASPSP, the information should not be distributed, except perhaps in case of events of international significance.
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.
As a significant part of the Level 1 criteria is not clearly defined, incident handling will be vastly dependent on custom interpretation. Therefore we suggest developing more objective thresholds, metrics and clarifying the conditions that will have to be applied.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.
We believe that in addition to objective criteria a subjective, discretionary option should also be guaranteed for the PSPs. During the evaluation of the event, the PSPs should be able to decide whether the event is an incident even if based on the thresholds outlined in the RTS it shall be reported as a major incident. Therefore it should be taken into consideration whether the PSP itself classifies the given incident as a major incident or does not, regardless the conditions applicable from the RTS.As an example: based on “transactions affected” – according to the current practice – special, individual cases occur where the amount could reach the LEVEL 2 threshold but due to the special parameters of the transaction, the event will not be considered as an incident.
Due to the subjective nature of the criteria mentioned below, in practice every incident may be considered as major, for that reason we recommend treating these as one criterion all together or taking them into account on a less significant level:
- High level of internal escalation: it should not be considered as an adequate indicator of the severity of the incident as it is entirely based on an internal process. The Chief Information Officer (or equivalent position) will be notified according to the internal processes of the PSPs, therefore the implementation of this criterion could differ significantly. We recommend the removal or further clarification of the criterion.
- Reputational risk: it is also not an objectively measurable criterion, any incident that gets press attention, causes some kind of failure, et cetera, will inherently carry reputational risk. In our view, this point needs further clarification.
- Potential to affect other payment service providers or relevant infrastructures: from our perspective, potential effect on other PSPs may not be straightforward; also initially it cannot be identified, assessed. The “potential to affect” phrase should be further explained; also level of effect which should be positively considered is not clearly defined.
We recommend taking into account whether the negative impact of the incident can be eliminated in the short run (such as the customer changing the leaked password) or will have a lingering effect (such as the home addresses of the customers were leaked).
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 recommend employing a Web-based interface to enable PSPs to fulfil the outlined reporting obligation; also the reporting PSPs need to be properly identified before submitting documentation. It is not necessary to further expand the template, if the PSPs will have an easy option to upload additional documents, information during the reporting process. There is a need for a scorecard system which could be utilised as a starting point for estimates if quantitative data will have to be produced. Also having practical examples for this purpose might prove to be useful.In case of a data breach, based on the regulation of the GDPR the incident will also have to be reported, so it would be advisable to bring the different reporting obligations in line in order to avoid duplications.