The unglamorous part
The books and thevenue will disagree.The question is whathappens next
Streams drop, responses get lost, venues restate. Software that assumes otherwise reports a confident number that is wrong. Every disagreement here is found, named, and either resolved by a rule or left open for a human.
The four disagreements that actually happen
The order we do not know about
A submission whose response was lost may be live at the venue. On startup and on a schedule, open orders are re-read and matched to the ledger by client order id — and where a venue mangles that id, by the instrument instead. An order the venue has and we do not is adopted rather than duplicated.
The fill that arrives twice
The private stream and a reconciliation pass legitimately report the same execution. Booking it twice doubles a position and invents P&L, so a fill is booked by its own identity and a repeat is a no-op — but the caller is told which it was, because "I booked this" and "someone already did" are different facts.
The fill that overfills the order
More filled than ordered is a contradiction the ledger must not silently accept, and rolling the whole thing back is worse — it would discard an order the venue accepted and filled. The row and the event survive, the order is left un-aggregated, and an issue is raised.
The history that changes underneath you
Some venues restate the past — a split, a correction. A cache that never revisits a bar it already has will hold the old numbers forever and never notice. Data that can be restated is re-read rather than assumed immutable.
What is never done to make the books look tidy
- Silently overwriting a position to match the venue. The difference is the finding.
- Dropping a fill that does not fit. A row that cannot be aggregated is kept and flagged.
- Reporting a degraded run as a clean one with fewer results.
- Treating "the data source failed" and "there is nothing there" as the same answer.
- Resolving an issue automatically when the resolution would move money.
Questions about reconciliation
How often does it run?
At startup, on a schedule, and on demand. The scheduled pass exists because a stream can be connected and still have missed something — a gap detected on reconnect triggers its own pass rather than waiting for the timer.
What do I do with an open issue?
Read it and resolve it. Each one names the account, the order and what disagreed. They are deliberately not auto-resolved: an unexplained discrepancy that closes itself is an unexplained discrepancy you will meet again with less information.
Does this matter on paper?
The machinery is the same and it runs, which is the point of rehearsing with it. What it will not show you is a venue misbehaving, because the simulated one does not.
Look at a ledger that admits things
Every fill, its fee, the decision that authorised it, and what it opened or closed.