Circulaire CSSF 18/704 — Abrogée par la circulaire CSSF 21/787

(1)de la loi modifiée du 10 novembre 2009 qui dispose qu’ « en cas d’incident opérationnel ou de sécurité majeur, les prestataires de services de paiement informent sans retard injustifié la CSSF » ; notamment en ce qui concerne le processus de notification à la CSSF.

1. Les Orientations ABE Les Orientations spécifient, en particulier, les critères pour la classification des incidents opérationnels ou de sécurité majeurs par les prestataires de services de paiement (ci-après les « PSP ») ainsi que le format et les procédures que ces derniers devraient appliquer pour informer l’autorité compétente dans l’Etat membre d’origine. Les Orientations s’appliquent à tous les incidents couverts par la définition d’ « incident opérationnel ou de sécurité majeur », qui englobe les évènements externes et internes qui pourraient être malveillants ou accidentels. Les Orientations s’appliquent également lorsque l’incident opérationnel ou de sécurité majeur trouve son origine en dehors de l’Union européenne et affecte les services de paiement fournis par un PSP situé dans l’Union européenne soit directement soit indirectement. Il convient de se référer au texte complet des Orientations en ce qui concerne les définitions applicables, la classification des incidents opérationnels ou de sécurité majeurs, ou tout autre point relatif au processus de notification à suivre. L’annexe 1 des Orientations contient les modèles de notification à utiliser par les PSP.
2. Instructions techniques pour le processus de notifications à la CSSF Les instructions techniques détaillées pour transmettre les données à la CSSF figurent à l’annexe 1 de la présente circulaire.
3. Les délais requis pour la notification à la CSSF Les PSP devraient soumettre une notification initiale à la CSSF dans les 4 heures suivant la détection de l’incident opérationnel ou de sécurité majeur. Les PSP devraient soumettre des notifications intermédiaires chaque fois qu’ils considèrent qu’il y a une mise à jour pertinente du statut et, au minimum, à la date de la prochaine mise à jour indiquée dans la notification précédente (notification initiale ou notification intermédiaire). Les PSP devraient remettre leur notification finale à la CSSF dans un délai maximum de deux semaines après que l’activité soit considérée comme revenue à la normale. Il convient de se référer au texte complet des Orientations concernant les détails relatifs aux différentes étapes de notification requises.
4. Délégation des obligations de notification à un tiers Une délégation des obligations de notifications d’un incident opérationnel ou de sécurité majeur à un tiers n’est pas admissible.
5. Entrée en vigueur et application La présente circulaire, par laquelle la CSSF adopte les Orientations, entre en vigueur avec effet immédiat. Les Orientations sont annexées à la présente circulaire et sont disponibles sur le site de l’ABE à l’adresse suivante : http://www.eba.europa.eu/documents/10180/1914076/Guidelines+on+incident+reporting+un der+PSD2+%28EBA-GL-2017-10%29.pdf/3902c3db-c86d-40b7-b875-dd50eec87657 Circulaire CSSF 18/704 Page 2/6 Veuillez recevoir, Mesdames, Messieurs, l’assurance de nos sentiments très distingués. COMMISSION de SURVEILLANCE du SECTEUR FINANCIER Marco ZWICK Directeur Jean-Pierre FABER Directeur Claude SIMON Directeur Françoise KAUTHEN Directeur Claude MARX Directeur général Annexes Circulaire CSSF 18/704 Page 3/6 Annexe 1: Instructions techniques pour l’envoi des fichiers Pour la transmission des données à la CSSF, les entités rapportantes doivent utiliser le template disponible sur le site CSSF sous: https://www.cssf.lu/fr/Document/notification-incidents-majeurs/ Instructions de remise Le rapport principal doit être une copie du fichier “.xlsx” ci-dessus remplie avec les données de l’incident. Le fichier ci-dessus est préformaté et sa structure ne doit être modifiée de quelque façon que ce soit par les entités rapportantes. Les fichiers annexes au rapport principal peuvent avoir des extensions tyiques d’application de type Office (“.pdf”, “.docx”, etc) Tous les fichiers doivent être envoyés à la CSSF via un canal de transmission selon la circulaire CSSF 08/
6. La convention de nom à utiliser est OTH. La structure de nom générale à utiliser est (voir détails ci-dessous) : OTHREP-ENNNN-MAJINCREP-YYYYMMDDHHMM-AAAA.extension Exemples: OTHREP-B0999-MAJINCREP-201901301700-0000.xlsx Pour le document principal du rapport d’incident remis par la banque B999 pour un incident du 30 janvier 2019 à 17:00 OTHREP-B0999-MAJINCREP-201901301700-0001.pdf Pour une première annexe au document principal du rapport d’incident ci-dessus OTHREP-W0999-MAJINCREP-201901301700-0000.xlsx Pour le document principal du rapport d’incident remis par l’établissement de monnaie électronique W999 pour un incident du 30 janvier 2019 à 17:00 Remarque: si une nouvelle version du rapport principal ou d’une autre annexe doit être envoyée pour refléter une évolution de la situation, le même numéro d’annexe que pour l’envoi précédent sera réutilisé. Circulaire CSSF 18/704 Page 4/6 Signification : Code Signification Structure Valeurs autorisées TYR Type de rapport Char

(3)Constante ‘OTH’ DIR Direction Char

(3)‘REP’ pour Report  fichier vers CSSF ‘FBR’ pour accusé de réception  confirmation de bonne réception par la CSSF à l’entité rapportante - Séparateur Char

(1)Constante ‘-’ (tiret) E Entité Char

(1)Tout type d’entité assigné par la CSSF, p.ex. ‘B’ pour Banques, ‘P’ for PSF, ‘W’ pour établissements de monnaie électronique, … NNNN CSSF ID Number

(4)0001…9999 Identifiant de l’entité assigné par la CSSF - Séparateur Char

(1)Constante ‘-’ (tiret) TTTTTTTTT TYPE Char

(9)La seule valeur autorisée est ‘MAJINCREP’ (Major Incident Report). - Séparateur Char

(1)Constante ‘-’ (tiret) YYYYMMDDHHMM Date et heure identifiant l’incident Number

(12)in format YYYYMMDDHHMM Timestamp représentant la date et l’heure de l’incident identifiant l’ensemble de tous les documents qui s’y rapportent p.ex. ‘201901301700’ pour un incident du 30 janvier 2019 à 17:00. (ce timestamp servira de clé/identifiant de l’incident et sera Circulaire CSSF 18/704 Page 5/6 réutilisé pour toutes les annexes de l’ensemble de documents) - Séparateur Char

(1)Constante ‘-’ (tiret) AAAA Annexe Number

(4)0001…9999 L’annexe 0000 sera le document principal de l’ensemble de documents (le template ci-dessus à télécharger du site CSSF), 0001 à 9999 peuvent être utilisées pour des annexes supplémentaires au document principal Ext Extension Char

(5)L’annexe 0000 est en .xlsx (téléchargé du site CSSF). En general, toutes les extensions “Office” sont permises pour les autres annexes (“.pdf”, “.docx”, etc.). Circulaire CSSF 18/704 Page 6/6 EBA/GL/2017/10 27/07/2017 Final Report Guidelines on major incident reporting under Directive (EU) 2015/2366 (PSD2) FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER PSD2 Abbreviations AISP Account information service provider ASPSP Account servicing payment services provider B2B Business to Business B2C Business to Consumer CA Competent Authority CEBS Committee of European Banking Supervisors EBA European Banking Authority ECB European Central Bank EMD Electronic Money Directive GL Guideline PISP Payment initiation services provider PSD2 Payment Services Directive (EU) 2015/2366 PSP Payment services provider SSM Single Supervisory Mechanism TPPs Third Party Providers 2 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER PSD2 Contents 1. Executive Summary 4 2. Background and rationale 5 2.1. Background 5 2.2. Rationale 6 3. Guidelines 14 4. Accompanying documents 45 4.1. Cost-benefit analysis / impact assessment 45 4.2. Feedback on the public consultation 49 3 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER PSD2 1. Executive Summary Article 96

(3)of Directive (EU) 2015/2366 on Payment Services in the Internal Market (PSD2) confers on the European Banking Authority (EBA) the mandate to develop, in close cooperation with the European Central Bank (ECB), Guidelines addressed to payment services providers (PSP) on the classification and notification of major operational or security incidents, and to competent authorities on the criteria to assess their relevance and the details to be shared with other domestic authorities. To fulfil this mandate, the EBA and the ECB have assessed existing scenarios and practices as regards incident reporting and have produced the Guidelines included in this Final Report. These Guidelines set out the criteria, thresholds and methodology to be used by payment service providers to determine whether or not an operational or security incident should be considered major and, therefore, be notified to the competent authority in the home Member State. Moreover, these Guidelines establish the template that payment service providers will have to use for this notification and the reports they have to send during the lifecycle of the incident, including the timeframe to do so. To ensure that current practices are reflected to the greatest extent possible, these Guidelines also allow for the possibility that payment service providers delegate their incident-reporting obligations to a third party, provided that a number of conditions are met. Furthermore, the Guidelines give payment service providers the possibility of reporting their incidents through a service provider in a way that is consolidated with other affected payment service providers, provided that the incident originates within said provider. Furthermore, these Guidelines establish a set of criteria that competent authorities have to use as primary indicators when assessing the relevance of a major operational or security incident to other domestic authorities in the context of PSD2. Moreover, they detail the information that, as a minimum, competent authorities should share with these domestic authorities when an incident is considered of relevance for the latter. Finally, for the purposes of promoting a common and consistent approach, these Guidelines also establish requirements regarding the reporting process envisaged in Article 96

(2)of PSD2 between competent authorities in the home Member State and the EBA/ECB. To seek the views of the market, the EBA published a Consultation Paper on the draft Guidelines on major incident reporting on 7 December

1. The consultation ran for three months, and 43 responses were received. Following analysis of the comments put forward by the market, the EBA has made some amendments to the draft Guidelines, in particular as regards further defining the criteria, reviewing one of the thresholds, extending the deadline for the first report, streamlining the amount of information to be provided at that stage and generally clarifying the information to be provided in each of the reports. 4 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER PSD2
2. Background and rationale 2.
3. Background
4. Article 96 of Directive (EU) 2015/2366 on payment services in the internal market (PSD2) requires payment service providers to establish a framework to maintain effective incident management procedures, including for the detection and classification of major operational or security incidents.
5. As part of this framework, and to ensure that damage to users, other payment service providers or payment systems is kept to a minimum, Article 96 lays down that payment service providers shall report major operational or security incidents to the competent authority in their home Member State without undue delay. It is also expected that this competent authority, after assessing the relevance of the incident to other relevant domestic authorities, will notify them accordingly.
6. To achieve this aim, Article 96

(3)of PSD2 confers a mandate on the EBA to develop, in close coordination with the ECB and after consulting all relevant stakeholders, including those in the payment services market, Guidelines in accordance with Article 16 of the EBA Regulation (EU) addressed to each of the following: a. payment service providers, on the classification of major operational or security incidents and on the content, the format, including standard notification templates, and the procedures for notifying such incidents; b. competent authorities, on the criteria for how to assess the relevance of the incident and the details of the incident reports to be shared with other domestic authorities.

1. In addition, PSD2 assigns to the EBA and the ECB a central coordination role in this context in relation to other relevant EU and national authorities. The Directive provides that the competent authority in the home Member State swiftly shares with the EBA and the ECB relevant details of the incident, that a collective assessment of its significance for these other Union and national authorities is performed and that, where appropriate, the EBA and the ECB notify them accordingly.
2. On 7 December 2016 the EBA launched a consultation on the draft Guidelines on major incident reporting, which ended on 7 March
3. The EBA received 43 responses to the Consultation Paper, 36 of which gave permission for the EBA to publish them on the EBA website. In what follows in the rationale section below, this Final Report summarises the comments received and the decisions that the EBA has taken. 5 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER PSD2 2.
4. Rationale
5. The EBA has assessed all the responses and has arrived at the main conclusions set out below, which are presented using the structure of the Guidelines: they start with the definitions, followed by the Guidelines addressed to payment service providers, and finish with some general comments, some of which refer to the Guidelines addressed to competent authorities. Additional, more detailed, feedback to all concerns received is provided in the feedback table in Chapter 4.2 of this Final Report. Definitions
6. In general, the definitions seemed to be clear enough, although several respondents proposed adopting definitions from international standards to ensure a common understanding and reduce the burden on firms. Furthermore, there were some suggestions aiming to improve the clarity of the definitions by, for instance, specifying further the scope of ‘major operational or security incident’ or defining more precisely the five dimensions that could be affected. Several respondents also favoured focusing the definition on ‘operational or security incident’ instead of on ‘major operational or security incident’.
7. The EBA has assessed the comments received and notes that the definitions are generally based on international standards, although it acknowledges that there is not an exact correlation. The reason for this is that they had to be adapted to the scope of PSD2, on which the EBA’s mandate is based. The EBA particularly relied on international standards for the definition of the five dimensions, and that is why the EBA considers they should remain unchanged. The only exception would be the term ‘continuity’, since the definition of this term does not come from any international standard, and the EBA acknowledges that it could be confused with the concept of ‘availability’. Therefore, the EBA has further clarified it to avoid misunderstandings. The other main change as regards the dimensions is the replacement of the word ‘client’ with ‘payment service user’ in the definition of ‘availability’ and throughout the Guidelines, since it led to confusion. Over and above, by relying on the latter term, the Guidelines manage to align even more closely with PSD
9. As regards the suggestion to specify the scope of ‘major operational or security incident’, the EBA concludes that part of the confusion came from the Background and Rationale section of the Consultation Paper and, hence, there is no need to clarify further in the Guidelines that all major operational or security incidents affecting payment services or any tasks needed to carry them out are included under their scope. 10.Also, to avoid confusion, the Guidelines have been amended so that the definition section now refers to the broader concept of ‘incidents’, while the criteria for the classification of the subset of incidents that are ‘major’ are set out separately in Guideline
10. Relatedly, the scope of application section has been amended to clarify that all external and internal events that have not been planned by the payment service provider would be included in the definition, bearing in mind that these could be either malicious or accidental. 6 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER PSD2 11.Finally, the EBA has assessed the proposal to define ‘operational or security incident’ instead of ‘major operational or security incident’, but has discarded the idea, since the EBA believes that the term that needs to be defined in the Guidelines is the one that PSD2 refers to. Nevertheless, the definition has been amended to improve clarity by dropping the term ‘material’ and explaining further what ‘major’ is. 12.A specific comment on the definition of ‘major operational or security incident’ was also received, namely that it should not include incidents that have only a potential (not materialised) major impact. The EBA, however, could not take this proposal fully on board, since it would go against the spirit of PSD2, i.e. that the competent authority in the home Member State is informed of a major operational or security incident as soon as possible. The Guidelines, however, now clarify that incidents that could have been major but are resolved before they reach that point (i.e. ’near misses’) are not included and, hence, do not need to be reported. Furthermore, the revised definition limits the range of potential incidents to be reported by replacing the term ‘may have [impact]’ with ‘will probably have [impact]’. Criteria, thresholds and methodology 13.A majority of the respondents considered that the proposal would result in a higher number of incidents being classified as major than is currently the case. The main arguments put forward were the use of qualitative criteria (which, in addition, were considered too broadly defined) and the use of absolute values as thresholds (in particular as regards ‘transactions affected’). Respondents therefore suggested removing both the qualitative criteria (or at least specifying them further) and the absolute thresholds (or else significantly increasing them). There was also a suggestion to remove the ‘economic impact’ criterion, since it was considered too difficult to estimate (in particular, the indirect costs). 14.A few respondents also suggested laying down that a given condition must be met if an incident is to be classified as major, regardless of whether the criteria are fulfilled or not, and others proposed having a second layer of assessment by senior management to ensure that only the actually relevant incidents are reported. It is also worth mentioning that some respondents pointed out that the terms ‘Level 1’ and ‘Level 2’ were counterintuitive. Moreover, a few of them expressed doubts about whether the use of cumulative thresholds in Level 1 and non-cumulative in Level 2 was intentional or not and, if so, what its goal was. 15.The EBA has assessed all these comments and wishes to highlight that qualitative criteria are widely used in the current reporting frameworks at local level, with apparently no issues. Furthermore, the EBA considers these criteria to be a very good complement of the quantitative ones, since they help provide a more accurate assessment of the incident on the basis of past experience at times when actual data (i.e. figures) on the impact of the incident may not be easily available. The EBA acknowledges, however, that the way the qualitative criteria should be assessed could be specified further, and has therefore introduced several clarifications in Guideline 1.
11. The EBA also considers that the ‘economic impact’ criterion should remain, since it is consistent with the EU’s Single Supervisory Mechanism SSM’s approach and gives an additional dimension about the relevance of the incident, but has introduced a nuance in the way it should 7 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER PSD2 be measured in order to make it easier. In any case, the EBA notes that the use of estimations and educated guesses is possible when assessing whether or not an incident is major. 16.As regards the thresholds, the EBA has taken note of the potential confusion introduced by the terms ‘Level 1’ and ‘Level 2’ and has replaced them with ‘Lower impact level’ and ‘Higher impact level’. The EBA is also of the view that cumulative versus alternative thresholds, where applicable, introduce proportionality. This allows the striking of an important and necessary balance between both smaller and larger payment service providers, so the EBA has made the necessary amendments to the Guidelines to highlight where and when PSPs should take them into account simultaneously or not. 17.Furthermore, the EBA has reassessed the possibility of removing the absolute thresholds, but is still of the opinion that they are necessary to ensure a level playing field between smaller and larger payment service providers. The EBA has also explored the possibility of increasing the ‘Higher impact level’ thresholds, since those are in principle the ones that could lead to overreporting, and has concluded that the threshold associated with ‘transactions affected’ could indeed be too low on account of the nature of Business-to business (B2B) payments. As a result, the EBA has raised it to EUR 5 million. 18.Finally, and contrary to the suggestions made by some respondents, the EBA has decided not to introduce any type of particular condition beyond the chosen criteria. In fact, the EBA believes that most of the suggested conditions would already be covered by the criteria considered in the Guidelines. Likewise, the EBA is against allowing payment service providers to somehow override the conclusions of the assessment on the basis of a subjective decision, since the main purpose of the Guidelines is precisely to harmonise the classification and reporting of major incidents for all payment service providers. 19.Several comments were also received on the methodology for assessing the different criteria (beyond the request to further specify the qualitative ones) as well as on the way they should be combined to conclude whether the incident is major or not. As regards the former, a large majority of respondents considered that more instructions were needed on how to calculate 'transactions affected' and 'clients (now payment service users) affected’. As regards the latter, a few respondents questioned the chosen number of criteria needed for an incident to qualify as major and others requested further clarity by, for instance, including Diagram 1 in the Guidelines. In addition, a number of respondents considered that more clarity was needed on whether the thresholds would actually have to be exceeded or the mere possibility of their being exceeded at some point in the future would suffice in view of the classification process. 20.The EBA acknowledges that the way the criteria should be measured was not detailed enough, and has therefore expanded Guideline 1.2 to clarify the different issues put forward by the respondents. Furthermore, the EBA considers that the requirement to fulfil three criteria at the ‘Lower impact level’ strikes an important and necessary balance between smaller and larger payment service providers and between quantitative and qualitative criteria. As regards the possibility of introducing the diagram in the Guidelines, the EBA notes that diagrams are not meant to be part of a set of actual EBA Guidelines, but it has kept it in the Rationale section for clarity. Finally, the EBA has amended Guidelines 1.3 and 1.4 to explain that, to assess whether or 8 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER PSD2 not an incident should be labelled as major, payment service providers should consider both if the thresholds are reached and if there is a possibility that they will be reached before the incident is resolved. Diagram 1: Decision tree for assessing whether or not an operational or security incident is major MAJOR INCIDENT Y Are 1 or more ‘Higher impact level’ criteria fulfilled? N MAJOR INCIDENT Y Are 3 or more ‘Lower impact level’ criteria fulfilled? N NON- MAJOR INCIDENT Legend: If an incident meets or will probably meet one or more ‘Higher impact level’ thresholds, it qualifies as major. If an incident does not meet and probably will not meet any ‘Higher impact level’ thresholds, but meets or will probably meet 3 or more ‘Lower impact level’ thresholds, it qualifies as major. If an incident does not meet and probably will not meet any ‘Higher impact level’ thresholds and does not meet and probably will not meet at least three ‘Lower impact level’ thresholds, it does not qualify as major. 21.Over and above those, a few respondents made suggestions along the lines of applying criteria and/or thresholds in a way that differentiates between categories of payment service providers on the basis of the type of payment service that they provide (e.g. to consider the downtime of the ASPSP’s dedicated interface for third party providers – PISPs, AISPs – a major incident for the ASPSP). The EBA has assessed these proposals but finally decided not to adopt them, as the benefits of such an approach are not clear while it would most likely lead to increased and unnecessary complexity, resulting in a less level playing field. Template and instructions 22.A large group of respondents considered that the template was not clear enough as regards what should be reported in each phase of the incident and which fields are mandatory and which are not. A few of them understood that payment service providers needed to fill out as many fields as possible, and this was seen too complicated in the given timeframe. Several comments regarding 9 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER PSD2 different fields of the template (e.g. the list of incident statuses, payment services affected, systems and components affected) and suggestions on potential improvements (e.g. clarify that multiple boxes may be ticked in some instances, indicate if figures are estimations, include a measurement of staff impact) were also received. 23.The EBA acknowledges that it was indeed not always comprehensible from the outset which information is expected from payment service providers in each phase. Hence, taking into consideration the concerns about the time needed to fill it out, the EBA has reorganised the template in three clear sections, one for each type of report: initial, intermediate and final. Payment service providers are therefore expected to complete each of the sections in a cumulative way, so the final report contains information on all fields. This means that all fields are in principle mandatory, unless the template explicitly states otherwise (e.g. ‘if applicable’ or ‘if already known’). The other comments and suggestions received have been considered by the EBA, and the necessary changes have been introduced in the template when relevant. 24.A few comments were also received on the instructions to complete the template, mainly seeking clarification as regards certain fields, e.g. unique identification number, country(ies) affected by the incident, incident discovery, operational incident. There was also a request to include the instructions in the Guidelines themselves. 25.The EBA notes that the instructions are technical and rather too complex to be placed in the text of the Guidelines. It emphasises that the annex is a fully fledged part of the Guidelines as well, thus having the same legal effects. As regards all other suggestions, the EBA has assessed the possibility of improving the clarity of the instructions and has amended them when considered relevant. Notification process 26.Respondents generally agreed with the notification process, the main exception being the deadline for submitting the initial report, which was deemed too short by most respondents given the need to devote resources to resolving the incident. Several suggestions were received on alternative deadlines, ranging from 3 to 72 hours. Furthermore, some respondents proposed that this deadline should be from the moment the incident is classified as major, and not from the moment it is detected. A few comments were also received on intermediate reports (mainly suggesting to remove them and to extend the deadline) and on final reports (to extend the deadline). 27.The EBA has assessed all replies and considers that the respondents’ arguments are sensible and well founded as regards the deadline for the initial report. It has therefore extended the deadline from 2 hours to 4 hours along with limiting the amount of information to be provided in the initial report. Nevertheless, the EBA considers the deadlines for the other reports to be adequate to balance the burden on payment service providers and the need for competent authorities to be informed of the development of the incident. That is also why the EBA considers that intermediate reports should remain. 10 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER PSD2 28.Furthermore, some requests for clarification were put forward, namely on (i) the way to proceed when a major incident has been resolved within the deadline for submitting the initial report, (ii) whether or not intermediate and/or final reports are needed when the source is in an external provider and (iii) whether or not Diagram 2 constitutes a requirement to set up a separate subprocess having exactly the same structure. 29.The EBA wishes to clarify that major incidents resolved within the deadline to submit the initial report should also be notified, with the peculiarity that the initial report may also constitute the last intermediate report and, potentially, the final report. Furthermore, the EBA confirms that intermediate and final reports are indeed required when the source is in an external provider and that Diagram 2 is not a requirement, since it is not included in the Guidelines, but simply aims to depict the notification process for clarity purposes. The EBA still believes in the usefulness of this diagram and has, accordingly, kept it in the Rationale section as seen below. Diagram 2: Incident notification process from payment service providers to the competent authority in the home Member State PSP INCIDENT MANAGEMENT PROCESSES A. INCIDENT DETECTION B. PSP’S INCIDENT REGISTRATION AND TRIAGE C. PSP’S INCIDENT RESOLUTION D. PSP’S INCIDENT CLOSURE E. PSP’S INCIDENT POSTANALYSIS END ADDITIONAL PSP INCIDENT NOTIFICATION PROCESSES 1.2 ADDITIONAL INCIDENT INFORMATION AVAILABLE TO BE ASSESSED 1.1 NEW INCIDENT DETECTED OR NEXT UPDATE TIME EXPIRED 1.3 ASSESS WHETHER TO REPORT TO NCA N Waits for a specific message to be received Sends a message to a specific destination [additional incident information available to be assessed] 1.4 ASSESS RELEVANCE OF UPDATED INFORMATION SINCE LAST NOTIFICATION [next update time expired] Y Y Should a report be sent (initial, intermediate or final)? Is there sufficient information for an update?
12. COLLECT & SORT INCIDENT INFORMATION N 4 CONTACT NCA TO EXPLAIN WHY NO UPDATE IS AVAILABLE (and agree on the next update time) Activity Flow decision Flow path
13. BUILD & SEND INCIDENT REPORT TO NCA (includ. annexes and next update time if applicable) Y END N Is this the final report? Delegated and consolidated reporting 30.A majority of respondents welcomed the option to delegate the reporting, also in a consolidated way, although a few of them noted that incident reporting should be the responsibility of the payment service provider. To benefit further from this option, some respondents requested that the following conditions be removed: that the third party should be established in the Union, that the competent authority should be informed beforehand, and that the consolidated report is limited to incidents stemming from a disruption of technical services. Another respondent asked for the possibilities of providing average values for measuring the impact instead of the figures corresponding to each payment service provider, and of assessing the incident on a consolidated 11 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER PSD2 basis. In addition, a number of respondents requested further clarifications in the Guidelines as regards the formal procedures to be followed for the designation of such a third party – including where the delegated entity is located in a different country – as well as for the communication of incident reports by those parties to competent authorities. 31.The EBA wishes to highlight that payment service providers remain fully responsible for the reporting of major operational or security incidents, regardless of whether this has been delegated or not. Furthermore, the EBA has assessed the suggestions received and considers that, in general, they would improve the usability of delegated and consolidated reporting, so the conditions that the third party should be established in the Union and that the incident has to stem from a technical disruption have been removed. Nevertheless, the EBA believes that competent authorities should know in advance who will send the report in case of incident, and therefore no changes have been introduced in this regard. 32.Moreover, for the particular case of consolidated reporting, the EBA notes that Article 96 of PSD2 requires that the assessment is done on an individual basis, although it expects that, in practice, the impact is similar for all payment service providers and, therefore, a detailed analysis is not necessary in most cases. As regards the impact-related information, the Guidelines – and the template – have been amended to allow the designated third party to provide value ranges (i.e. the value corresponding to the least affected payment service provider and the value corresponding to the most affected payment service provider) instead of individual information. Finally, the EBA is of the view that the formal designation and communication procedures to be applied in the case of the intervention of a third party remain within the scope of each competent authority, so no changes have been made to the Guidelines on this particular point. Guidelines addressed to competent authorities 33.Many respondents questioned the way the EBA would treat the information provided in the incident reports, both when stored and in transit. The EBA agrees that the Guidelines could explain that the professional secrecy obligations set out in PSD2 apply, and has therefore introduced this clarification in the Guidelines. General comments 34.Most respondents mentioned the existence of other incident-reporting frameworks and the convenience of aligning them by harmonising criteria, templates and notification processes. They also mentioned having one-stop-shop mechanisms. Many respondents also raised questions about how the EBA and relevant authorities will use the collected information and, in particular, if it will be shared with other payment service providers. Moreover, on the argument about the importance of encouraging collaboration amongst firms on these matters, several respondents expressed a desire that the Guidelines be used to promote and establish best practices addressing collaboration (especially in the case of incidents affecting Third Party Providers TPPs). 35.The EBA acknowledges that other incident notification frameworks exist, but it is not in a position to address the issue, since its mandate is limited to the scope of PSD
14. The EBA would, however, like to highlight that it has tried to align the Guidelines as much as possible with the SSM’s cyber 12 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER PSD2 incident-reporting framework. As regards the use of the information by competent authorities and, in particular, on the issue of sharing or promoting the sharing of such information with/among payment service providers, the EBA would like to recall that this is not in the scope of PSD2 mandate and, therefore, it cannot be covered by the Guidelines. In any case, the EBA would like to underline the fact that the Guidelines do not forbid payment service providers to share information about reported incidents on a voluntary basis, and concurs that such an initiative would bring about benefits if it became standard practice in the market. 13 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2
15. Guidelines 14 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 EBA/GL/2017/10 27/07/2017 Guidelines on major incident reporting under Directive (EU) 2015/2366 (PSD2) 15 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2
16. Compliance and reporting obligations Status of these Guidelines
17. This document contains Guidelines issued pursuant to Article 16 of Regulation (EU) No 1093/
18. 1 In accordance with Article 16

(3)of Regulation (EU) No 1093/2010, competent authorities and financial institutions must make every effort to comply with the Guidelines. 2. Guidelines set out the EBA’s view of appropriate supervisory practices within the European System of Financial Supervision or of how Union law should be applied in a particular area. Competent authorities as defined in Article 4

(2)of Regulation (EU) No 1093/2010 to whom Guidelines apply should comply by incorporating them into their practices as appropriate (e.g. by amending their legal framework or their supervisory processes), including where Guidelines are directed primarily at institutions. Reporting requirements 3. In accordance with Article 16

(3)of Regulation (EU) No 1093/2010, competent authorities must notify the EBA that they comply or intend to comply with these Guidelines, or otherwise give reasons for non-compliance, by ([dd.mm.yyyy]). In the absence of any notification by this deadline, competent authorities will be considered by the EBA to be non-compliant. Notifications should be sent by submitting the form available on the EBA website to compliance@eba.europa.eu with the reference ‘EBA/GL/2017/10’. Notifications should be submitted by persons with appropriate authority to report compliance on behalf of their competent authorities. Any change in the status of compliance must also be reported to the EBA. 4. Notifications will be published on the EBA website, in line with Article 16

(3). 1 Regulation (EU) No 1093/2010 of the European Parliament and of the Council of 24 November 2010 establishing a European Supervisory Authority (European Banking Authority), amending Decision No 716/2009/EC and repealing Commission Decision 2009/78/EC (OJ L 331, 15.12.2010, p. 12). 16 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 2. Subject matter, scope and definitions Subject matter 5. These Guidelines derive from the mandate given to the EBA in Article 96

(3)of Directive (EU) 2015/2366 of the European Parliament and of the Council of 25 November 2015 on payment services in the internal market, amending Directives 2002/65/EC, 2009/110/EC and 2013/36/EU and Regulation (EU) No 1093/2010, and repealing Directive 2007/64/EC (PSD2). 6. In particular, these Guidelines specify the criteria for the classification of major operational or security incidents by payment service providers as well as the format and procedures they should follow to communicate, as laid down in Article 96

(1)of the above-mentioned directive, such incidents to the competent authority in the home Member State. 7. In addition, these Guidelines deal with the way these competent authorities should assess the relevance of the incident and the details of the incident reports that, according to Article 96

(2)of the said directive, they shall share with other domestic authorities.

1. Moreover these Guidelines also deal with the sharing with the EBA and the ECB of the relevant details of the incidents reported, for the purposes of promoting a common and consistent approach. Scope of application
2. These Guidelines apply in relation to the classification and reporting of major operational or security incidents in accordance with Article 96 of Directive (EU) 2015/
4. These Guidelines apply to all incidents included under the definition of ‘major operational or security incident’, which covers both external and internal events that could be either malicious or accidental.
5. These Guidelines apply also where the major operational or security incident originates outside the Union (e.g. when an incident originates in the parent company or in a subsidiary established outside the Union) and affects the payment services provided by a payment service provider located in the Union either directly (a payment-related service is carried out by the affected non-Union company) or indirectly (the capacity of the payment service provider to keep carrying out its payment activity is jeopardised in some other way as a result of the incident). 17 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 Addressees
6. The first set of Guidelines (Section 4) is addressed to payment service providers as defined in Article 4

(11)of Directive (EU) 2015/2366 and as referred to in Article 4

(1)of Regulation (EU) 1093/

2. The second and third sets of Guidelines (Sections 5 and 6) are addressed to competent authorities as defined in Article 4

(2)(i) of Regulation (EU) No 1093/

1. Definitions
2. Unless otherwise specified, terms used and defined in the Directive (EU) 2015/2366 have the same meaning in the Guidelines. In addition, for the purposes of these Guidelines, the following definitions apply: Operational or security incident Integrity Availability Confidentiality Authenticity Continuity Payment-related services A singular event or a series of linked events unplanned by the payment service provider which has or will probably have an adverse impact on the integrity, availability, confidentiality, authenticity and/or continuity of paymentrelated services. The property of safeguarding the accuracy and completeness of assets (including data). The property of payment-related services being accessible and usable by payment service users. The property that information is not made available or disclosed to unauthorised individuals, entities or processes. The property of a source being what it claims to be. The property of an organisation’s processes, tasks and assets needed for the delivery of payment-related services being fully accessible and running at acceptable predefined levels. Any business activity in the meaning of Article 4

(3)of PSD2, and all the necessary technical supporting tasks for the correct provision of payment services. 18 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2

1. Implementation Date of application
2. These Guidelines apply from 13 January
3. 19 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2
4. Guidelines addressed to payment service providers on the notification of major operational or security incidents to the competent authority in their home Member State Guideline 1: Classification as major incident 1.
5. Payment service providers should classify as major those operational or security incidents that fulfil a. one or more criteria at the ‘Higher impact level’, or b. three or more criteria at the ‘Lower impact level’ as set out in GL 1.4, and following the assessment set out in these Guidelines. 1.
6. Payment service providers should assess an operational or security incident against the following criteria and their underlying indicators: i. Transactions affected Payment service providers should determine the total value of the transactions affected, as well as the number of payments compromised as a percentage of the regular level of payment transactions carried out with the affected payment services. ii. Payment service users affected Payment service providers should determine the number of payment service users affected both in absolute terms and as a percentage of the total number of payment service users. iii. Service downtime Payment service providers should determine the period of time when the service will probably be unavailable for the payment service user or when the payment order, in the meaning of Article 4

(13)of PSD2, cannot be fulfilled by the payment service provider. iv. Economic impact Payment service providers should determine the monetary costs associated with 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). v. High level of internal escalation 20 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 Payment service providers should determine whether or not this incident has been or will probably be reported to their executive officers. vi. Other payment service providers or relevant infrastructures potentially affected Payment service providers should determine the systemic implications that the incident will probably have, i.e. its potential to spill over beyond the initially affected payment service provider to other payment service providers, financial market infrastructures and/or card payment schemes. vii. Reputational impact Payment service providers should determine how the incident can undermine users’ trust in the payment service provider itself and, more generally, in the underlying service or the market as a whole. 1.3. Payment service providers should calculate the value of the indicators according to the following methodology: i. Transactions affected As a general rule, payment service providers should understand as ‘transactions affected’ all domestic and cross-border transactions that have been or will probably be directly or indirectly affected by the incident and, in particular, those transactions that could not be initiated or processed, those for which the content of the payment message was altered and those that were fraudulently ordered (whether the funds have been recovered or not). Furthermore, payment service providers should understand the regular level of payment transactions to be the daily annual average of domestic and cross-border payment transactions carried out with the same payment services that have been affected by the incident, taking the previous year as the reference period for calculations. If payment service providers do not consider this figure to be representative (e.g. because of seasonality), they should use another, more representative, metric instead and convey to the competent authority the underlying rationale for this approach in the corresponding field of the template (see Annex 1). ii. Payment service users affected Payment service providers should understand as ‘payment service users affected’ all customers (either domestic or from abroad, consumers or corporates) that have a contract with the affected payment service provider that grants them access to the affected payment service, and that have suffered or will probably suffer the consequences of the incident. Payment service providers should resort to estimations based on past activity to determine the number of payment service users that may have been using the payment service during the lifetime of the incident. In the case of groups, each payment service provider should consider only its own payment service users. In the case of a payment service provider offering operational services to others, that payment service provider should consider only its own payment service users 21 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 (if any), and the payment service providers receiving those operational services should assess the incident in relation to their own payment service users. Furthermore, payment service providers should take as the total number of payment service users the aggregated figure of domestic and cross-border payment service users contractually bound to them at the time of the incident (or, alternatively, the most recent figure available) and with access to the affected payment service, regardless of their size or whether they are considered active or passive payment service users. iii. Service downtime Payment service providers should consider the period of time that any task, process or channel related to the provision of payment services is or will probably be down and, thus, prevents (

1. i)the initiation and/or execution of a payment service and/or (
2. ii)access to a payment account. Payment service providers should count the service downtime from the moment the downtime starts, and they should consider both the time intervals when they are open for business as required for the execution of payment services as well as the closing hours and maintenance periods, where relevant and applicable. If payment service providers are unable to determine when the service downtime started, they should exceptionally count the service downtime from the moment the downtime is detected. iv. Economic impact Payment service providers should consider both the costs that can be connected to the incident directly and those which are indirectly related to the incident. Among other things, payment service providers should take into account expropriated funds or assets, replacement costs of hardware or software, other forensic or remediation costs, fees due to non-compliance with contractual obligations, sanctions, external liabilities and lost revenues. As regards the indirect costs, payment service providers should consider only those that are already known or very likely to materialise. v. High level of internal escalation Payment service providers should consider whether or not, as a result of its impact on payment-related services, the Chief Information Officer (or similar position) has been or will probably be informed about the incident outside any periodical notification procedure and on a continuous basis throughout the lifetime of the incident. Furthermore, payment service providers should consider whether or not, as a result of the impact of the incident on payment-related services, a crisis mode has been or is likely to be triggered. vi. Other payment service providers or relevant infrastructures potentially affected Payment service providers should assess the impact of the incident on the financial market, understood as the financial market infrastructures and/or card payment schemes that support them and other payment service providers. In particular, payment service providers should assess whether or not the incident has been or will probably be replicated at other payment service providers, whether or not it has affected or will probably affect the smooth functioning of financial market infrastructures and whether or not it has compromised or will probably compromise the sound operation of the financial system as a 22 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 whole. Payment service providers should bear in mind various dimensions such as whether the component/software affected is proprietary or generally available, whether the compromised network is internal or external and whether or not the payment service provider has stopped or will probably stop fulfilling its obligations in the financial market infrastructures of which it is a member. vii. Reputational impact Payment service providers should consider the level of visibility that, to the best of their knowledge, the incident has gained or will probably gain in the marketplace. In particular, payment service providers should consider the likelihood that the incident will cause harm to society as a good indicator of its potential to affect their reputation. Payment service providers should take into account whether or not (
3. i)the incident has affected a visible process and is therefore likely to receive or has already received media coverage (considering not only traditional media, such as newspapers, but also blogs, social networks, etc.), (
4. ii)regulatory obligations have been or will probably be missed, (iii) sanctions have been or will probably be breached or (
5. iv)the same type of incident has occurred before. 1.4. Payment service providers should assess an incident by determining, for each individual criterion, if the relevant thresholds in Table 1 are or will probably be reached before the incident is resolved. Table 1: Thresholds Criteria Lower impact level Higher impact level Service downtime > 10% of the payment service provider’s regular level of transactions (in terms of number of transactions) and > EUR 100 000 > 5 000 and > 10% of the payment service provider’s payment service users > 2 hours Economic impact Not applicable High level of internal escalation Yes > 25% of the payment service provider’s regular level of transactions (in terms of number of transactions) or > EUR 5 million > 50 000 or > 25% of the payment service provider’s payment service users Not applicable > Max. (0.1% Tier 1 capital,* EUR 200 000) or > EUR 5 million Yes, and a crisis mode (or equivalent) is likely to be called upon Other payment service providers or relevant infrastructures potentially affected Yes Not applicable Reputational impact Yes Not applicable Transactions affected Payment service users affected 23 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 *Tier 1 capital as defined in Article 25 of Regulation (EU) No 575/2013 of the European Parliament and of the Council, of 26 June 2013, on prudential requirements for credit institutions and investment firms and amending Regulation (EU) No 648/2012. 1.5. Payment service providers should resort to estimations if they do not have actual data to support their judgments of whether or not a given threshold is or will probably be reached before the incident is resolved (e.g. this could happen during the initial investigation phase). 1.6. Payment service providers should carry out this assessment on a continuous basis during the lifetime of the incident, to identify any possible status change, either upwards (from non-major to major) or downwards (from major to non-major). Guideline 2: Notification process 2.1. Payment service providers should collect all relevant information, produce an incident report using the template provided in Annex 1 and submit it to the competent authority in the home Member State. Payment service providers should fill out the template following the instructions provided in Annex 1. 2.2. Payment service providers should use the same template to inform the competent authority throughout the lifetime of the incident (i.e. for initial, intermediate and final reports, as described in paragraphs 2.7 to 2.21). Payment service providers should complete the template in an incremental manner, on a best effort basis, as more information becomes readily available in the course of their internal investigations. 2.3. Payment service providers should also present to the competent authority in their home Member State, if applicable, a copy of the information provided (or that will be provided) to their users, as laid down in the second paragraph of Article 96

(1)of PSD2, as soon as it is available. 2.

1. Payment service providers should furnish the competent authority in the home Member State, if available and deemed relevant for the competent authority, with any additional information by appending supplementary documentation to the standardised template as one or various annexes. 2.
2. Payment service providers should follow up on any requests from the competent authority in the home Member State to provide additional information or clarifications regarding already submitted documentation. 2.
3. Payment service providers should at all times preserve the confidentiality and integrity of the information exchanged with the competent authority in their home Member State and also authenticate themselves properly towards the competent authority in their home Member State. 24 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 Initial report 2.
4. Payment service providers should submit an initial report to the competent authority in the home Member State when a major operational or security incident is first detected. 2.
5. Payment service providers should send the initial report to the competent authority within 4 hours from the moment the major operational or security incident was first detected, or, if the reporting channels of the competent authority are known not to be available or operational at that time, as soon as they become available/operational again. 2.
6. Payment service providers should also submit an initial report to the competent authority in the home Member State when a previously non-major incident becomes a major incident. In this particular case, payment service providers should send the initial report to the competent authority immediately after the change of status is identified, or, if the reporting channels of the competent authority are known not to be available or operational at that time, as soon as they become available/operational again. 2.
7. Payment service providers should include headline-level information (i.e. section A of the template) in their initial reports, thus featuring some basic characteristics of the incident and its expected consequences based on the information available immediately after it was detected or reclassified. Payment service providers should resort to estimations when actual data are not available. Payment service providers should also include in their initial report the date for the next update, which should be as soon as possible and under no circumstances go beyond 3 business days. Intermediate report 2.
8. Payment service providers should submit intermediate reports every time they consider that there is a relevant status update and, as a minimum, by the date for the next update indicated in the previous report (either the initial report or the previous intermediate report). 2.
9. Payment service providers should submit to the competent authority a first intermediate report with a more detailed description of the incident and its consequences (section B of the template). Moreover, payment service providers should produce additional intermediate reports by updating the information already provided in sections A and B of the template at least, when they become aware of new relevant information or significant changes since the previous notification (e.g. whether the incident has escalated or decreased, new causes identified or actions taken to fix the problem). In any case, payment service providers should produce an intermediate report at the request of the competent authority in the home Member State. 2.
10. As in the case of initial reports, when actual data are not available payment service providers should make use of estimations. 25 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 2.
11. Furthermore, payment service providers should indicate in each report the date for the next update, which should be as soon as possible and under no circumstances go beyond 3 business days. Should the payment service provider not be able to comply with the estimated date for the next update, it should contact the competent authority in order to explain the reasons behind the delay, propose a new plausible submission deadline (no longer than 3 business days) and send a new intermediate report updating exclusively the information regarding the estimated date for the next update. 2.
12. Payment service providers should send the last intermediate report when regular activities have been recovered and business is back to normal, informing the competent authority of this circumstance. Payment service providers should consider that business is back to normal when activity/operations are restored to the same level of service/conditions as defined by the payment service provider or laid out externally by a Service Level Agreement (SLA) in terms of processing times, capacity, security requirements, etc., and contingency measures are no longer in place. 2.
13. Should business be back to normal before 4 hours have passed since the incident was detected, payment service providers should aim to submit both the initial and the last intermediate report simultaneously (i.e. filling out sections A and B of the template) by the 4-hour deadline. Final report 2.
14. Payment service providers should send a final report when the root cause analysis has taken place (regardless of whether or not mitigation measures have already been implemented or the final root cause has been identified) and there are actual figures available to replace any estimates. 2.
15. Payment service providers should deliver the final report to the competent authority within a maximum of 2 weeks after business is deemed back to normal. Payment service providers needing an extension of this deadline (e.g. if there are no actual figures on the impact available yet) should contact the competent authority before it has lapsed and provide an adequate justification for the delay, as well as a new estimated date for the final report. 2.
16. Should payment service providers be able to provide all the information required in the final report (i.e. section C of the template) within the 4-hour window since the incident was detected, they should aim to submit in their initial report the information related to initial, last intermediate and final reports. 2.
17. Payment service providers should aim to include in their final reports full information, i.e. (i) actual figures on the impact instead of estimations (as well as any other update needed in sections A and B of the template) and (ii) section C of the template, which includes the root cause, if already known, and a summary of measures adopted or planned to be adopted to remove the problem and prevent its recurrence in the future. 26 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 2.
18. Payment service providers should also send a final report when, as a result of the continuous assessment of the incident, they identify that an already reported incident no longer fulfils the criteria to be considered major and is not expected to fulfil them before the incident is resolved. In this case, payment service providers should send the final report as soon as this circumstance is detected and, in any case, by the estimated date for the next report. In this particular situation, instead of filling out section C of the template, payment service providers should tick the box ‘incident reclassified as non-major’ and explain the reasons justifying this downgrading. Guideline 3: Delegated and consolidated reporting 3.
19. 3.
20. Where permitted by the competent authority, payment service providers wishing to delegate reporting obligations under PSD2 to a third party should inform the competent authority in the home Member State and ensure the fulfilment of the following conditions: a. The formal contract or, where applicable, existing internal arrangements within a group, underpinning the delegated reporting between the payment service provider and the third party unambiguously defines the allocation of responsibilities of all parties. In particular, it clearly states that, irrespective of the possible delegation of reporting obligations, the affected payment service provider remains fully responsible and accountable for the fulfilment of the requirements set out in Article 96 of PSD2 and for the content of the information provided to the competent authority in the home Member State. b. The delegation complies with the requirements for the outsourcing of important operational functions as set out in i. Article 19

(6)of PSD2 in relation to payment institutions and e-money institutions, applicable mutatis mutandis in accordance with Article 3 of Directive 2009/110/EC (EMD); or ii. the CEBS Guidelines on outsourcing in relation to credit institutions. c. The information is submitted to the competent authority in the home Member State in advance and, in any case, following any deadlines and procedures established by the competent authority, where applicable. d. The confidentiality of sensitive data and the quality, consistency, integrity and reliability of the information to be provided to the competent authority is properly ensured. Payment service providers wishing to allow the designated third party to fulfil the reporting obligations in a consolidated way (i.e. by presenting one single report referred to several payment service providers affected by the same major operational or security incident) should inform the competent authority in the home Member State, include the contact 27 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 information included under ‘Affected PSP’ in the template and make certain that the following conditions are satisfied: a. Include this provision in the contract underpinning the delegated reporting. b. Make the consolidated reporting conditional on the incident’s being caused by a disruption in the services provided by the third party. c. Confine the consolidated reporting to payment service providers established in the same Member State. d. Ensure that the third party assesses the materiality of the incident for each affected payment service provider and includes in the consolidated report only those payment service providers for which the incident is classified as major. Furthermore, ensure that, in case of doubt, a payment service provider is included in the consolidated report as long as there is no evidence that it should not. e. Ensure that, when there are fields of the template where a common answer is not possible (e.g. section B 2, B 4 or C 3), the third party either (

1. i)fills them out individually for each affected payment service provider, further specifying the identity of each payment service provider to which the information relates, or (
2. ii)uses ranges, in those fields where this is an option, representing the lowest and highest values as observed or estimated for the different payment service providers. f. Payment service providers should ensure that the third party keeps them informed at all times of all the relevant information regarding the incident and all the interactions that the third party may have with the competent authority and of the contents thereof, but only as far as is compatible with avoiding any breach of confidentiality as regards the information that relates to other payment service providers. 3.3. Payment service providers should not delegate their reporting obligations before informing the competent authority in the home Member State or after having been informed that the outsourcing agreement does not meet the requirements referred to in Guideline 3.1, letter b). 3.4. Payment service providers wishing to withdraw the delegation of their reporting obligations should communicate this decision to the competent authority in the home Member State, in accordance with the deadlines and procedures established by the latter. Payment service providers should also inform the competent authority in the home Member State of any material development affecting the designated third party and its ability to fulfil the reporting obligations. 28 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 3.5. Payment service providers should materially complete their reporting obligations without any recourse to external assistance whenever the designated third party fails to inform the competent authority in the home Member State of a major operational or security incident in accordance with Article 96 of PSD2 and with these Guidelines. Furthermore, payment service providers should ensure that an incident is not reported twice, individually by said payment service provider and once again by the third party. Guideline 4: Operational and security policy 4.1. Payment service providers should ensure that their general operational and security policy clearly defines all the responsibilities for incident reporting under PSD2, as well as the processes implemented to fulfil the requirements defined in the present Guidelines. 29 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 5. Guidelines addressed to competent authorities on the criteria on how to assess the relevance of the incident and the details of the incident reports to be shared with other domestic authorities Guideline 5: Assessment of the relevance of the incident 5.1. Competent authorities in the home Member State should assess the relevance of a major operational or security incident to other domestic authorities, taking as a basis their own expert opinion and using the following criteria as primary indicators of the importance of said incident: a. b. c. d. 5.2. The causes of the incident are within the regulatory remit of the other domestic authority (i.e. its field of competence). The consequences of the incident have an impact on the objectives of another domestic authority (e.g. safeguarding of financial stability). The incident affects, or could affect, payment service users on a wide scale. The incident is likely to receive, or has received, wide media coverage. Competent authorities in the home Member State should carry out this assessment on a continuous basis during the lifetime of the incident, to identify any possible change that could make an incident relevant that was previously not considered as such. Guideline 6: Information to be shared 6.1. Notwithstanding any other legal requirement to share incident-related information with other domestic authorities, competent authorities should provide information about major operational or security incidents to the domestic authorities identified following the application of Guideline 5.1 (i.e. ‘other relevant domestic authorities’), as a minimum, at the time of receiving the initial report (or, alternatively, the report that prompted the sharing of information) and when they are notified that business is back to normal (i.e. last intermediate report). 6.2. Competent authorities should submit to other relevant domestic authorities the information needed to provide a clear picture of what happened and the potential consequences. To do so, they should provide, as a minimum, the information given by the payment service provider in the following fields of the template (either in the initial or in the intermediate report): 30 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 - date and time of detection of the incident; date and time of beginning of the incident; date and time when the incident was restored or is expected to be restored; short description of the incident (including non-sensitive parts of the detailed description); short description of measures taken or planned to be taken to recover from the incident; description of how the incident could affect other PSPs and/or infrastructures; description (if any) of the media coverage; cause of the incident. 6.3. Competent authorities should conduct proper anonymisation, as needed, and leave out any information that could be subject to confidentiality or intellectual property restrictions before sharing any incident-related information with other relevant domestic authorities. Nevertheless, competent authorities should provide other relevant domestic authorities with the name and address of the reporting payment service provider when said domestic authorities can guarantee that the information will be treated confidentially. 6.4. Competent authorities should at all times preserve the confidentiality and integrity of the information stored and exchanged with other relevant domestic authorities and also authenticate themselves properly towards other relevant domestic authorities. In particular, competent authorities should treat all information received under these Guidelines in accordance with the professional secrecy obligations set out in PSD2, without prejudice to applicable Union law and national requirements. 31 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 6. Guidelines addressed to competent authorities on the criteria on how to assess the relevant details of the incident reports to be shared with the EBA and the ECB and on the format and procedures for their communication Guideline 7: Information to be shared 7.1. Competent authorities should always provide the EBA and the ECB with all reports received from (or on behalf
3. of)payment service providers affected by a major operational or security incident (i.e. initial, intermediate and final reports). Guideline 8: Communication 8.1. Competent authorities should at all times preserve the confidentiality and integrity of the information stored and exchanged with the EBA and the ECB and also authenticate themselves properly towards the EBA and the ECB. In particular, competent authorities should treat all information received under these Guidelines in accordance with the professional secrecy obligations set out in PSD2, without prejudice to applicable Union law and national requirements. 8.2. To avoid delays in the transmission of incident-related information to the EBA/ECB and help minimise the risks of operational disruptions, competent authorities should support appropriate means of communication. 32 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 Annex 1 – Reporting templates for payment service providers Major Incident Report Initial report within 4 hours after detection Intermediate report maximum of 3 business days from previous report Last intermediate report Final report Incident reclassified as non-major within 2 weeks after closing the incident Please explain: Report date DD/MM/YYYY Time HH:MM Incident identification number, if applicable (for interim and final reports) A - Initial report A 1 - GENERAL DETAILS Type of report Individual Consolidated Type of report Affected payment service provider (PSP) PSP name PSP unique identification number, if relevant PSP authorisation number Head of group, if applicable Home country Country/countries affected by the incident Email Primary contact person Email Secondary contact person Reporting entity (complete this section if the reporting entity is not the affected PSP in case of delegated reporting) Name of the reporting entity Unique identification number, if relevant Authorisation number, if applicable Email Primary contact person Email Secondary contact person Telephone Telephone Telephone Telephone A 2 - INCIDENT DETECTION and INITIAL CLASSIFICATION Date and time of detection of the incident DD/MM/YYYY, HH:MM The incident was detected by

(1)Please provide a short and general description of the incident (should you deem the incident to have an impact in other EU Member States(s), and if feasible within the applicable reporting deadlines, please provide a translation in English) What is the estimated time for the next update? If Other, please explain: DD/MM/YYYY, HH:MM B - Intermediate report B 1 - GENERAL DETAILS Please provide a more DETAILED description of the incident. e.g. information on: - What is the specific issue? - How it happened - How did it develop - Was it related to a previous incident? - Consequences (in particular for payment service users) - Background of the incident detection - Areas affected - Actions taken so far - Service providers/ third party affected or involved - Crisis management started (internal and/or external (Central Bank Crisis management)) - PSP internal classification of the incident Date and time of beginning of the incident (if already identified) Incident status Date and time when the incident was restored or is expected to be restored DD/MM/YYYY, HH:MM Diagnostics Recovery Repair Restoration DD/MM/YYYY, HH:MM 33 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 B 2 - INCIDENT CLASSIFICATION & INFORMATION ON THE INCIDENT Overall impact Transactions affected

(2)Payment service users affected

(3)Integrity Confidentiality Availability Authenticity Continuity Number of transactions affected Actual figure Estimation As a % of regular number of transactions Actual figure Estimation Value of transactions affected in EUR Comments: Actual figure Estimation Number of payment service users affected Actual figure Estimation As a % of total payment service users Actual figure Estimation Service downtime

(4)Actual figure Estimation Direct costs in EUR DD:HH:MM Actual figure Estimation Indirect costs in EUR Actual figure Total service downtime Economic impact

(5)YES, AND CRISIS MODE (OR EQUIVALENT) IS LIKELY TO BE CALLED UPON YES High level of internal escalation Describe the level of internal escalation of the incident, indicating if it has triggered or is likely to trigger a crisis mode (or equivalent) and if so, please describe Other PSPs or relevant infrastructures potentially affected Describe how this incident could affect other PSPs and/or infrastructures Reputational impact Describe how the incident could affect the reputation of the PSP (e.g. media coverage, potential legal or regulatory infringement, etc.) Estimation NO NO YES YES NO B 3 - INCIDENT DESCRIPTION Type of Incident Cause of incident Operational Security Under investigation Type of attack: Distributed/Denial of Service (D/DoS) Infection of internal systems Targeted intrusion Other If Other, specify External attack Internal attack External events Human error Process failure System failure Other Was the incident affecting you directly, or indirectly through a service provider? If Other, specify Directly If indirectly, please provide the service provider's name Indirectly B 4 - INCIDENT IMPACT Building(s) affected (Address), if applicable Commercial channels affected Telephone banking Mobile banking ATMs Point of sale Other Cash placement on a payment account Credit transfers Money remittance Cash withdrawal from a payment account Direct debits Payment initiation services Operations required for operating a payment account Acquiring of payment instruments Card payments Account information services Issuing of payment instruments Other Clearing Direct settlement Indirect settlement Other Branches E-banking If Other, specify: Payment services affected Functional areas affected Systems and components affected Staff affected If Other, specify: Authentication/authorisation Communication If Other, specify: Application/software Database Hardware Network/infrastructure Other If Other, specify: YES NO Describe how the incident could affect the staff of the PSP/service provider (e.g. staff not being able to reach the office to support customers, etc.) B 5 - INCIDENT MITIGATION Which actions/measures have been taken so far or are planned to recover from the incident? Has the Business Continuity Plan and/or Disaster Recovery Plan been activated? If so, when? If so, please describe Has the PSP cancelled or weakened some controls because of the incident? If so, please explain YES NO DD/MM/YYYY, HH:MM YES NO 34 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 C - Final report If no intermediate report has been sent, please also complete section B C 1 - GENERAL DETAILS Please update the information from the intermediate report (summary): - additional actions/measures taken to recover from the incident - final remediation actions taken - root cause analysis - lessons learnt - addittional actions - any other relevant information Date and time of closing the incident If the PSP had to cancel or weaken some controls because of the incident, are the original controls back in place? If so, please explain DD/MM/YYYY, HH:MM YES NO C 2 - ROOT CAUSE ANALYSIS AND FOLLOW-UP What was the root cause (if already known)? (possible to attach a file with detailed information) Main corrective actions/measures taken or planned to prevent the incident from happening again in the future, if already known C 3 - ADDITIONAL INFORMATION Has the incident been shared with other PSPs for information purposes? If so, please provide details Has any legal action been taken against the PSP? If so, please provide details YES NO YES NO Notes:

(1)Pull-down menu: payment service user; internal organisation; external organisation; none of the above

(2)Pull-down menu: > 10% of regular level of transactions and > EUR 100000; > 25% of regular level of transactions or > EUR 5 milion; none of the above

(3)Pull-down menu: > 5000 and > 10% payment service users; > 50000 or > 25% payment service users; none of the above

(4)Pull-down menu: > 2 hours; < 2 hours

(5)Pull-down menu: > Max (0,1% Tier 1 capital, EUR 200000) or > EUR 5 million; none of the above CONSOLIDATED REPORT - LIST OF PSPs PSP Name PSP Unique PSP Authorisation Identification Number number 35 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 INSTRUCTIONS FOR FILLING OUT THE TEMPLATES Payment service providers should fill out the relevant section of the template, depending on the reporting phase they are in: section A for the initial report, section B for intermediate reports and section C for the final report. All fields are mandatory, unless it is clearly specified otherwise. Headline Initial report: this is the first notification that the PSP submits to the competent authority in the home Member State. Intermediate report: this is an update of a previous (initial or intermediate) report on the same incident. Last intermediate report: this informs the competent authority in the home Member State that regular activities have been recovered and business is back to normal, so no more intermediate reports will be submitted. Final report: it is the last report the PSP will send on the incident, since (

1. i)a root cause analysis has already been carried out and estimations can be replaced with real figures or (
2. ii)the incident is not considered major any more. Incident reclassified as non-major: the incident no longer fulfils the criteria to be considered major and is not expected to fulfil them before it is resolved. PSPs should explain the reasons for this downgrading. Report date and time: exact date and time of submission of the report to the competent authority. Incident identification number, if applicable (for intermediate and final report): the reference number issued by the competent authority at the time of the initial report to uniquely identify the incident, if applicable (i.e. if such a reference is provided by the competent authority). A – Initial report A 1 – General details Type of report: Individual: the report refers to a single PSP. Consolidated: the report refers to several PSPs making use of the consolidated reporting option. The fields under ’Affected PSP’ should be left blank (with the exception of the field ’Country/countries affected by the incident’) and a list of the PSPs included in the report should be provided by filling in the corresponding table (Consolidated report – List of PSPs). Affected PSP: refers to the PSP that is experiencing the incident. PSP name: full name of the PSP subject to the reporting procedure as it appears in the applicable official national PSP registry. PSP unique identification number, if relevant: the relevant unique identification number used in each Member State to identify the PSP, to be provided by the PSP if the field ‘PSP authorisation number’ is not filled in. PSP authorisation number: home Member State authorisation number. Head of group: in case of groups of entities as defined in Article 4

(40)of Directive (EU) 2015/2366 of the European Parliament and of the Council of 25 November 2015 on payment services in the internal market, amending Directives 2002/65/EC, 2009/110/EC and 2013/36/EU and Regulation (EU) 1093/2010 and repealing Directive 2007/64/EC, please indicate the name of the head entity. 36 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 Home country: Member State in which the registered office of the PSP is situated; or if the PSP has, under its national law, no registered office, the Member State in which its head office is situated. Country/countries affected by the incident: country or countries where the impact of the incident has materialised (e.g. several branches of a PSP located in different countries are affected). It may or may not be the same as the home Member State. Primary contact person: first name and surname of the person responsible for reporting the incident or, if a third party reports on behalf of the affected PSP, first name and surname of the person in charge of the incident management/risk department or similar area, at the affected PSP. Email: email address to which any requests for further clarifications could be addressed, if needed. It can be either a personal or a corporate email. Telephone: telephone number to call with any requests for further clarifications, if needed. It can be either a personal or a corporate phone number. Secondary contact person: first name and surname of an alternative person who could be contacted by the competent authority to inquiry about an incident when the primary contact person is not available. If a third party reports on behalf of the affected PSP, first name and surname of an alternative person in the incident management/risk department or similar area, at the affected PSP. Email: email address of the alternative contact person to which any requests for further clarifications could be addressed, if needed. It can be either a personal or a corporate email address. Telephone: telephone number of the alternative contact person to call with any requests for further clarifications, if needed. It can be either a personal or a corporate phone number. Reporting entity: this section should be completed if a third party fulfils the reporting obligations on behalf of the affected PSP. Name of the reporting entity: full name of the entity that reports the incident, as it appears in the applicable official national business registry. Unique identification number, if relevant: the relevant unique identification number used in the country where the third party is located to identify the entity that is reporting the incident, to be provided by the reporting entity if the field ‘Authorisation number’ is not filled in. Authorisation number, if applicable: the authorisation number of the third party in the country where it is located, when applicable. Primary contact person: first name and surname of the person responsible for reporting the incident. Email: email address to which any requests for further clarifications could be addressed, if needed. It can be either a personal or a corporate email. Telephone: telephone number to call with any requests for further clarifications, if needed. It can be either a personal or a corporate phone number. Secondary contact person: first name and surname of an alternative person in the entity that is reporting the incident who could be contacted by the competent authority when the primary contact person is not available. Email: email address of the alternative contact person to which any requests for further clarifications could be addressed, if needed. It can be either a personal or a corporate email address. Telephone: telephone number of the alternative contact person to call with any requests for further clarifications could be addressed, if needed. It can be either a 37 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 personal or a corporate phone number. A 2 – Incident detection and initial classification Date and time of detection of the incident: date and time at which the incident was first identified. Incident detected by: indicate whether the incident was detected by a payment service user, some other party from within the PSP (e.g. internal audit function) or an external party (e.g. external service provider). If it was none of those, please provide an explanation in the corresponding field. Short and general description of the incident: please explain briefly the most relevant issues of the incident, covering possible causes, immediate impacts, etc. What is the estimated time for the next update?: indicate the estimated date and time for the submission of the next update (interim or final report). B – Intermediate report B 1 – General details More detailed description of the incident: please describe the main features of the incident, covering at least the points featured in the questionnaire (what specific issue the PSP is facing, how it started and developed, possible connection with a previous incident, consequences, especially for payment service users, etc.). Date and time of beginning of the incident: date and time at which the incident started, if known. Incident status: Diagnostics: the characteristics of the incident have just been identified. Repair: the attacked items are being reconfigured. Recovery: the failed items are being restored to their last recoverable state. Restoration: the payment-related service is being provided again. Date and time when the incident was restored or is expected to be restored: indicate the date and time when the incident was or is expected to be under control and business was or is expected to be back to normal. B 2 – Incident classification/Information on the incident Overall impact: please indicate which dimensions have been affected by the incident. Multiple boxes may be ticked. Integrity: the property of safeguarding the accuracy and completeness of assets (including data). Availability: the property of payment-related services being accessible and usable by payment service users. Confidentiality: the property that information is not made available or disclosed to unauthorised individuals, entities or processes. Authenticity: the property of a source being what it claims to be. Continuity: the property of an organisation’s processes, tasks and assets needed for the delivery of payment-related services being fully accessible and running at acceptable predefined levels. Transactions affected: PSPs should indicate which thresholds are or will probably be reached by the incident, if any, and the related figures: number of transactions affected, percentage of 38 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 transactions affected in relation to the number of payment transactions carried out with the same payment services that have been affected by the incident, and total value of the transactions. PSPs should provide specific values for these variables, which may be either actual figures or estimations. Entities reporting on behalf of several PSPs (i.e. consolidated reporting) may provide value ranges instead, representing the lowest and highest values observed or estimated within the group of PSPs included in the report, separated by a hyphen. As a general rule, PSPs should understand as ‘transactions affected’ all domestic and cross-border transactions that have been or will probably be directly or indirectly affected by the incident and, in particular, those transactions that could not be initiated or processed, those for which the content of the payment message was altered, and those that were fraudulently ordered (whether the funds have been recovered or not). Furthermore, PSPs should understand the regular level of payment transactions to be the daily annual average of domestic and crossborder payment transactions carried out with the same payment services that have been affected by the incident, taking the previous year as the reference period for calculations. If PSPs do not consider this figure to be representative (e.g. because of seasonality), they should use another, more representative, metric instead and convey to the competent authority the underlying rationale for this approach in the field ‘Comments’. Payment service users affected: PSPs should indicate which thresholds are or will probably be reached by the incident, if any, and the related figures: total number of payment service users that have been affected and percentage of payment service users affected in relation to the total number of payment service users. PSPs should provide concrete values for these variables, which may be either actual figures or estimations. Entities reporting on behalf of several PSPs (i.e. consolidated reporting) may provide value ranges instead, representing the lowest and highest values observed or estimated within the group of PSPs included in the report, separated by a hyphen. PSPs should understand as ‘payment service users affected’ all customers (either domestic or from abroad, consumers or corporates) that have a contract with the affected payment service provider that grants them access to the affected payment service, and that have suffered or will probably suffer the consequences of the incident. PSPs should resort to estimations based on past activity to determine the number of payment service users that may have been using the payment service during the lifetime of the incident. In the case of groups, each PSP should consider only its own payment service users. In the case of a PSP offering operational services to others, that PSP should consider only its own payment service users (if any), and the PSPs receiving those operational services should also assess the incident in relation to their own payment service users. Furthermore, PSPs should take as the total number of payment service users the aggregated figure of domestic and cross-border payment service users contractually bound to them at the time of the incident (or, alternatively, the most recent figure available) and with access to the affected payment service, regardless of their size or whether they are considered active or passive payment service users. Service downtime: PSPs should indicate if the threshold is or will probably be reached by the incident and the related figure: total service downtime. PSPs should provide concrete values for this variable, which may be either actual figures or estimations. Entities reporting on behalf of several PSPs (i.e. consolidated reporting) may provide a value range instead, representing the lowest and highest values observed or estimated within the group of PSPs included in the report, separated by a hyphen. PSPs should consider the period of time that any task, process or channel related to the provision of payment services is or will probably be down and, thus, prevents (

1. i)the initiation and/or execution of a payment service and/or (
2. ii)access to a payment account. PSPs should count the service downtime from the moment the downtime starts, and they should consider both the time intervals when they are open for business as required for the execution of payment services as well as the closing hours and maintenance periods, where 39 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 relevant and applicable. If payment service providers are unable to determine when the service downtime started, they should exceptionally count the service downtime from the moment the downtime is detected. Economic impact: PSPs should indicate if the threshold is or will probably be reached by the incident and the related figures: direct costs and indirect costs. PSPs should provide concrete values for these variables, which may be either actual figures or estimations. Entities reporting on behalf of several PSPs (i.e. consolidated reporting) may provide a value range instead, representing the lowest and highest values observed or estimated within the group of PSPs included in the report, separated by a hyphen. PSPs should consider both the costs that can be connected to the incident directly and those which are indirectly related to the incident. Among other things, PSPs should take into account expropriated funds or assets, replacement costs of hardware or software, other forensic or remediation costs, fees due to non-compliance with contractual obligations, sanctions, external liabilities and lost revenues. As regards the indirect costs, PSPs should consider only those that are already known or very likely to materialise. Direct costs: amount of money (euro) directly cost by the incident, including funds needed to rectify the incident (e.g. expropriated funds or assets, replacement costs of hard‐ and software, fees due to non‐compliance with contractual obligations). Indirect costs: amount of money (euro) indirectly cost by the incident (e.g. customer redress/compensation costs, revenues lost as a result of missed business opportunities, potential legal costs). High level of internal escalation: PSPs should consider whether or not, as a result of its impact on payment-related services, the Chief Information Officer (or similar position) has been or will probably be informed about the incident outside any periodical notification procedure and on a continuous basis throughout the lifetime of the incident. In the case of delegated reporting, the escalation would take place within the third party. Furthermore, PSPs should consider whether or not, as a result of the impact of the incident on payment-related services, a crisis mode has been or is likely to be triggered. Other PSPs or relevant infrastructures potentially affected: payment service providers should assess the impact of the incident on the financial market, understood as the financial market infrastructures and/or card payment schemes that support it and the rest of the PSPs. In particular, PSPs should assess whether or not the incident has been or will probably be replicated at other PSPs, whether or not it has affected or will probably affect the smooth functioning of financial market infrastructures and whether or not it has compromised or will probably compromise the solidity of the financial system as a whole. PSPs should bear in mind various dimensions such as whether the component/software affected is proprietary or generally available, whether the compromised network is internal or external and whether or not the PSP has stopped or will probably stop fulfilling its obligations in the financial market infrastructures of which it is a member. Reputational impact: PSPs should consider the level of visibility that, to the best of their knowledge, the incident has gained or will probably gain in the marketplace. In particular, PSPs should consider the likelihood that the incident will cause harm to society as a good indicator of its potential to affect their reputation. PSPs should take into account whether or not (
3. i)the incident has affected a visible process and is therefore likely to receive or has already received media coverage (considering not only traditional media, such as newspapers, but also blogs, social networks, etc.), (
4. ii)regulatory obligations have been or are likely to be missed, (iii) sanctions have been or are likely to be breached or (
5. iv)the same type of incident has occurred before. 40 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 B 3 – Incident description Type of Incident: indicate whether, to the best of your knowledge, it is an operational or a security incident. Operational: incident stemming from inadequate or failed processes, people and systems or events of force majeure that affect the integrity, availability, confidentiality, authenticity and/or continuity of payment-related services. Security: unauthorised access, use, disclosure, disruption, modification or destruction of the PSP’s assets that affect the integrity, availability, confidentiality, authenticity and/or continuity of payment-related services. This may happen when, among other things, the PSP experiences cyberattacks, inadequate design or implementation of security policies, or inadequate physical security. Cause of incident: indicate the cause of the incident or, if it is not known yet, the one that it is most likely to be. Multiple boxes may be ticked. Under investigation: the cause has not been determined yet. External attack: the source of the cause comes from outside, and is intentionally targeting the PSP (e.g. malware attacks). Internal attack: the source of the cause comes from inside, and is intentionally targeting the PSP (e.g. internal fraud). Type of attack: Distributed/Denial of Service (D/DoS): an attempt to make an online service unavailable by overwhelming it with traffic from multiple sources. Infection of internal systems: harmful activity that attacks computer systems, trying to steal hard disk space or CPU time, access private information, corrupt data, spam contacts, etc. Targeted intrusion: unauthorised act of spying, snooping and stealing information through cyberspace. Other: any other type of attack the PSP may have suffered, either directly or through a service provider. In particular, if there has been an attack aimed at the authorisation and authentication process, this box should be ticked. Details should be added in the free text field. External events: the cause is associated with events generally outside the organisation’s control (e.g. natural disasters, legal issues, business issues and service dependencies). Human error: the incident was caused by the unintentional mistake of a person, be it as part of the payment procedure (e.g. uploading the wrong payments batch file to the payments system) or related to it somehow (e.g. the power is accidentally cut off and the payment activity is put on hold). Process failure: the cause of the incident was poor design or execution of the payment process, the process controls and/or the supporting processes (e.g. process for change/migration, testing, configuration, capacity, monitoring). System failure: the cause of the incident is associated with inadequate design, execution, components, specifications, integration or complexity of the systems that support the payment activity. Other: the cause of the incident is none of the above. Further details should be provided in the free text field. Was the incident affecting you directly, or indirectly through a service provider?: an incident can target a PSP directly or affect it indirectly, through a third party. In the case of an indirect impact, please provide the name of the service provider(s). 41 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 B 4 – Incident impact Building(
6. s)affected (Address), if applicable: if a physical building is affected, please indicate its address. Commercial channels affected: indicate the channel or channels of interaction with payment service users that have been affected by the incident. Multiple boxes may be ticked. Branches: place of business (other than the head office) which is a part of a PSP, has no legal personality and carries out directly some or all of the transactions inherent in the business of a PSP. All of the places of the business set up in the same Member State by a PSP with a head office in another Member State should be regarded as a single branch. E-banking: the use of computers to carry out financial transactions over the internet. Telephone banking: the use of telephones to carry out financial transactions. Mobile banking: the use of a specific banking application on a smartphone or similar device to carry out financial transactions. ATMs: electromechanical devices that allow payment service users to withdraw cash from their accounts and/or access other services. Point of sale: physical premise of the merchant at which the payment transaction is initiated. Other: the commercial channel affected is none of the above. Further details should be provided in the free text field. Payment services affected: indicate those payment services that are not working properly as a result of the incident. Multiple boxes may be ticked. Cash placement on a payment account: the handing of cash to a PSP to credit it on a payment account. Cash withdrawal from a payment account: the request received by a PSP from its payment service user to provide cash and debit his/her payment account by the corresponding amount. Operations required for operating a payment account: those actions needed to be performed in a payment account to activate, deactivate and/or maintain it (e.g. opening, blocking). Acquiring of payment instruments: a payment service consisting in a PSP contracting with a payee to accept and process payment transactions, which results in a transfer of funds to the payee. Credit transfers: a payment service for crediting a payee’s payment account with a payment transaction or a series of payment transactions from a payer’s payment account by the PSP which holds the payer’s payment account, based on an instruction given by the payer. Direct debits: a payment service for debiting a payer’s payment account, where a payment transaction is initiated by the payee on the basis of the consent given by the payer to the payee, to the payee’s payment service provider or to the payer’s own payment service provider. Card payments: a payment service based on a payment card scheme's infrastructure and business rules to make a payment transaction by means of any card, telecommunication, digital or IT device, or software if this results in a debit or a credit card transaction. Card-based payment transactions exclude transactions based on other kinds of payment services. 42 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 Issuing of payment instruments: a payment service consisting in a PSP contracting with a payer to provide her with a payment instrument to initiate and process the payer’s payment transactions. Money remittance: a payment service whereby funds are received from a payer, without any payment accounts being created in the name of the payer or the payee, for the sole purpose of transferring a corresponding amount to a payee or to another PSP acting on behalf of the payee, and/or whereby such funds are received on behalf of and made available to the payee. Payment initiation services: payment services to initiate a payment order at the request of the payment service user with respect to a payment account held at another PSP. Account information services: online payment services to provide consolidated information on one or more payment accounts held by the payment service user with either another PSP or more than one PSP. Other: the payment service affected is none of the above. Further details should be provided in the free text field. Functional areas affected: indicate the step or steps of the payment process that have been affected by the incident. Multiple boxes may be ticked. Authentication/authorisation: procedures which allow the PSP to verify the identity of a payment service user or the validity of the use of a specific payment instrument, including the use of the user’s personalised security credentials and the payment service user (or a third party acting on behalf of that user) giving his/her consent to transfer funds or securities. Communication: flow of information for the purpose of identification, authentication, notification and information between the account-servicing PSP and payment initiation service providers, account information service providers, payers, payees and other PSPs. Clearing: a process of transmitting, reconciling and, in some cases, confirming transfer orders prior to settlement, potentially including the netting of orders and the establishment of final positions for settlement. Direct settlement: the completion of a transaction or of processing with the aim of discharging participants’ obligations through the transfer of funds, when this action is carried out by the affected PSP itself. Indirect settlement: the completion of a transaction or of processing with the aim of discharging participants’ obligations through the transfer of funds, when this action is carried out by another PSP on behalf of the affected PSP. Other: the functional area affected is none of the above. Further details should be provided in the free text field. Systems and components affected: indicate which part or parts of the PSP’s technological infrastructure have been affected by the incident. Multiple boxes may be ticked. Application/software: programs, operating systems, etc. that support the provision of payment services by the PSP. Database: data structure which stores personal and payment information needed to execute payment transactions. Hardware: physical technology equipment that runs the processes and/or stores the data needed by PSPs to carry out their payment-related activity. Network/infrastructure: telecommunications networks, either public or private, that allow the exchange of data and information during the payment process (e.g. the internet). 43 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 Other: the system and component affected is none of the above. Further details should be provided in the free text field. Staff affected: indicate whether or not the incident has had any effects on the PSP’s staff and, if so, provide details in the free text field. B 5 – Incident mitigation Which actions/measures have been taken so far or are planned to recover from the incident?: please provide details about actions that have been taken or planned to be taken to temporarily address the incident. Have the Business Continuity Plans and/or Disaster Recovery Plans been activated?: please indicate whether or not and, if so, provide the most relevant details of what happened (i.e. when they were activated and what these plans consisted of). Has the PSP cancelled or weakened some controls because of the incident?: please indicate whether or not the PSP has had to override some controls (e.g. stop using the four eyes principle) to address the incident and, if so, provide details of the underlying reasons justifying the weakening or cancelling of controls. C – Final report C 1 – General details Update of the information from the intermediate report (summary): please provide further information on the actions taken to recover from the incident and avoid its recurrence, analysis of the root cause, lessons learnt, etc. Date and time of closing the incident: indicate the date and time when the incident was considered closed. Are the original controls back in place?: if the PSP had to cancel or weaken some controls because of the incident, indicate whether or not such controls are back in place and provide any additional information in the free text field. C 2 – Root cause analysis and follow-up What was the root cause, if already known?: please explain which is the root cause of the incident or, if it is not known yet, the preliminary conclusions drawn from the root cause analysis. PSPs may attach a file with detailed information if considered necessary. Main corrective actions/measures taken or planned to prevent the incident from happening again in the future, if already known: please describe the main actions that have been taken or are planned to be taken to prevent a future reoccurrence of the incident. C 3 – Additional information Has the incident been shared with other PSPs for information purposes?: please provide an overview of which PSPs have been contacted, either formally or informally, to debrief them about the incident, providing details of the PSPs that have been informed, the information that has been shared and the underlying reasons for sharing this information. Has any legal action been taken against the PSP?: please indicate whether or not, at the time of filling out the final report, the PSP has suffered any legal action (e.g. been taken to court or lost its licence) as a result of the incident. 44 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 4. Accompanying documents 4.1. Cost-benefit analysis/impact assessment Article 96

(3)of Directive (EU) 2015/2366 on payment services in the internal market (PSD2) mandates the EBA to issue Guidelines to payment service providers on the classification and notification of major operational or security incidents, and to competent authorities on the criteria to assess the incidents’ relevance and on the provision of information to other domestic authorities. Article 16

(2)of the EBA Regulation provides that the EBA should carry out an analysis of ‘the potential related costs and benefits’ of any Guidelines it develops. This analysis should provide an overview of the findings regarding the problem to be dealt with, the solutions proposed and the potential impact of these options. This annex contains the impact assessment from adopting the Guidelines on incident reporting. A. Problem identification The market for payment services in the Union is developing very dynamically, with the number of users and providers of innovative payment services rising continuously, 2 increasing the need for an adequate regulatory and governance framework. PSD2 brings important improvements to the legal framework of the Union payment market. The Directive requires payment service providers to establish a framework to maintain effective incident management procedures, including for the detection and classification of major operational or security incidents. Article 96

(1)of the Directive demands that payment service providers shall report major operational or security incidents to the competent authorities in their Member State. Article 96

(2)states that competent authorities are expected to notify such incidents to the EBA and the ECB and to assess their relevance, in order to inform other national authorities accordingly. The baseline scenario, the status quo, is the currently established incident reporting based on the requirements set by each Member State if compulsory payment-related incident reporting is already in place. The EBA stock-taking exercise depicts the current status of payment-related incident reporting in Union Member States. In general, the result states that, as the reporting of operational or security incidents is developing, there are disparities in the criteria presently applied by competent authorities for the fulfilment of reporting obligations, individual payment service providers’ judgments about the appropriateness of a notification prevail and most reporting procedures currently in place are unstructured. The status quo thus allows competent authorities to apply different standards on the reporting needs, leading to different 2 EBA

(2016), EBA Consumer Trends Report 2016; European Commission

(2015), Green Paper on Retail Financial Services 45 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 administrative obligations on payment service providers in different Member States and thereby hampering the establishment of a level playing field and internal market for payment services in the Union. To address these issues, these Guidelines on incident reporting specify the criteria for the classification of major operational or security incidents by payment service providers as well as the format and procedures they should follow to communicate such incidents to the competent authorities in the home Member State. In addition, the Guidelines determine the criteria that should govern the sharing of incident-relevant information between competent authorities and other domestic authorities and harmonise the reporting process between competent authorities and the EBA and the ECB. B. Policy objectives This Final Report introduces three sets of Guidelines consisting of separate Guidelines addressed to payment service providers, to competent authorities reporting to other domestic authorities, and to competent authorities reporting to the EBA and the ECB. In general, the outlined Guidelines contribute to the EBA’s objective of fostering regulatory and supervisory convergence and the development of a single market for payment services in the Union. They will contribute to consistent, efficient and effective implementation of the provisions of PSD2 and enhance supervisory convergence across Member States. 3 More specifically, the framework proposed by these Guidelines could contribute to maintaining effective incident management procedures and establishing a common and consistent approach regarding the reporting process. The notification of other national authorities as well as the EBA and the ECB contributes to improving the assessment of the collective impact on the different stakeholders in the domestic and Union payment service markets. It also fosters prompt reaction to incidents, the containment of potential spill-over effects and the prevention of future similar events. This restricts the negative impact of major operational and security incidents, which could affect the integrity, availability, confidentiality, authenticity and/or continuity of the services provided by the payment service provider. Therefore, the Guidelines help to ensure that the damage to users, other payment service providers or the payment systems from operational and security incidents is minimised. Operationally, the Guidelines are drafted considering several options, with a view to incorporating current national payment-related incident requirements and to considering the legal status and size of various types of payment service providers under the scope of PSD2. 3 EBA

(2015), EBA Annual Report; EBA

(2016), Work programme 2017 46 FINAL REPORT ON GUIDELINES ON MAJOR INCIDENT REPORTING UNDER THE PSD2 C. Options considered and preferred option During the drafting process, the prevailing classification methods, which differ widely among Member States and have a material impact on payment service providers and competent authorities, were of major concern. The EBA’s stock-taking exercise shows that, while currently incidents tend to be categorised according to a compulsory requirement, in some jurisdictions reporting agents themselves can decide on the severity of the incident and if reporting is needed. In jurisdictions in which a categorisation is predefined, usually a combination of quantitative and qualitative criteria is used to determine the incident category. In general, criteria thresholds are not always clear-cut and definitions may differ substantially from one authority to another. Not only are there differences in the applicable thresholds but sometimes they are defined very broadly, thus leaving room for interpretation. In the preferred option, the Union-wide criteria and thresholds to determine whether or not an operational or security incident is major are defined. As summarised in Table 1 of Guideline 1 on incident classification, a combination of seven quantitative and qualitative criteria is retained. They are chosen based on most commonly used practices in the Member States. In general, they