What reconciliation compares
Trading-system reconciliation compares the application’s saved intent and state with broker orders, executions and positions. It answers whether the local model matches the account before the system resumes normal decisions.
The records answer different questions. An order says what was requested and whether it remains active. An execution says what quantity traded. A position says what the account currently holds. Local intent explains why the application initiated the request. A robust recovery process needs these perspectives together.
In ADT, session state and order intent are persisted locally. The engine requests broker records on startup and reconnect before resuming its workflow. See the application architecture for the service and persistence boundaries.
A timeout leaves an uncertain outcome
Imagine that the application sends a buy order, then loses its connection before it receives a response. At least three outcomes are possible: the broker never received it, the broker accepted it but it remains unfilled, or the order executed and the response was lost.
Resubmitting immediately is not a safe way to distinguish those cases. It can produce a duplicate entry. Assuming the order executed is also wrong: the software may attempt to manage shares that do not exist. Recovery begins by querying and matching the relevant broker records.
This is why durable order intent matters. The application needs enough information to identify the original request across process restarts. A new process should not treat an empty in-memory cache as proof that nothing happened.
Identity, fills and quantity
ADT matches broker order evidence using the client and order identifiers, then persistent broker identity and its own order reference. Execution identifiers are used to avoid recording the same execution twice. The internal order reference connects the event to its session and role.
Requested quantity and filled quantity must remain separate. A partially filled entry can create exposure while the remaining order is still working. A cancellation acknowledgment for the remainder does not reverse the executed shares. Likewise, an exit order that partially fills reduces exposure without establishing that the account is flat.
Reconciliation should account for execution corrections and repeated notifications rather than relying on the number of callback messages. IBKR’s order submission documentation describes its order and execution callbacks; ADT adds persistence and session-specific matching around that interface.
Connection recovery has multiple layers
A desktop-to-gateway socket and a gateway-to-broker connection are different links. The local process can remain connected to Gateway while Gateway has lost its upstream connection. The error message identifies which layer needs attention.
IBKR documents code 1100 for lost connectivity between TWS and IBKR, 1101 for restored connectivity with data lost, and 1102 for restored connectivity with data maintained. Their handling is not interchangeable; subscriptions may need to be restored when data was lost. Consult IBKR’s system message codes.
ADT reconnects with backoff and reconciles broker records. An operator should inspect the actual position and accepted orders in the broker application during an interruption. Restoring a network link alone does not prove that the local state has caught up.
Existing protection and manual trades
An accepted broker-side protective order may remain working while the application is offline, subject to its time in force and broker rules. An application-monitored trigger cannot continue processing without the service and its inputs. Read the actual protection authority and broker order status rather than assuming both modes behave the same way.
Manual broker actions can also change the account while ADT is running. The system must reconcile the resulting quantity and order evidence. Avoid running overlapping automation or unrelated manual trades in the same instrument without understanding ownership and matching behavior. An unexplained position is an operational discrepancy, not something to silently adopt as a successful strategy entry.
Recovery procedure for an operator
- Establish account identity and account mode directly in IBKR.
- Inspect current positions and working orders. Record the relevant time and error message.
- Restore the gateway login, socket or network connection as indicated.
- Allow the service to request and reconcile broker records.
- Review any remaining alert. In ADT, use Resolve after correcting the underlying issue to request reconciliation again.
- If intervention is needed, follow the documented exit procedure and verify the broker outcome.
Do not delete the local database or reset the application while exposure or working orders may remain. That removes evidence the recovery process uses. Closing the desktop window also does not stop ADT’s separate background service.
What completion does and does not mean
A reconciled state establishes consistency with the broker evidence available at that point. It is not a promise that future events will arrive without delay or that a requested exit will fill. Monitoring continues after reconciliation.
ADT can block normal progression when the state is unresolved. Where its exit process remains active, retries are still subject to market hours, broker acceptance and actual liquidity. The operator should understand the alert and the remaining exposure instead of treating a reconnect as a completed recovery.
Independent positions, shared account evidence
ADT persists a separate lifecycle identity, order references, fills, high-water mark and exit state for each managed position. Reconnect restores all outstanding lifecycles rather than treating the account as a new empty session. Aggregate broker snapshots are matched to the correct account and contract. Duplicate events must not duplicate entries or exits, and unexpected short exposure is not accepted as broker-confirmed flat.
An automatic protective or session exit owns the same reconciliation path as an operator flatten override. A rejection or partial exit leaves that lifecycle unresolved while the other positions retain their own state.