Response to consultation on Guidelines on major incidents reporting under PSD2
Go back
The EBA document is a good attempt to have clear threshold criteria and represents a good approach on the principle (other EBA guidelines are missing this).
Worldline Group shares the objective of EBA to have a harmonized approach across the EU and prevent stricter thresholds in one country compared to others (especially considering the passporting evolution, i.e. two PSPs operating in the same country should not have different incident reporting requirements, if they are regulated by different authorities in two different countries).
But, this guideline will be of great value, only if the NCAs do not add the EBA template to their existing one for incident reporting, or their own regulatory framework imposing multiple reporting formats for the same incident and according to different criteria / thresholds. As, in a major incident management process, the focus must remain to reestablish the service, not to fill in forms.
In the EBA guideline, the current level of criteria / thresholds selected (§ 1.3 table on page 25 & 26) for the Level 1 & 2 is, to our opinion, very low especially for current Payment & E-Money Institutions. We are convinced that this will lead to a very high number of incidents reported to the NCAs.
As a consequence, it will generate for institutions and NCAs heavy reporting costs, especially the formal update character of the reporting requirements with a high frequency at the minimum every 3 days until incident resolution and the production of a full root cause analysis.
Concerning the guidelines 5 and 6, we are very concerned regarding the sharing of incident information with other NCAs, especially regarding the strict confidentiality character of the data provided between NCAs. When incident are related to security incidents, the sharing of detailed reports across NCAs and the centralization of the information at EBA/ECA represent a security concern. The security and storage of this information is not addressed at all in the EBA guideline and the legal framework around leakage of such information is totally unclear.
To our opinion, the confidentiality and protection of such sensitive incident reporting information that can depict security weakness is not addressed in the documents. So we strongly disagree with a full and automatic sharing of the information between the NCAs even in an anomisation context.
Open question that requires clarifications:
We want to stress that Worldline NV/SA (Belgian legal entity – Payment Institution), Paysquare SE and equensWorldline SE (Netherlands legal entity – PFMI under the regulation of the DNB) are under the supervision of the National Bank of Belgium and the De Nederland’s Bank, the central bank of Italy.
equensWorldline SE as processor of Worldline NV/SA wants to understand towards which regulator equensWorldline SE will have to provide the incident reporting forms. Could you clarify how this will work in the context of the lead supervisor?
The local NBB & DNB reporting forms will be harmonized within all central banks to limit the risk to have to fill in several local NCAs’ templates for the same incidents.
Regarding question1:
The definitions as provided on page 21 §13 of the document are not fully clear to us.
1) The definition of major operational or security incident can be clearer, we suggest to adapt it as such: “A singular event or a series of linked events which have (delete or may have") a material adverse impact on the integrity, availability, confidentiality, authenticity and/or continuity of payment-related services”.
2) The definition of Payment related services can also be clearer; “…. All necessary technical supporting tasks for the correct provision of the services”.
Do we have to consider as payment related services:
i) Only the On-line transaction authorization technical tasks (front end activity, when a cardholder or a merchant cannot pay or perform a SDD?)
ii) Or also the Back-office transactions services such as e.g.:
- merchant payments are not paid on the D+1 but with some delay D+2?
- the consultation of transaction history on a Merchant Extranet is not available?
- the cardholder charge back or Card stop activity is not properly working?
- the card PIN mailer activities are not working, delaying new card activation for banks?
iii) We consider that a payment related service should address the technical tasks that are directly visible on the market and affect the End Users’ usual payment activities, which perform a payment?
To our opinion the definition is too broad and not precise enough to meet the objective of the common handling in the different NCAs."
But on the list of criteria selected, we consider that some have very low threshold or are not practical enough to be useful in the decision process.
The following criteria and their underlying indicators are unclear:
1) The incident classification (page 23, transaction affected § 1.1 a)) must be updated: “Payment service providers should determine the total value of the transactions affected and (delete / or") the number of payments compromised as a percentage of the regular level of payment transactions carried out.”
The document provides inconsistencies “and/or” and this should be aligned with the chapter 3.2 item 17 a) to get a coherent document.
Regarding the threshold level for the criteria, we consider that it must be adapted to only consider 10% (for Level 1) and 25% (for level 2) of the transaction affected. The second element regarding the amount of transactions proposed: 100 K€ (Level 1) and 1.000K€ (Level 2) are so low, that for big financial Institutions this absolute criterion will be very/too often met.
This will lead to too many major incidents reporting obligations.
As an example:
- Worldline NV (PI regulated in Belgium) processed in a peak day 17K trx/min.
Let’s assume:
• a network problem of 1 minute occurs due to a system re-computing a root.
• an average trx value on a debit trx = 50€
-> this would mean that the criteria would reach an amount of 850K€ (17.000 trx missed X 50€), meaning that the conditions for major incident may be met.
The limit of a fixed amount is to our opinion not relevant and should be removed because it is far too low for significant players; we are in favor of a % base criterion.
2) The definition of client affected needs to be clarified:
i) In acquiring domain: do you consider a client as VAT numbers, number of shops affected, number of POS impacted, number of Webshops affected?
ii) In issuing domain: do you consider the number of banks, number of cards, number of smart phones and/or number of tokens?
3) The notion of "Economic impact" criteria is unclear, how can we assess these criteria during the crisis phase? “Payment service providers should determine the monetary costs associated to the incident holistically and take into account both the absolute figure and, when applicable, the relative importance of these costs in relation to the size of the payment service provider (i.e. to the payment service provider’s Tier-1 capital)”.
We understand from the definition that this criterion is referring to the cost if the incident for PSP (investment costs, forensic costs, fees for non-compliance…). We think that PSD2 article 96 §1 is looking to the impact for the End User point of view, not from the PSP cost point of view.
This economic impact criterion is, to our opinion, not part of the article 96 of the PSD2 and is not a relevant criterion to classify the incident as major or not. It should be removed from the list of criteria and annex 1 form.
Moreover, this criterion can only be assessed post incident, so it is useless to decide or not if we are facing a major incident or not. The incident cost will only be known after several months, and after the incident and resolution plan(s) will be fully implemented.
The definition in §1.2 d) page 24 is unclear, what are the “expropriate funds” and why this parameter is relevant?
4) The Level 1 Service downtime threshold > 2h should only reflect the business hours. “Payment service providers should consider both the time intervals when they are open for business as required for the execution of payment services (delete "as well as the closing hours and maintenance periods, where applicable")”. The maintenance period should be excluded from these 2 hours, as during a release all the network may be unavailable and this is not necessary due to an incident.
How do we report announced unavailability’s?
5) The "reputational criterion" is a very subjective element that will not be assessed in the same way by the different PSP. We are from the opinion that this criterion should be removed."
Our current reporting practice to the NCAs is to notify an incident when it has a visible impact for End Users that are out of SLA agreed with the customers.
We understand that the proposed definition requests to notify incidents that may not be visible on the market, so this will increase the number of reporting forms that will require a higher level of formalization.
We also consider that the down time criterion that includes the planned maintenance or the business closing period is not acceptable. This will have indirect impact on the further development of the platform that, with the coming of AIS and PIS new services, will have to face a high number of improvement and releases.
(See also our answer to Q2 that are also relevant to Q3).
1) Economic impact criteria should be removed, as it is impossible to quantify the impact at the time of the incident notification.
2) Service down time should exclude the planned maintenance and should refer to agreed SLA. It should also differentiate the business hours and the non-business hours thresholds downtime. It is not normal to report a night event in the same way as a day event.
3) The requirement to send a notification to the NCA within 2 hours of the incident first detection is too short to assess if the incident is major or not. The quantification of the incident impact needs more time, as the priority is first to assess the technical problems and the workaround solution to restore the service.
4) Reputation risk criteria should be removed; it is not a relevant parameter to assess if it is a major incident, especially social network are very volatile and not objective or manipulated by influencers.
Except for the criteria that cannot be assessed in crisis mode (cf previous question).
But, we believe it is also important to specify in the guidelines, the usage that can and will be done by the NCAs and the EBA/ECB with all the information. What are the confidentiality and protection that will be granted to this very competitive information?
We want to understand what will be the consequences if the reporting document(s) cannot be filled in due time (at incident, during the incident, post incident).
We have recognized that page 26 §2.2 provide flexibility as the report must be completed on a “best effort basis” and incremental process.
Regarding the final report (page 28 § 2.16) “Payment service providers should send a final report when the root cause analysis has taken place (regardless whether mitigation measures have already been implemented or the final root cause has been identified) and there are actual figures available to replace any potential estimates when possible “.
It is important to note that for some type of incidents (e.g. during a front office incident impacting transaction authorization or an Internet network incident), you may never get the exact figures of the missed transactions and that most of the figures will remain estimates even in the final report.
Regarding the delay to produce the final report (page 28 §2.17), which must be available within 2 weeks after the incident and the situation is back to normal, it is to our opinion too short to be able to provide a complete report that is valuable. Payment systems are complex systems and the analysis of the root cause analysis can take several weeks to explain the issue and validate the solution and plan the implementation of the changes.
We propose to amend the text and to provide the final report within 2 weeks after the root cause report has been issued.
It must remain the responsibility and accountability of the PSP to manage its processors and to control its critical outsourcing partner, to establish the proper governance to get the right level on information in case of incident.
It must remain the responsibility and accountability of the PSP to manage its processors and to control its critical outsourcing partner, to establish the proper governance to get the right level on information in case of incident.
Question 1: Do you consider the definitions included in the draft Guidelines to be sufficiently clear?
General commentsThe EBA document is a good attempt to have clear threshold criteria and represents a good approach on the principle (other EBA guidelines are missing this).
Worldline Group shares the objective of EBA to have a harmonized approach across the EU and prevent stricter thresholds in one country compared to others (especially considering the passporting evolution, i.e. two PSPs operating in the same country should not have different incident reporting requirements, if they are regulated by different authorities in two different countries).
But, this guideline will be of great value, only if the NCAs do not add the EBA template to their existing one for incident reporting, or their own regulatory framework imposing multiple reporting formats for the same incident and according to different criteria / thresholds. As, in a major incident management process, the focus must remain to reestablish the service, not to fill in forms.
In the EBA guideline, the current level of criteria / thresholds selected (§ 1.3 table on page 25 & 26) for the Level 1 & 2 is, to our opinion, very low especially for current Payment & E-Money Institutions. We are convinced that this will lead to a very high number of incidents reported to the NCAs.
As a consequence, it will generate for institutions and NCAs heavy reporting costs, especially the formal update character of the reporting requirements with a high frequency at the minimum every 3 days until incident resolution and the production of a full root cause analysis.
Concerning the guidelines 5 and 6, we are very concerned regarding the sharing of incident information with other NCAs, especially regarding the strict confidentiality character of the data provided between NCAs. When incident are related to security incidents, the sharing of detailed reports across NCAs and the centralization of the information at EBA/ECA represent a security concern. The security and storage of this information is not addressed at all in the EBA guideline and the legal framework around leakage of such information is totally unclear.
To our opinion, the confidentiality and protection of such sensitive incident reporting information that can depict security weakness is not addressed in the documents. So we strongly disagree with a full and automatic sharing of the information between the NCAs even in an anomisation context.
Open question that requires clarifications:
We want to stress that Worldline NV/SA (Belgian legal entity – Payment Institution), Paysquare SE and equensWorldline SE (Netherlands legal entity – PFMI under the regulation of the DNB) are under the supervision of the National Bank of Belgium and the De Nederland’s Bank, the central bank of Italy.
equensWorldline SE as processor of Worldline NV/SA wants to understand towards which regulator equensWorldline SE will have to provide the incident reporting forms. Could you clarify how this will work in the context of the lead supervisor?
The local NBB & DNB reporting forms will be harmonized within all central banks to limit the risk to have to fill in several local NCAs’ templates for the same incidents.
Regarding question1:
The definitions as provided on page 21 §13 of the document are not fully clear to us.
1) The definition of major operational or security incident can be clearer, we suggest to adapt it as such: “A singular event or a series of linked events which have (delete or may have") a material adverse impact on the integrity, availability, confidentiality, authenticity and/or continuity of payment-related services”.
2) The definition of Payment related services can also be clearer; “…. All necessary technical supporting tasks for the correct provision of the services”.
Do we have to consider as payment related services:
i) Only the On-line transaction authorization technical tasks (front end activity, when a cardholder or a merchant cannot pay or perform a SDD?)
ii) Or also the Back-office transactions services such as e.g.:
- merchant payments are not paid on the D+1 but with some delay D+2?
- the consultation of transaction history on a Merchant Extranet is not available?
- the cardholder charge back or Card stop activity is not properly working?
- the card PIN mailer activities are not working, delaying new card activation for banks?
iii) We consider that a payment related service should address the technical tasks that are directly visible on the market and affect the End Users’ usual payment activities, which perform a payment?
To our opinion the definition is too broad and not precise enough to meet the objective of the common handling in the different NCAs."
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?
The high level methodology mechanics such as the Level 1 and the Level 2 criteria are clear: a major incident is when 3 or more criteria Level 1 are met or 1 or more Level 2 criteria are met.But on the list of criteria selected, we consider that some have very low threshold or are not practical enough to be useful in the decision process.
The following criteria and their underlying indicators are unclear:
1) The incident classification (page 23, transaction affected § 1.1 a)) must be updated: “Payment service providers should determine the total value of the transactions affected and (delete / or") the number of payments compromised as a percentage of the regular level of payment transactions carried out.”
The document provides inconsistencies “and/or” and this should be aligned with the chapter 3.2 item 17 a) to get a coherent document.
Regarding the threshold level for the criteria, we consider that it must be adapted to only consider 10% (for Level 1) and 25% (for level 2) of the transaction affected. The second element regarding the amount of transactions proposed: 100 K€ (Level 1) and 1.000K€ (Level 2) are so low, that for big financial Institutions this absolute criterion will be very/too often met.
This will lead to too many major incidents reporting obligations.
As an example:
- Worldline NV (PI regulated in Belgium) processed in a peak day 17K trx/min.
Let’s assume:
• a network problem of 1 minute occurs due to a system re-computing a root.
• an average trx value on a debit trx = 50€
-> this would mean that the criteria would reach an amount of 850K€ (17.000 trx missed X 50€), meaning that the conditions for major incident may be met.
The limit of a fixed amount is to our opinion not relevant and should be removed because it is far too low for significant players; we are in favor of a % base criterion.
2) The definition of client affected needs to be clarified:
i) In acquiring domain: do you consider a client as VAT numbers, number of shops affected, number of POS impacted, number of Webshops affected?
ii) In issuing domain: do you consider the number of banks, number of cards, number of smart phones and/or number of tokens?
3) The notion of "Economic impact" criteria is unclear, how can we assess these criteria during the crisis phase? “Payment service providers should determine the monetary costs associated to the incident holistically and take into account both the absolute figure and, when applicable, the relative importance of these costs in relation to the size of the payment service provider (i.e. to the payment service provider’s Tier-1 capital)”.
We understand from the definition that this criterion is referring to the cost if the incident for PSP (investment costs, forensic costs, fees for non-compliance…). We think that PSD2 article 96 §1 is looking to the impact for the End User point of view, not from the PSP cost point of view.
This economic impact criterion is, to our opinion, not part of the article 96 of the PSD2 and is not a relevant criterion to classify the incident as major or not. It should be removed from the list of criteria and annex 1 form.
Moreover, this criterion can only be assessed post incident, so it is useless to decide or not if we are facing a major incident or not. The incident cost will only be known after several months, and after the incident and resolution plan(s) will be fully implemented.
The definition in §1.2 d) page 24 is unclear, what are the “expropriate funds” and why this parameter is relevant?
4) The Level 1 Service downtime threshold > 2h should only reflect the business hours. “Payment service providers should consider both the time intervals when they are open for business as required for the execution of payment services (delete "as well as the closing hours and maintenance periods, where applicable")”. The maintenance period should be excluded from these 2 hours, as during a release all the network may be unavailable and this is not necessary due to an incident.
How do we report announced unavailability’s?
5) The "reputational criterion" is a very subjective element that will not be assessed in the same way by the different PSP. We are from the opinion that this criterion should be removed."
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.
We consider the methodology as currently proposed will capture much more incidents than the incidents that are currently consider as major ones and reported to the NCA.Our current reporting practice to the NCAs is to notify an incident when it has a visible impact for End Users that are out of SLA agreed with the customers.
We understand that the proposed definition requests to notify incidents that may not be visible on the market, so this will increase the number of reporting forms that will require a higher level of formalization.
We also consider that the down time criterion that includes the planned maintenance or the business closing period is not acceptable. This will have indirect impact on the further development of the platform that, with the coming of AIS and PIS new services, will have to face a high number of improvement and releases.
(See also our answer to Q2 that are also relevant to Q3).
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 consider the levels of the criteria threshold are very low and some of them must be removed or put higher.1) Economic impact criteria should be removed, as it is impossible to quantify the impact at the time of the incident notification.
2) Service down time should exclude the planned maintenance and should refer to agreed SLA. It should also differentiate the business hours and the non-business hours thresholds downtime. It is not normal to report a night event in the same way as a day event.
3) The requirement to send a notification to the NCA within 2 hours of the incident first detection is too short to assess if the incident is major or not. The quantification of the incident impact needs more time, as the priority is first to assess the technical problems and the workaround solution to restore the service.
4) Reputation risk criteria should be removed; it is not a relevant parameter to assess if it is a major incident, especially social network are very volatile and not objective or manipulated by influencers.
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 consider that the report in Annex 1 is very detailed, and will provide a suitable picture.Except for the criteria that cannot be assessed in crisis mode (cf previous question).
But, we believe it is also important to specify in the guidelines, the usage that can and will be done by the NCAs and the EBA/ECB with all the information. What are the confidentiality and protection that will be granted to this very competitive information?
We want to understand what will be the consequences if the reporting document(s) cannot be filled in due time (at incident, during the incident, post incident).
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.
We consider that the report in Annex 1 and the explanation are sufficiently detailed, but do not give any guarantee that it will be interpreted in the same way by different PSP as some of the criteria remain subjective.We have recognized that page 26 §2.2 provide flexibility as the report must be completed on a “best effort basis” and incremental process.
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.
We consider that reporting and updating the NCA on the initial report at the demand of the NCA and at a minimum every 3 business days is a very constraining obligation, especially when you have to manage and solve a major incident. To our opinion the NCA reporting update could be done in an informal way, but not by producing a detailed incident report all the time, as this will impact the resolution time (especially in small PSP).Regarding the final report (page 28 § 2.16) “Payment service providers should send a final report when the root cause analysis has taken place (regardless whether mitigation measures have already been implemented or the final root cause has been identified) and there are actual figures available to replace any potential estimates when possible “.
It is important to note that for some type of incidents (e.g. during a front office incident impacting transaction authorization or an Internet network incident), you may never get the exact figures of the missed transactions and that most of the figures will remain estimates even in the final report.
Regarding the delay to produce the final report (page 28 §2.17), which must be available within 2 weeks after the incident and the situation is back to normal, it is to our opinion too short to be able to provide a complete report that is valuable. Payment systems are complex systems and the analysis of the root cause analysis can take several weeks to explain the issue and validate the solution and plan the implementation of the changes.
We propose to amend the text and to provide the final report within 2 weeks after the root cause report has been issued.
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.
No, there is no added value to delegate the incident reporting procedure towards its outsourcing partner.It must remain the responsibility and accountability of the PSP to manage its processors and to control its critical outsourcing partner, to establish the proper governance to get the right level on information in case of 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.
No, there is no added value to have a consolidation process of the incident reporting procedure towards its outsourcing partner.It must remain the responsibility and accountability of the PSP to manage its processors and to control its critical outsourcing partner, to establish the proper governance to get the right level on information in case of incident.