A trading platform goes down for two hours during the London session. A support mailbox turns out to have been accessible to a former contractor. Both are incidents. Neither is one report.
Depending on the firm's licences and where its clients are, that platform outage could be an operational incident notification to the financial regulator, and separately a matter for client communications and complaint handling. The mailbox case could be a personal data breach notification to a data protection authority, an ICT incident report under an operational resilience regime, and an internal investigation that ends in a suspicious activity report if it turns out client funds were touched.
The four families of reporting duty
Trading firms typically sit under several reporting regimes at once, and the categories behave differently.
Operational and ICT incidents. Financial regulators expect to be told about significant disruptions to regulated services. Where an operational resilience framework applies, the criteria for a major incident, the reporting stages and the templates are defined in the rules rather than left to judgement. The EU version is set out in DORA regulation explained.
Personal data breaches. Privacy regimes run on their own clock and their own thresholds. Under the GDPR the controller notifies the supervisory authority within 72 hours of becoming aware of a breach, unless it is unlikely to result in a risk to individuals, and notifies affected people directly where the risk to them is high. Trading firms hold identity documents and payment data, which raises the likelihood that a breach clears the threshold. See GDPR for trading firms.
Financial crime reports. Suspicion of money laundering or terrorist financing goes to the financial intelligence unit, not to the prudential regulator, and it goes through the firm's money laundering reporting officer. These reports carry confidentiality duties: tipping off the customer is an offence in most regimes. The internal route belongs in the AML policy, and the role is described in the MLRO role.
Market and conduct notifications. Suspected market abuse, breaches of the firm's own rules, material client money shortfalls and significant complaints trends carry their own routes. So does self reporting: many regimes require a firm to tell its regulator promptly about anything it would reasonably expect notice of, including its own rule breaches.
Awareness starts the clock, not resolution
The single most common failure is waiting to understand the incident before reporting it. Deadlines generally run from the point the firm becomes aware, and initial reports are designed to be incomplete. Regimes with staged reporting expect an initial notification, then an intermediate update, then a final report with root cause. Holding the first report while engineering investigates converts a technical incident into a compliance failure.
Awareness also has to be defined internally. If an engineer sees the anomaly at 02:00 and the compliance officer hears about it at 11:00, which time counts? A firm without an internal escalation rule will be arguing that point with a supervisor after the fact, which is a bad place to invent a policy.
Thresholds, deadlines, formats and recipients differ by regime and by licence. This describes the categories, not your obligations. Map your actual notification duties with counsel or a compliance consultant in each jurisdiction where you are licensed or where your clients are.
Build the map before you need it
The useful artefact is a one page notification map maintained by compliance: for each incident type, which authority, which threshold, which deadline, which template, who signs, and the backup signatory. It sounds bureaucratic until the day the primary contact is on a flight and nobody else knows the portal login.
The map should also record who is told outside the regulator. Clients, if their service or their data is affected. The acquirer or PSP, where a payment incident is involved and contractual notice periods apply. Liquidity providers, where trading is suspended. Insurers, where a policy has notification conditions that void cover if missed.
The evidence trail matters as much as the report
After a serious incident a supervisor tends to ask for the timeline: when it started, when the firm knew, what was decided at each point and by whom, when clients were told, what was restored and when. Firms that reconstruct that from memory produce a defensible version of events. Firms that kept a running incident log during the event produce a record.
Keep the log outside the systems that might be affected, timestamped, with decisions attributed to people rather than to teams. It is the same principle behind compliance audit trails and it costs nothing to set up in advance.
What this changes about how you operate
Two practical consequences. First, incident classification has to be somebody's job in the moment, not a retrospective judgement, because the decision of whether an event is reportable determines whether a deadline is already running. Second, the continuity plan and the notification map belong in the same drill, since the people managing the outage are the people who owe the report. That overlap is why we treat them as one exercise alongside the continuity plan and the escalation lines in the compliance officer role.
A firm that reports early, updates honestly and closes with a root cause is dealing with an incident. A firm that reports late is dealing with two.
"Report it before you understand it. The first notification is allowed to say we do not know yet. What is not allowed is a week of silence while the team works out what happened."
— Alex Onta, Executive Director, SINGUARD
Key Takeaways
- One event can trigger separate reports to a financial regulator, a data protection authority and a financial intelligence unit.
- Deadlines run from awareness, so define internally when the firm is deemed aware and who escalates.
- Keep a one page notification map with authority, threshold, deadline, template, signatory and backup signatory.
- Run a timestamped incident log outside the affected systems, with decisions attributed to named people.
Frequently Asked Questions
How quickly does an incident have to be reported?
It depends on the regime and the type of incident, and deadlines generally run from when the firm becomes aware rather than from when it understands the cause. Under the GDPR, for example, a personal data breach is notified to the supervisory authority within 72 hours of awareness unless it is unlikely to pose a risk to individuals.
Does one incident mean one report?
Often not. A single event can create an operational incident notification to the financial regulator, a personal data breach notification to a data protection authority and, if funds or financial crime are involved, a separate report through the money laundering reporting officer, each with its own threshold and format.
Should we report before the investigation is finished?
Yes, where the threshold is met. Staged reporting regimes expect an initial notification followed by updates and a final root cause report, and delaying the first notification while engineering investigates is treated as a separate failure from the incident itself.
About the Author
Alex Onta is an Executive Director at SINGUARD. He built eTrader, the terminal, the mobile apps, eTrader Broker, Copytrading, Business and Community, along with the worldwide clustered-server infrastructure it all runs on, with his brother Roman Onta helping on the design, and he leads that division today. Together with Roman he builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals, and the two of them carry worldwide compliance, payment processing and international business structuring side by side. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.