Reconciling bot orders with exchange records

A bot log records what the application attempted. The exchange account records what the venue accepted, rejected, cancelled and filled. Those records can disagree after a timeout, retry, partial fill or delayed event. Reconciliation compares independent evidence so an operator can find the disagreement before another decision relies on an incorrect position or balance.

Define a stable order identity

Give every intent an internal identifier and send a supported client-order identifier to the exchange. Store the request, exchange order identifier, symbol, side, quantity and timestamps. A timeout is an unknown outcome, not a failed order: query the venue using the stable identifier before retrying. Blind retries can create duplicate exposure when the first request succeeded.

Compare state, not only events

Periodically compare open orders, fills, fees, balances and positions with the exchange API. Account for partial fills and exchange-specific status transitions. Preserve raw responses and normalized values with an immutable audit trail, while excluding credentials and unnecessary personal data from logs. A local “filled” event alone is not confirmation of a venue fill.

Make disagreements safe

Classify mismatches by urgency. An unknown open order or unexplained position should pause new entries for that account and alert an operator. A delayed fee can be reviewed without stopping every bot. Automated repair should be limited to deterministic cases; ambiguous state needs an exchange-side check and a documented human decision.

Operational takeaways

• Use idempotent client-order identifiers and look up unknown outcomes before retrying.
• Reconcile venue orders, fills, fees and balances on a defined schedule.
• Pause new exposure when an unexplained order or position is detected.
• Keep credential values out of logs and retain only evidence needed for investigation.
• Test timeout, duplicate-event and partial-fill paths in paper or sandbox environments.

Reconciliation improves detection and recovery; it does not guarantee correct execution, a particular fill, continuous exchange access or profit. It is an operational control, not financial advice, regulatory authorisation or a transfer of responsibility for the account.