Response to consultation paper on the draft revised Guidelines on major incident reporting under PSD2
Go back
We would, however, like to point out that focussing on relative thresholds makes more sense and is more meaningful (in line with the internal classification of incidents).
We believe this also makes sense for the higher impact level.
In addition, the condition “downtime >1 hour” should also be considered for security incidents (except external attacks).
We also suggest adapting the condition “downtime >1 hour” to the criteria “service downtime >2 hours”, thereby providing for a uniform duration of >2 hours.
This would enable identification processes to be standardised and simplified.
In contrast, the condition “or” instead of “and” does not reduce the burden.
We see this more as a tightening of the conditions and as such we believe “and” should remain as before.
Otherwise, we would be in favour of removing the absolute thresholds.
However, the criterion “Breach of security measures” does not meet this requirement since, for us, it is not clear.
This new criterion is also redundant because any breaches of security measures that require reporting are covered by the existing criterion “High level of internal escalation”.
This criterion should therefore not be introduced.
Alternatively, this new criterion needs to be defined more specifically.
We believe they are a sensible way of addressing deficiencies and simplifying the reporting process.
The requirements of the revised guidelines should be taken into account in the DORA proposal, for example, with regard to alignment of criteria, templates and reporting processes.
In addition, given current developments, the application date for the revised guidelines should be postponed until 1 January 2022.
At the same time, other common formats such as MS Excel or PDF should also be supported.
In addition, existing reporting channels must continue to be supported as they are already being used effectively by both parties (BaFin’s MVP portal).
2.7: We are in favour of specifying “from the moment of classification as a major incident” instead of “detection of the incident”.
2.12: No comments (in our opinion, this is not a simplification).
2.14: No comments.
2.18: We welcome the deadline extension.
It should be possible either to leave a field empty or mark it as “not available”.
Also, the sub-categories for causes of incidents are too granular and it is sometimes difficult to differentiate between them.
With a view to additional future reporting requirements, e.g. from the DORA Regulation, we would welcome more consistent harmonisation of reporting requirements in general.
Q1. Do you agree with the change proposed in Guideline 1.4 to the absolute amount threshold of the criteria ‘Transactions affected’ in the higher impact level?
We agree with the proposed increase to the absolute amount threshold.We would, however, like to point out that focussing on relative thresholds makes more sense and is more meaningful (in line with the internal classification of incidents).
Q2. Do you agree with the changes proposed in Guideline 1.4 to the assessment of the criteria ‘Transactions affected’ and ‘Payment service users affected’ in the lower impact level, including the introduction of the condition that the operational incidents must have a duration longer than one hour?
We welcome the introduction of the condition “downtime >1 hour” for both criteria.We believe this also makes sense for the higher impact level.
In addition, the condition “downtime >1 hour” should also be considered for security incidents (except external attacks).
We also suggest adapting the condition “downtime >1 hour” to the criteria “service downtime >2 hours”, thereby providing for a uniform duration of >2 hours.
This would enable identification processes to be standardised and simplified.
In contrast, the condition “or” instead of “and” does not reduce the burden.
We see this more as a tightening of the conditions and as such we believe “and” should remain as before.
Otherwise, we would be in favour of removing the absolute thresholds.
Q3. Do you agree with the inclusion of the new criterion ‘Breach of security measures’ in Guidelines 1.2, 1.3 and 1.4?
In principle, we are in favour of using/introducing clearly quantifiable values/criteria.However, the criterion “Breach of security measures” does not meet this requirement since, for us, it is not clear.
This new criterion is also redundant because any breaches of security measures that require reporting are covered by the existing criterion “High level of internal escalation”.
This criterion should therefore not be introduced.
Alternatively, this new criterion needs to be defined more specifically.
Q4. Do you agree with the proposed changes to the Guidelines aimed at addressing the deficiencies in the reporting process?
We welcome the proposed changes to the guidelines.We believe they are a sensible way of addressing deficiencies and simplifying the reporting process.
The requirements of the revised guidelines should be taken into account in the DORA proposal, for example, with regard to alignment of criteria, templates and reporting processes.
In addition, given current developments, the application date for the revised guidelines should be postponed until 1 January 2022.
Q5. Do you support the introduction of a standardised file for submission of incident reports from payment service providers to national competent authorities? If so, what type of structured file format would you support (e.g. “MS Excel”, “xbrl”, “xml”) and why?
We are in favour of submitting incident reports in a structured file format, such as “xml”. This simplifies integration into internal bank reporting processes and would continue to make it possible to export them into other formats thanks to widely used IT modules.At the same time, other common formats such as MS Excel or PDF should also be supported.
In addition, existing reporting channels must continue to be supported as they are already being used effectively by both parties (BaFin’s MVP portal).
Q6. Do you agree with the proposed changes to Guidelines 2.4, 2.7, 2.12, 2.14, and 2.18 that are aimed at simplifying the process of reporting major incidents under PSD2?
2.4: No comments2.7: We are in favour of specifying “from the moment of classification as a major incident” instead of “detection of the incident”.
2.12: No comments (in our opinion, this is not a simplification).
2.14: No comments.
2.18: We welcome the deadline extension.
Q7. Do you agree with the proposed changes to the templates in the Annex to the Guidelines?
We don’t think it will always be possible to fill in all the proposed fields in the template for all types of incidents.It should be possible either to leave a field empty or mark it as “not available”.
Also, the sub-categories for causes of incidents are too granular and it is sometimes difficult to differentiate between them.
With a view to additional future reporting requirements, e.g. from the DORA Regulation, we would welcome more consistent harmonisation of reporting requirements in general.