Futures Prop Firm OffersFutures Platform Disconnect Incident Checklist
A practical futures prop trading checklist for platform disconnects: verify positions, avoid duplicate orders, document the incident, and reconcile fills.
Futures Platform Disconnect Incident Checklist
Direct answer: When a futures platform disconnects, first determine whether the account has an open position or working order through an independent approved channel. Do not repeatedly click order buttons or assume a rejected-looking order never reached the market. Stabilize connectivity, flatten or manage exposure through an authorized route, record evidence, and reconcile broker-side fills before resuming.
First 60 seconds
| Priority | Action | Reason |
|---|---|---|
| 1 | Stop sending repeated orders | Prevent duplicate or conflicting instructions |
| 2 | Note the exact time and account | Creates a reliable incident record |
| 3 | Check connection and platform status | Separates local failure from wider outage |
| 4 | Verify positions through an independent approved view | The local screen may be stale |
| 5 | Use the firm’s authorized emergency process if exposure exists | Limits unmanaged market risk |
| 6 | Preserve screenshots and error messages | Supports later reconciliation |
The order of actions may change if the firm provides a mandatory liquidation or support procedure. Follow the account agreement and use only approved platforms, phone desks, or backup connections.
The three states to distinguish
Confirmed flat
The broker-side or clearing-side position view shows no open position and no working order. Save proof before reopening the platform.
Confirmed exposure
An open position or working order is visible through a trusted independent channel. Manage it using the firm’s approved route and record every instruction.
Unknown state
The local platform is unavailable and no independent confirmation is available. Treat the account as potentially exposed. Escalate through the official support or emergency channel rather than placing speculative offsetting orders.
| State | What is known | Immediate goal | Avoid |
|---|---|---|---|
| Confirmed flat | No position or working order | Preserve confirmation and diagnose | New trades during instability |
| Confirmed exposure | Quantity and orders are visible | Control or close risk | Blind duplicate orders |
| Unknown | Position state cannot be trusted | Obtain authoritative confirmation | Assuming flat or guessing quantity |
Why duplicate orders are dangerous
A timeout can occur after an order reaches the market but before the acknowledgement returns to the screen. Sending the same order again can create twice the intended quantity or reverse a position after the first order fills.
Hypothetical example:
| Event time | Local display | Possible market state | Safe interpretation |
|---|---|---|---|
| 09:31:02 | Buy order sent | Order may be received | Pending verification |
| 09:31:04 | “Request timed out” | Order could still fill | Not proof of rejection |
| 09:31:10 | Platform disconnects | Position unknown | Do not resend blindly |
| 09:31:35 | Backup view shows long 1 | First order filled | Manage actual position |
An offsetting sell order is not automatically a harmless cancellation. If the original buy never filled, the sell may open a short position.
Pre-session disconnect preparation
| Preparation item | What to record |
|---|---|
| Firm support route | Official email, ticket page, or emergency process |
| Backup approved access | Web, mobile, or secondary connection allowed by the firm |
| Account identifiers | Firm account name and platform account number |
| Risk limits | Current daily and overall thresholds |
| Open-order habits | Whether stops are server-side or platform-dependent |
| Evidence folder | Location for screenshots, exports, and timestamps |
| Copier plan | How to verify every follower account independently |
Do not install or use an unapproved trading route during the incident. Compatibility and account authorization matter more than speed.
Open-position response sequence
- Record the time, symbol, expected quantity, last known stop, and account.
- Check a trusted backup position view.
- Confirm working orders separately from the net position.
- If the firm permits it, cancel unwanted working orders.
- Flatten or manage the verified quantity using an authorized connection.
- Confirm the resulting position and order count independently.
- Stop trading until the incident is understood and records match.
Multi-account copier check
A copier can leave leader and follower accounts in different states.
| Account | Expected position | Verified position | Working orders | Action |
|---|---|---|---|---|
| Leader | 0 | 0 | 0 | No action |
| Follower A | 0 | Long 1 | Stop present | Close through approved route |
| Follower B | 0 | 0 | Sell stop 1 | Cancel orphaned order |
| Follower C | 0 | Unknown | Unknown | Escalate and verify |
Never infer follower positions solely from the leader. Inspect each account because rejects, latency, and allocation errors can affect them differently.
Evidence and incident log
| Field | Example entry |
|---|---|
| Local timestamp and time zone | 09:31:04 CT |
| Platform and version | Record exact client |
| Account ID | Last four digits or internal label |
| Contract | Symbol and expiry month |
| Last verified position | Long 1 |
| Working orders | Stop 1, target 1 |
| Error message | Exact text or screenshot |
| Connection type | Primary internet / backup |
| Action taken | Closed through approved web access |
| Confirmation time | 09:32:11 CT |
| Support case | Ticket number |
Keep sensitive login details out of screenshots and support messages. The log needs account identification, not passwords or authentication codes.
Reconcile before resuming
Compare platform history, broker-side fills, and account P&L.
| Reconciliation check | Pass condition |
|---|---|
| Net position | Zero or intentionally managed |
| Working orders | No orphaned stops or targets |
| Fill quantity | Matches broker-side record |
| Fill prices | Recorded accurately |
| Realized P&L | Matches fill arithmetic after costs |
| Copier accounts | Checked one by one |
| Rule dashboard | Current thresholds and status understood |
| Support response | Saved with incident record |
If two records disagree, keep the account inactive and ask the firm or platform provider to reconcile them.
Post-incident decision
A resolved connection does not automatically make the session safe to continue. Consider market volatility, emotional state, time spent without reliable data, remaining rule room, and whether the root cause is known.
Resume-or-stop table
| Condition | Response |
|---|---|
| Position and orders fully reconciled, cause understood | Resume only if the trading plan allows |
| Position flat but cause unknown | Prefer ending the session |
| Records disagree | Do not trade |
| Copier accounts differ | Reconcile every account first |
| Rule room is close to a limit | End the session |
| Backup connection is unstable | End the session |
What to send support
Provide a concise timeline, affected account IDs, contract month, order IDs if available, screenshots, and the specific discrepancy. State the outcome you need, such as confirmation of a fill or correction of an orphaned order record. Avoid claiming that an error caused a loss before the execution record has been reviewed.
Every firm and platform can have a different incident procedure. The account agreement and official support instructions take priority over this general checklist.