Duplicate Execution Reports: Prevent Double Booking

Define identity at the application boundary

FIX sequence numbers identify session messages; they are not a universal trade-booking key. A business event can reappear through replay or another reporting channel. Define the scope of execution identifiers, including counterparty, account, business date or other documented dimensions, and retain the original report.

The FIX trade specification describes execution reports, correction references and fill groups. Do not assume every report is a new fill or that every dialect supplies identical fields. Some status messages carry summary information rather than a new execution. Multi-fill or fragmented reports require the documented grouping and completion rules.

Use quantities as an independent check

For a straightforward active order, compare the accepted order quantity with cumulative executed and remaining quantities. Also compare the latest increment with the specific reported fill, while respecting the event type. A mismatch is a review signal, not permission to manufacture a missing trade.

Terminal states and corrections can break a simplistic quantity formula or reduce a previously reported result. Keep a correction chain referencing the affected event and preserve both old and new values. The order-state specification includes these transitions. Recalculating positions from a controlled event history should reproduce the approved current state.

Commit once and retain the outcome

Persist the decision that an event was accepted together with the resulting business update under an appropriate transactional design. If the process records only a log message and crashes before posting, a retry may be needed; if it posts before recording identity, a retry can double book. Document this failure boundary explicitly.

The duplicate flag helps session recovery, but it is not a command to discard a message without inspection. A retransmitted event may be the first copy your application successfully processes. Conversely, a repeated economic event can require detection even outside session retransmission. Keep duplicate receipts for diagnostics while preventing repeated financial effects.

Worked example: 35 units, not 55

A fictional order receives fill E1 for 20 units, with cumulative quantity 20. E1 arrives again after recovery and causes no second booking. A new fill E2 adds 15, bringing cumulative quantity to 35. A later status report repeats cumulative quantity 35 and remaining quantity 65; it adds no fill. The ledger therefore contains 35 executed units. If a correction later changes E2, process that referenced correction under the agreed semantics rather than treating it as another 15-unit trade.