At 09:00 in London a payments platform stops processing. The banking group that runs it has regulated entities in London, Dublin, New York, Toronto and Riyadh, and every one of them depends on that platform. In Dublin it is also 09:00 and in Riyadh it is 11:00. In New York and Toronto it is 04:00, and the people who would normally speak to the regulator are asleep.
By 09:40 the technology teams are on one bridge call, working the fault. Nobody yet knows whether the cause is a failed change or an attack. The compliance leads are not on that call. Each has opened a local reporting procedure and started a draft for a local regulator, using whatever they were told by whoever they reached first.
The questions they are asking are reasonable ones. When was the outage detected, and by whom? Has anyone classified it as major? How many customers are affected in this country, and who is allowed to say so?
On paper, reporting one incident to regulators in several countries is five compliance tasks. On the day it turns out to be one coordination task with five outputs, and the difference shows inside the first hour.
Five regulators will accept five formats and five deadlines. They are far less comfortable with five different accounts of the same morning.
Reporting One Incident To Regulators In Several Countries Starts From One Record
Cross-border incident reporting is the work of telling each supervisor, on its own timetable and in its own format, about a single operational event from one agreed set of facts. The reports differ in template, language and deadline. The detection time, the classification decision, the affected services and the customer impact should read the same in every one.
The principle that follows is easy to state. Local teams own the relationship with their regulator, and one person owns the facts all of them rely on. Without that person each report is accurate to what its author knew at the time, and the set of reports does not agree.
Which Regulators Ask About One Outage, And When?
A financial group with entities in the UK, Ireland, the United States, Canada and Saudi Arabia answers to at least five supervisors after a major outage, and each one sets its own timetable. The wording below is taken from the regulators’ own publications. What starts each clock matters more than the number of hours.
- United Kingdom. The FCA’s finalised guidance on operational incident reporting applies from 18 March 2027 as part of a single FCA, PRA and Bank of England regime. It expects a report as soon as practicable, and within 24 hours of the firm determining that a reporting threshold is met (FCA 2026). Until then the FCA’s current notification process applies.
- Ireland. DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025, and firms regulated by the Central Bank of Ireland report major ICT-related incidents to it. The European Banking Authority’s summary of the reporting standards gives the initial notification as 4 hours after classification and 24 hours after detection (EBA 2025).
- United States. OCC Bulletin 2021-55 requires a bank to notify the OCC as soon as possible and no later than 36 hours after the bank determines that a notification incident has occurred (OCC 2021).
- Canada. OSFI’s Technology and Cyber Security Incident Reporting Advisory requires federally regulated financial institutions to report within 24 hours, or sooner if possible, and then to send regular updates until all details have been provided (OSFI 2021).
- Saudi Arabia. SAMA’s requirements sit in more than one framework. Its IT Governance Framework asks a member organisation to inform SAMA immediately on identifying an incident classified medium or above that affects customers, and to submit a detailed incident report within five days. Its Cyber Security Framework sets a separate immediate notification for medium or high classified security incidents.
Requirements vary by entity, incident type and jurisdiction, so the list is orientation and each obligation should be confirmed against the primary text. Whether a rule is triggered depends on the cause and the impact in that country, and that assessment belongs to the local entity.
What the five have in common is where the clock starts. The UK and US rules run from a determination the firm makes. DORA runs from classification as well as detection. The Saudi rules turn on how the incident has been classified.
So the timetable each regulator sees depends on when somebody in the group decided what kind of incident this was, and five teams deciding separately will produce five answers. The post on DORA major incident reporting timelines covers the European clock in detail.
The Financial Stability Board acknowledged the wider problem in April 2025, when it published FIRE, the Format for Incident Reporting Exchange. FIRE is a common framework firms can use to report operational incidents, and it was written to reduce fragmentation in incident reporting and enhance cross-border cooperation (FSB 2025). A common format helps with the paperwork, but it doesn’t settle who inside the firm holds the facts.
Approach One: Every Country Team Reports Alone
When every country team reports alone, each compliance lead gathers the facts independently, applies a local classification and submits on a local clock. The approach feels safe because it matches the organisation chart. It fails because the incident doesn’t follow the organisation chart.
Back in the scenario, the London lead takes the detection time from the service desk ticket, which says 09:07. The Dublin lead speaks to a platform engineer who says monitoring fired at 08:52.
The Riyadh lead is told by local operations that customers began complaining at 11:20 local time, which is 09:20 in London. The New York duty officer is woken at 05:15 and hears a summary third hand.
By midday the drafts disagree on the things a supervisor reads first:
- Detection time: 08:52, 09:07 or 09:20, depending on who was asked
- Classification: London has called it major, Dublin is waiting for impact numbers and Toronto has not been asked
- Customer impact: each entity has counted its own customers, and nobody holds the group figure
- Cause: one draft says a failed change, another says under investigation
None of those drafts is careless. The FCA’s review of the July 2024 CrowdStrike outage found that the timing and completeness of incident notifications from firms varied extensively (FCA 2024). That was inside a single jurisdiction. Across five, with five authors, variation is the expected result unless somebody is assigned to prevent it.
The engineers pay a second cost. Each compliance lead needs the same handful of facts, so the bridge call is interrupted five times for them.
Approach Two: One Coordinator, Five Local Submissions
Under the second approach a single group incident coordinator holds the record of the incident, and the local compliance leads draw every report from it. Submission stays local. The facts are held once, by one named person, for the whole group.
In practice the coordinator does five things:
- Records one detection time, and the evidence for it
- Records the group classification decision, who made it and when
- Sends a facts update at a fixed interval, for example every 30 minutes, which every local lead receives at the same moment
- Keeps a running list of which regulator has been told what, by whom and at what time
- Wakes the entities that are out of hours, so they do not find out from a customer
In the scenario, the coordinator’s first update goes out at 09:25 and looks like this:
“Facts update 1, 09:25 London. Payments platform unavailable since 08:52 (monitoring alert). Classified as major at 09:20 by the group incident lead. All five entities affected. Cause not yet known, cyber not ruled out. Customer impact figures at 10:00. Local leads: confirm receipt and your regulator’s notification status.”
The New York and Toronto leads are phoned at 04:30 their time and sent the same message. When they later determine whether a local threshold has been met, the times in their record match London’s.
The coordinator doesn’t overrule them. The Toronto entity may reasonably conclude that its own impact is small, and the Riyadh entity may classify the incident differently under its own framework. Each of those local decisions is recorded against the same facts, so the differences between reports can be explained.
The Two Approaches Side By Side
The two approaches differ on six practical questions, and none of them is about which regulator has the shortest deadline. The table shows what a group can expect from each during the first day.
Question | Each country reports alone | One coordinator, local submissions |
When was it detected? | Whatever time the local lead was given | One time, with its source, in every report |
Who classified it? | Each entity separately, at different times | One group decision on record, with local decisions recorded against it |
Where do impact figures come from? | Local counts and no group total | One set of figures, issued at a stated time |
Who interrupts the engineers? | Every compliance lead | One coordinator |
Which regulators have been told? | Nobody knows until the review | A running list every lead can see |
What happens out of hours? | Sleeping entities start late, from second-hand accounts | They are called and start from the same record |
Who Coordinates Regulator Notifications In A Multinational Bank?
Regulator notifications in a multinational bank are best coordinated by the person running the incident response for the group, usually a group incident lead or an operational resilience manager. The local compliance leads act as named owners for each regulator. The coordinator is not the head of compliance for any one country.
The reason is access. The coordinator sits inside the response, hears the classification decision as it is made and has the authority to ask the technical lead for a fact once. A compliance lead in Dublin knows the Central Bank of Ireland’s expectations well and is rarely on the bridge call.
Three things stay outside the coordinator’s job:
- The judgement on whether a local reporting threshold has been met
- The wording of each submission and any conversation with the supervisor
- Legal advice on what should be disclosed and when
Owning The Regulator Is Not The Same As Owning The Facts
The common belief is that each country team handles its own regulator, and it is mostly right. Local leads know the supervisor, the template and the language, and no group function should be filing on their behalf. The belief fails at one point: it assumes each team can also establish the facts alone.
The facts belong to the incident, and the incident is group-wide. A local lead cannot know when the group classified the outage unless somebody tells them.
The forms also ask for the same things in different words. The FCA’s guidance requires a firm to confirm the time at which the incident was detected. The formal incident report under SAMA’s Cyber Security Framework asks for the date and time the incident occurred and was detected, the root-cause analysis and the impact.
The honest objection to a single coordinator is that one person becomes a bottleneck. Fixed-interval updates and a deputy deal with that. Going back to five separate investigations removes the bottleneck and brings back the five versions.
Six Things To Agree Before The Next Outage
Cross-border regulatory notifications are easier when six things are settled in advance, because none of them can be agreed calmly at 09:10 on the day. Six items, and each fits on one line of a plan:
- The group coordinator, and a deputy in a second time zone
- One named owner per regulator, with a deputy and an out-of-hours number for both
- The common facts every report will use: detection time, classification, services affected, customer impact, cause status and the time of the next update
- The update interval, and the list of people who receive each update
- Who may speak informally to a supervisor before the written report goes in
- A notification log with four columns: regulator, owner, time told and what was sent
A quick way to test the list is to take one incident from the past year and write down every regulator, in every country, that could have asked about it. Then name the person who would have answered each one. The gaps usually sit with the entities that were asleep at the time.
What Incident Manager Records, And What Stays With Compliance
Most groups already have ways to tell people an incident has started. Communication tools send notifications, but they don’t coordinate the updates, acknowledgements and response activity that follow.
Crises Control is an operational incident coordination platform, and its Incident Manager module is built for the coordinator’s side of this problem. The idea is the one this article has followed: one incident record, one coordinated response and several local submissions drawn from it.
The coordinator launches a predefined incident response plan from one structured workspace. The regulatory leads can be set up in advance as a recipient group, with a facts-update template and each entity’s reporting procedure attached to the plan.
Acknowledgement tracking shows who has responded and who needs chasing, which matters when two of the five leads were asleep. Every communication, acknowledgement, update and decision is timestamped and retained as a complete incident record, and the record can be exported.
Crises Control supports retail and investment banks, insurers, asset managers and payment providers. The page on operational resilience software for financial services describes its use across the incident lifecycle, and the compliance management software page covers audit, governance and regulatory evidence.
The software does not decide whether an incident is reportable, and it does not file anything with a regulator. Those remain decisions and actions for the firm’s compliance leads. Its role is to give all of them one timestamped record to work from.
One Outage Should Produce One Account
Go back to 09:40 in London. With a coordinator in place the five compliance leads are still drafting five reports for five regulators, as they should be. But every draft now carries 08:52 as the detection time, 09:20 as the classification time and the customer figures issued at 10:00. Monday’s post in this series, on the Martyn’s Law lockdown procedure for venue staff, ends on the same question from a very different setting: who was told what, and when.
Five regulators may require five submissions. They should not receive five versions of the incident. The response needs one agreed record, one clear owner for the facts and a visible log of what each regulator has been told.
Frequently Asked Questions
What does cross-border incident reporting involve for a financial group?
Reporting one incident to regulators in several countries involves notifying each supervisor in its own format and on its own timetable about a single operational event. The reports differ in template and deadline. The detection time, classification, affected services and customer impact should be the same in all of them.
Who coordinates regulator notifications in a multinational bank?
The group incident lead or operational resilience manager usually coordinates regulator notifications, because that person is inside the response and hears each decision as it is made. Local compliance leads remain the named owners for each regulator. They decide whether a local threshold is met and they make the submission.
Do all financial regulators set the same incident reporting deadline?
No. OSFI in Canada requires a report within 24 hours, or sooner if possible (OSFI 2021), and the OCC in the United States sets a limit of 36 hours after a bank determines that a notification incident has occurred (OCC 2021). DORA’s initial notification is due 4 hours after classification (EBA 2025).
How can banks avoid inconsistent regulator notifications?
Banks avoid inconsistent regulator notifications by keeping one group incident record and appointing a coordinator for the shared facts. Each regulator has a named local owner who makes the submission. A timestamped notification log shows what each regulator has received.
What information should be consistent across cross-border regulatory reports?
Detection time, incident classification, affected services, customer impact, known cause, response actions and the timing of the next update should be the same in every report. All of them should come from one agreed incident record. Template, language and deadline will differ by regulator.
This article was drafted with AI assistance and reviewed by the Crises Control team. Featured image: AI-generated.
