OMS State Consistency Checker

The canonical state machine for equity order lifecycle defines the states an order can be in and which transitions are legal. Valid states: New (order created in OMS, not yet sent), PendingNew (sent to broker, acknowledgement awaited), Open (acknowledged, resting at exchange), PartiallyFilled (one or more fills received, remainder open), Filled (all shares executed), Cancelled (order cancelled with open quantity remaining), Rejected (broker or exchange rejected the order). Legal transitions are one-directional: you cannot go from Filled back to Open, or from Cancelled to PartiallyFilled. See the full state model guide for the transition table and FIX OrdStatus tag mappings.

Overfills occur when the OMS fails to enforce a fill quantity ceiling equal to the order's original total quantity. Common causes: a race condition where two fill events arrive simultaneously and both pass the quantity check before either updates the cumulative fill counter; incorrect handling of amended orders where the quantity was reduced but fills were still processed against the original quantity; or a missing quantity check in the fill processing path. Overfills must be caught in real time, any fill that would cause cumulative fill quantity to exceed the order quantity should be rejected by the OMS and flagged immediately.

A bust (FIX ExecType='H', Trade Cancel) reverses a fill. In the OMS, it should apply a correcting entry with negative fill quantity equal to the original fill quantity being busted. This reduces the cumulative fill total. If the order was fully Filled before the bust, the bust returns it to PartiallyFilled or Open state depending on how much is now unfilled. The OMS must also update the open quantity (order quantity minus remaining cumulative fill quantity) and recompute the average price to reflect the removal of the busted fill's contribution. See the Corrections, Busts, and Trade Amendments guide.

A fill event is received for an order that is already in a terminal state, Filled, Cancelled, or Rejected. The OMS must not apply this fill because the order has no remaining open quantity to fill. If the OMS incorrectly processes the fill, the position count increases beyond what was intended (or decreases for a sell), the average price is corrupted, and the result may be an unintended long or short position. In practice this can happen when a CANCEL_ACK and a FILL cross in flight from the exchange, the OMS receives both and must determine which arrived first. The canonical resolution is to honor the fill if it predates the cancel at the exchange, or reject it if the exchange acknowledged the cancel before sending the fill.

Yes. Try adding a FILL event in row 7 after row 6 completes the order (Fill state), the tool will flag "fill on terminal order." Or increase the fill quantity in row 6 to 4,000 instead of 3,000, total fills will be 11,000 against a 10,000-share order, triggering an overfill error. Or select "Cancelled" as the Reported State in row 4, the tool will flag a state mismatch because after a PARTIAL_FILL the expected state is PartiallyFilled, not Cancelled.

An ordered list of order lifecycle events, each naming the event type and carrying the quantities associated with it, in the order the system processed them. The order matters: the tool evaluates each event against the state produced by the ones before it, so a sequence sorted by venue timestamp rather than by processing order will produce different findings. Feeding both orderings through separately is a way to see whether a suspected bug is a logic error or an ordering problem.

It means the specific sequence entered contains none of the inconsistencies the tool looks for. The checks cover transition legality, quantity arithmetic, overfills, and activity on terminal orders. They cannot evaluate whether the state model itself matches the venue, whether the sequence is representative of what production sees, or whether events are being dropped before they reach the handler. The strongest use is running known-bad sequences to confirm the checks fire, then real captured sequences.

From the order log, provided it records every state-changing event rather than only the final outcome. The fields needed are the event type and the quantities, which most structured order logs already carry. Where a log records only order snapshots at intervals, the sequence has to be reconstructed and the reconstruction may itself hide the transition that caused the problem. That gap is often the first useful finding from attempting the exercise.

By separating whether the event stream was wrong or the handler was. An overfill can mean the venue genuinely sent more executed quantity than was ordered, which is a counterparty question, or that duplicate fill events were applied twice, which is a handler question. Comparing the flagged sequence against the raw messages received, before changing any code, identifies which of the two applies and prevents a fix that suppresses the symptom while leaving the cause.