During a trading outage, the most useful message is not “our engineers are investigating.” It is a clear statement of what has failed, which services remain available, what is known about outstanding orders, and when the next update will arrive.
Outage communication between brokers, exchanges, and traders should reduce uncertainty without pretending it has disappeared. A trader needs to know whether an order might still execute. A broker needs reliable venue information before advising clients. An exchange needs participants to follow recovery instructions rather than improvise.
This is a practical part of communication in trading operations: keeping service status, order status, and client instructions consistent from the first warning through recovery. The aim is not more messages. It is fewer dangerous assumptions.
Identify What Is Down Before Describing the Impact
“Trading is unavailable” is often too broad to guide a decision. An incident notice should distinguish account access, price data, order entry, cancellations, execution reporting, and the trading venue itself. Treat each as a separate service until its condition is confirmed.
A working login does not establish that order entry works. A moving chart does not establish that execution reports are current. Equally, a frozen screen does not prove that an order has stopped working at the venue.
| Affected service | What the notice should clarify | Assumption to avoid |
|---|---|---|
| Website or application access | Which access methods are affected and whether an approved alternative is available | All trading systems have stopped |
| Market data | Affected feeds, instruments, and the last verified data time | The displayed price is current |
| Order entry or routing | Whether submissions are rejected, queued, or awaiting confirmation | A timeout means rejection |
| Cancellations | Whether requests can be submitted and whether completion is confirmed | Pressing cancel removes the order |
| Execution reporting | Whether reports are delayed and how individual orders will be checked | No reported fill means no execution |
Check the affected exchange’s official notices alongside the broker’s incident updates. The NYSE market and system status history provides a venue-level record of notices. Use it to check what the exchange has published, not as proof that every broker connection or customer account is healthy.
Keep trading halts separate from technical outages. Describe the affected instrument, venue, or service rather than calling every interruption a market shutdown. Where the cause remains unverified, say so.
Make Order Uncertainty the First Trading Risk
The hardest question during an outage is often straightforward: did the order get through?
A useful incident message separates the customer’s submission attempt from the broker’s receipt, venue acceptance, execution, and cancellation. These are different events. A request acknowledged by an application is not necessarily an order accepted by the venue.
Consider a hypothetical purchase of 100 shares. The trader submits the order, receives a timeout, and submits another 100 shares through a second channel. If the original order was accepted, the trader may now have twice the intended purchase. Changing the access channel does not resolve the first order’s status.
Do not treat a missing response as a rejection, or a cancellation request as a completed cancellation. The SEC’s online investing guidance on execution and cancellation checks warns against duplicate submissions and advises investors to confirm that a cancellation worked before placing another trade.
For brokers, “status unknown” should be a visible, actionable condition rather than an error message that disappears on refresh. Customer support should explain how the order will be investigated, give a case reference, and avoid promising that an unconfirmed order cannot execute.
For traders, retain the order identifier, instrument, side, quantity, order type, submission time, and any acknowledgement. When contacting support, ask for the accepted quantity, executed quantity, remaining quantity, and confirmed cancellation status. “Is everything working?” is a much less useful question.
Assign Ownership Across the Communication Chain
A practical outage plan should name an incident lead, a technical status owner, an order reconciliation owner, and a communications owner. Smaller firms may combine roles, but the responsibilities should remain explicit.
The technical team should verify service condition. Trading operations should verify order handling and exposure. Customer support should receive approved instructions. The communications owner should turn those facts into notices that different audiences can use.
Exchange and broker messages serve different purposes. A venue notice may describe a gateway or trading segment. The broker should translate that into client impact: affected products, available functions, restrictions, and the process for checking outstanding instructions. Forwarding a technical bulletin without explanation leaves the customer to do the broker’s interpretation.
Use one incident identifier across public notices, internal updates, and support cases. Maintain an approved facts record with timestamps and named owners. If a fact changes, update the record and correct the affected messages rather than allowing competing versions to circulate.
Use Channels That Survive the Incident
An outage plan should not depend entirely on the application experiencing the outage. Give customers a status channel they can reach without signing in, and test whether it remains available when the main service fails.
Use a public incident page for shared service updates and authenticated support for account details. Email, SMS, and push notifications can direct customers to the current notice, but should not become competing versions of it. A short alert should identify the incident, affected service, timestamp, and location of the full update.
Choose trading alert channels around delivery needs and failure scenarios. A notification is useful only if the intended recipient can receive it, recognise it, and find the instruction that matters.
Fallback channels also need boundaries. If telephone dealing is available, state which products it supports, its operating hours, any applicable charges, and whether staff can accept new orders or only investigate existing ones. Do not advertise a workaround before confirming that the team can provide it.
Keep account numbers, holdings, credentials, and order details out of public threads. Traders should use previously verified contact routes rather than numbers or links supplied by unsolicited accounts claiming to offer outage assistance.
Write Updates Around Decisions, Not Reassurance
The first notice should acknowledge a confirmed service problem promptly, even if the cause remains unknown. Waiting for a complete technical diagnosis can leave customers guessing about what they should do with outstanding instructions.
Each substantive update should answer five questions:
- What is affected? Name the service, products, venues, or customer group.
- What still works? Include only functions that have been verified.
- What is known about orders? Separate confirmed states from unresolved ones.
- What should customers do? Give an instruction or a verified support route.
- When is the next update? Include a time zone and distinguish this from a restoration estimate.
Publish material changes immediately and set a review interval appropriate to the incident. There is no universal update frequency that suits every market and service. If nothing has changed by the promised update time, say that checks continue and provide the next update time.
A commitment to publish again at 14:30 UTC is not a promise to restore service at 14:30 UTC. Keep those statements separate. “Soon” is not an operational instruction.
Example of a Useful Initial Notice
The following is an illustrative notice, not a report of a real incident:
14:10 UTC — Incident OPS-104: We are investigating delayed order acknowledgements for equities submitted through our mobile application. Website order entry has been verified as available; the status of orders already submitted through the mobile application may remain unresolved.
Do not resubmit an order solely because its acknowledgement is missing. Contact our established dealing support channel with your order reference so we can check its status. A cancellation request does not confirm cancellation. We have not confirmed a restoration time. Our next update will be published by 14:25 UTC.
This notice gives a bounded impact statement, an action, and a publication commitment. It avoids guessing at the cause or claiming that every customer is affected.
Separate Good Practice From Regulatory Duties
Communication procedures should reflect the firm’s jurisdiction, permissions, products, and regulatory obligations. A public status notice is not a substitute for a required regulatory notification, and a regulator filing is not a substitute for useful customer instructions.
In the United States, FINRA Rule 4370 on business continuity plans requires member firms to maintain a written continuity plan, review it annually, and update it following material changes. Its required categories include alternative customer and employee communications, regulatory reporting, and communications with regulators, to the extent applicable and necessary.
Build those obligations into the incident workflow before an outage. Identify who assesses reporting requirements, who approves notices, and who covers each role if the usual decision maker cannot be reached. A communications plan that waits indefinitely for one person’s approval is another point of failure.
For firms within the scope of the UK operational resilience framework, FCA SYSC 15A.8 on disruption communications requires internal and external communication strategies and clear, timely, relevant stakeholder messages. Its guidance also addresses advance warning arrangements and the circumstances, needs, and vulnerabilities of recipients.
Keep customer language practical regardless of jurisdiction. Explain whether a service is unavailable, whether an instruction remains unresolved, and where help is available. Technical precision is useful; unexplained internal terminology is not.
Communicate Recovery in Stages
“Service restored” should describe a verified condition, not the moment a server starts responding. A recovery notice should distinguish connectivity, order handling, data freshness, account reconciliation, and any remaining restrictions.
A sensible sequence is to announce restored connectivity, confirm which functions have passed checks, identify unresolved orders or reports, and explain when normal activity can resume. Where recovery is partial, label it partial.
Exchange recovery instructions may require participant action. The NYSE disaster recovery FAQ states that connections targeting production addresses are not automatically redirected to its recovery site; customers must use the recovery session addresses and ports. Do not assume every venue uses the same arrangement.
For traders, the relevant message is the resulting service condition, not the infrastructure detail. A broker should say whether clients can enter orders, receive current execution reports, and rely on reconciled positions. “We have switched sites” does not answer those questions.
Before resuming automated submissions, require the responsible team to check outstanding orders, execution reports, positions, and queued instructions. Do not blindly replay requests whose outcomes remain unknown. Recovery should reduce uncertainty before adding fresh activity.
Keep broader failover design separate from the incident notice. Customers need the consequence of the recovery step and any action required from them, not the entire engineering runbook.
Close the Incident Without Losing the Evidence
The closing notice should state which services have recovered, when recovery was verified, what issues remain, and how customers can raise an order or account discrepancy. If the cause is still under investigation, distinguish service restoration from completion of the investigation.
Preserve message versions, publication times, approvals, support cases, and the evidence behind order-status decisions. Include relevant phone and chat communications within the firm’s approved recording and retention arrangements. The related guide to trading communication records and retention covers that wider process.
A post-incident review should assess communication separately from technical recovery. Review the time to acknowledge customer impact, missed update commitments, contradictory instructions, unanswered order queries, and whether fallback channels worked under demand. Assign corrective actions to named owners with completion dates.
Traders should also retain their own incident timeline and raise discrepancies promptly through the broker’s formal process. Record what was submitted, what response appeared, and what support confirmed. An intended trade, a submitted instruction, and an executed transaction are not interchangeable evidence.
Effective outage communication ends with a usable account of what happened: which services failed, how outstanding orders were resolved, and what customers can safely rely on now. A green status indicator is helpful. Clear order and account information is what makes it meaningful.