Exchange outage risk in automated trading

In automated trading, an exchange connection failure can separate the account’s actual state from what software knows. Data may stop arriving while an earlier order executes, or a page may remain accessible while another service fails. An outage plan should distinguish these situations. Running software does not establish certain account control.

Identify which function is affected

Price feeds, order submission, cancellation, fill reports and user login can use different paths. A host status page alone does not establish that every path is healthy. Record the last valid response time and affected function. An unknown cause should not be presented as a complete exchange outage or a proven manager error.

No response does not mean no execution

An instruction may have been accepted even if its response never arrives. Resending without checking state risks a duplicate instruction. Use identifiers and the host’s official status-query method where genuinely supported. Do not assume every API collapses repeated requests into a single order.

A hypothetical unknown order state

Suppose software times out after submitting an order. The timeout establishes only that confirmation was not received within the expected interval, not that the order was certainly rejected. Reconcile state with a reliable report before subsequent decisions. This educational example requests no live order or retry.

What belongs in the response plan?

• Critical functions and a valid health indication for each.
• The last confirmed order and position states.
• Permitted behaviour with stale data or uncertain responses.
• Decision responsibility and a genuinely available alternative route.
• Event records, communication and criteria for ending the incident.

A risk control depends on where it runs

A manager-software limit may need connectivity to act, while an instruction held by the host remains subject to that host’s execution conditions. A stop-loss label does not guarantee exit during disruption. Establish the control location, price reference and limitations before relying on it.

Reconnection is not the end of review

After service returns, reconcile fills, cancellations, balances and open positions against the last reliable state. New data may reveal events during the interruption. Restarting every instruction automatically without reconciliation can increase discrepancies. Failure-mode tests belong in a controlled non-live environment, not in deliberately disrupted live accounts.

State response limitations explicitly

Logging an alert differs from delivery, acknowledgement and action. Keep each stage’s time and responsibility separate, without promising constant access or certain compensation. Managers can describe outage arrangements without secrets in a cooperation inquiry. When reviewing accounts, read them alongside host rules. This framework claims neither connectivity to all exchanges nor an active product emergency-stop system.