Most continuity plans I read were written for a company that sells software or advice. They cover email, payroll and the office. They do not answer the question a trading firm's clients will ask within ninety seconds of an outage: my position is open, the market is moving, and I cannot close it.
That is the difference. In a trading business the loss during downtime accrues to clients in real time, and the complaints, the regulatory questions and sometimes the compensation follow from how the firm handled those minutes.
Start from the business impact analysis
Before recovery targets there has to be an inventory of what the firm actually does and how long each function can be unavailable before harm is material. For a retail broker or prop firm the list is short and the tolerances are very different.
| Function | Tolerance for downtime | Why |
|---|---|---|
| Order execution and position closing | Minutes | Client exposure moves continuously and cannot be paused |
| Price feed and risk monitoring | Minutes | Margin and hedging decisions depend on live prices |
| Client portal and support channels | Short | Clients need to reach someone who can act on their account |
| Deposits | Hours | Delayed funding is an inconvenience, not an exposure |
| Withdrawals | Hours to a day | Delay is tolerable briefly, then becomes a conduct issue |
| Reporting and reconciliation | A business day | Deadlines are daily, so a same day recovery holds the line |
Those tolerances then become recovery time and recovery point objectives per system, rather than one number applied to everything. A firm that sets a single recovery target for the whole business either overspends on the back office or underspends on execution.
The failures worth planning for
Hardware failure is the easy case and rarely the one that hurts. The scenarios that actually take trading firms offline are a data centre or cloud region loss, a liquidity provider or bridge failing while the platform stays up, a payment route being suspended without notice, a denial of service attack during a news release, and loss of access to a system because a key person left or a single credential expired.
Two of those deserve specific plans. A liquidity failure with a working platform is worse than a platform failure, because clients keep trading against prices the firm can no longer hedge. The plan needs a documented decision on whether pricing is suspended, and who makes that call in the moment. The relationships behind it are covered in brokerage liquidity providers.
The key person case is unglamorous and common. If one person holds the credentials to the trading server, the DNS or the payment portal, the firm has a continuity gap regardless of how good the infrastructure is.
What clients are told, and when
Communication is the part regulators examine after the fact, because it decides whether an outage became a conduct issue. The plan should fix in advance which channel carries the first notice, who is authorised to publish it without waiting for a full diagnosis, what is said about open positions, and how clients request manual intervention on an account they cannot reach.
A firm that goes silent for an hour and then posts a technical explanation is in a worse position than a firm that says within five minutes that trading is unavailable, that it is working on it, and that clients should contact support for urgent position changes. The second version generates work. It also generates far fewer complaints and a much better answer when the regulator asks what you did. Where the event crosses a reporting threshold, the timeline in incident reporting obligations starts running from awareness, not from resolution.
Operational resilience requirements differ sharply by regime, and some regulators set explicit testing, mapping and tolerance rules. Treat this as the shape of the exercise rather than your obligations, and confirm the specifics with advisers in your licensing jurisdiction.
Testing, because an untested plan is a draft
The plan gets tested on a schedule the board sets, and the test produces evidence: what was simulated, who took part, what failed, what was changed afterwards. Restoring a backup once a year is not a test of continuity, it is a test of backups. A worthwhile exercise runs the decision making too, with the named people, on a scenario where the answer is genuinely unclear.
Firms operating under regimes with formal resilience rules will find the testing expectations spelled out, and the EU version is described in DORA regulation explained. Vendors sit inside the same perimeter, which is why the register described in keeping an outsourcing register and the continuity plan are usually maintained together.
Vendor dependencies are your dependencies
Most firms today are assembling a stack rather than building one: platform, CRM, KYC provider, payment providers, hosting, market data. Continuity planning means knowing each vendor's own recovery commitments, whether you have contractual notice of their incidents, and what your manual fallback is for the hour their service is down.
The uncomfortable answer for some functions is that there is no fallback, and the plan should say so rather than pretend. That honesty is what tells a reviewer the document was written by someone who runs the firm. When we designed eTrader the assumption was that a firm needs its own visibility of positions and client state during an incident, because a plan that depends entirely on a vendor's dashboard being up is not a plan.
"Ask a firm what happens to an open position when the platform is down for twenty minutes. If the plan does not answer that in plain words, the rest of it is just an IT document with a compliance cover page."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- Set recovery objectives per function, because execution tolerates minutes while reporting tolerates a business day.
- Plan separately for a liquidity or bridge failure while the platform is still quoting, and decide who suspends pricing.
- Fix the first client message and its channel in advance, including what clients do about open positions.
- Test the decisions and the people, not only the backups, and keep the evidence of what failed and what changed.
Frequently Asked Questions
What should a trading firm's continuity plan cover that a generic BCP does not?
Open positions. The plan needs a documented answer for what happens to client exposure while systems are unavailable, who can suspend pricing, how manual position changes are requested and authorised, and what clients are told in the first minutes.
How often should the plan be tested?
On a cycle the board sets and after any material change to the systems or the model, with evidence retained of what was simulated and what changed as a result. Some regimes set explicit testing expectations, so check what applies to your licence.
Do vendor outages count as our problem?
In supervisory terms, yes. Using a third party for a function does not move the obligation, so the plan should record each vendor's recovery commitments, your notice rights and the manual fallback, and say plainly where no fallback exists.
About the Author
Roman Onta is an Executive Director at SINGUARD. He builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals side by side with his brother Alex Onta, and he helped on the design of eTrader, the division Alex built and leads. His ground is worldwide payment processing, AML compliance and the corporate structures brokers are built on, work the two of them carry together, shaped by executive roles in the UAE and international corporates. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.