BaFin’s Circular 03/2022 (BA) on the reporting of serious payment security incidents has been in effect since October 01, 2022 (we reported on this). BaFin has now published an FAQ in which it provides answers to various questions in connection with the reporting obligation and the reporting procedure.
In the FAQ, BaFin explains in particular how an incorrect report is to be corrected, what payment service providers (PSP) must report if it is not (yet) clear what the scope of a payment security incident is, and what the consequences are if the obligation to submit an initial report falls on a weekend or a public holiday.
Reporting obligation pursuant to Section 54 (1) Sentence 1 ZAG
In Circular 03/2022 (BA), BaFin implemented the changes made by the European Banking Authority (EBA) regarding the obligation to report serious payment security incidents in German banking supervision.
If a serious payment security incident occurs at a payment service provider (this means a payment institution, an e-money institution, as well as a CRR credit institution or the Kreditanstalt für Wiederaufbau (KfW) to the extend they provide payment services), the payment service provider must notify BaFin immediately in accordance with section 54 (1) sentence 1 of the Zahlungsdiensteaufsichtsgesetz (ZAG – German Payment Services Supervision Act) – as implementation of Art 96 PSD2. A three-stage notification procedure is provided for this purpose. This provides for an initial report, (possibly several) interim reports and a final report.
According to Circular 03/2022 (BA), a payment security incident is “an incident consisting of a single event or a chain of events that was not intended by the payment service provider and has or is likely to have an adverse effect on the integrity, availability, confidentiality and/or authenticity of payment-related services”.
The triggering event for the obligation to submit an initial notification is the classification of a payment security incident that is “serious.” This is to be assessed based on a set of criteria, which we have already outlined in our previous post. In its circular 03/2022 (BA), BaFin adopts the benchmarks (divided into low and high impact levels) to classify whether an initial notification has to be submitted. This is the case if at least one of the criteria reaches a “high impact level” or at least three criteria reach a “low impact level”.
If a payment service provider detects a payment security incident, it must classify the incident within 24 hours using the criteria and standards described above. In the event of a serious incident, the initial notification to BaFin must be made within 4 hours. The reclassification/upgrading of an originally non-serious incident into a serious incident also triggers the reporting obligation.
Subsequently, the obligated payment service has to provide an interim report when the regulatory activity has been resumed and regular operation exists. This is the case when the original level of service has been restored and emergency measures are no longer active. A report must also be submitted if regular operations have not been resumed – this report must be submitted within 3 days of the initial report and then on a regular basis.
If regular operations are resumed, a final report must be submitted to BaFin within 20 days of resumption. This period may be extended in consultation with BaFin, stating the reasons. The final report must state the scope of the incident (in concrete figures), the main cause(s) (if available) and the measures that have been taken or are planned to remedy the problem or prevent its recurrence in the future.
Clarifications through FAQ
Apparently, despite it’s circular, BaFin felt compelled to make individual clarifications concerning the reporting obligation under Section 54 (1) sentence 1 ZAG.
Correction of incorrect reports
If a PSP submits an incorrect report, it cannot correct it in the strict sense. Instead, the PSP must submit a new, error-free report. If the process has already been completed, the PSP must do so by means of a new final report, which represents the last report of the process.
In order to enable the corrective report to be assigned, the incident number (incident ID) must be specified.
Dealing with unknown incident data
If exact data on the number of payment transactions or payment service users affected is not available, this does not eliminate the obligation to submit a report. Rather, estimated values are to be provided, which are to be determined by extrapolating historical data. For BaFin’s comprehensibility, comments on the estimate (e.g., method, underlying data, period of backed-up data) must be entered in the comments field of the reporting form.
It should be noted that the starting point for the reporting obligation is the classified serious payment security incident. This obligation does not cease to apply even if the incidents concerned could be made up for or executed by other means. However, this must be explained as part of the notification to BaFin.
Affection of other payment service providers
BaFin also clarifies when other payment service providers are affected and explains examples of how this can occur. This is the case if the security incident also affects or is likely to affect other payment service providers, as well as if the financial market infrastructure as a whole may be affected by the consequences.
By way of illustration, BaFin states that, for example, the impact of software or hardware used throughout the industry, the existence of an incident at a third-party service provider that is (presumably) active throughout the industry, or the failure at one service provider may mean that other payment service providers are affected. Furthermore, the failure of a payment service provider may also have an impact within the financial market infrastructure.
If other payment service providers are (probably) affected in this way, a report must be submitted in accordance with section 54 (1) sentence 1 ZAG.
Initial report on weekends and public holidays
With regard to the submission of an initial report, BaFin clarifies that reportable incidents must also be identified, classified and reported on a weekend or a public holiday. Thus, the requirement to detect and classify payment security incidents represents a minimum requirement. However, this does not mean that the additional monitoring of the functioning of payment services traffic is optional. Finally, the circular did not provide any exemption for weekends or holidays.
Clarifications on the submission of interim reports
Finally, BaFin clarifies the requirements for the submission of interim reports. This must always be done when regular activities have been resumed and regular operations have been restored. However, if regular operations have not been restored within three days of the initial notification, a corresponding interim notification must be submitted. However, a further interim report is only required if there are significant changes to the incident or if regular operation is resumed. If an initial or interim report has already been submitted when a material change occurs, BaFin must be informed of this change in a first or second interim report.
It should be noted that the interim report must always be submitted – this is also the case if the incident can already be remedied on the day of the initial report.
Outlook/Opinion
BaFin’s clarifications through the FAQ are not surprising, but rather clarify what Circular 03/2022 (BA) already regulates. Nevertheless, the clarifications are to be welcomed as they eliminate ambiguities of the players of the (German) financial market regarding the circular. The possibility of correcting incorrect reports by submitting an error-free report provides payment service providers subject to reporting requirements with a familiar tool without expanding and complicating the existing system. This creates (legal) clarity and is therefore to be welcomed.
With the kind support of Manuel Traub, research assistant.
For further information, please contact:
Dr. Michael Jünemann, Partner, Bird & Bird
michael.juenemann@twobirds.com
