Order Lifecycle

Order Lifecycle

Core Concepts

Order State Machine

The order state machine is the central abstraction in any order management system. It defines every state an order can occupy and every valid transition between states. A correctly implemented state machine prevents impossible transitions (such as filling a canceled order), ensures audit trail completeness, and provides the foundation for order status reporting to clients, counterparties, and regulators.

Canonical order states:

• New: The order has been created internally but not yet transmitted to an execution venue. This is the initial state in the OMS after order entry and validation.
• Pending New: The order has been transmitted to the execution venue but no acknowledgment has been received. The order is in flight. This state exists because network latency and venue processing time create a window between submission and acceptance.
• Accepted (New on venue): The execution venue has acknowledged receipt of the order and placed it on the order book. The FIX ExecType=New / OrdStatus=New acknowledgment has been received.
• Partially Filled: The order has received one or more executions but the full quantity has not yet been filled. The cumulative filled quantity is greater than zero but less than the order quantity.
• Filled: The order has been completely executed. The cumulative filled quantity equals the order quantity. This is a terminal state.
• Pending Cancel: A cancel request has been submitted for the order but the venue has not yet confirmed the cancellation. The original order may still receive fills during this window — this is a critical race condition.
• Canceled: The order has been successfully canceled by the venue. Any unfilled quantity is no longer eligible for execution. This is a terminal state. If partial fills occurred before cancellation, the order is sometimes described as "partially filled and canceled" — the fills stand and the remaining quantity is canceled.
• Pending Replace: A cancel/replace (amend) request has been submitted but not yet confirmed. As with Pending Cancel, fills may still arrive during this window.
• Replaced: The original order has been replaced by a new order with amended parameters (price, quantity, or other fields). The original order transitions to Replaced (terminal), and a new order is created with the amended terms. In FIX, replacement creates a chain linked by ClOrdID and OrigClOrdID.
• Rejected: The execution venue has rejected the order. Common rejection reasons include invalid symbol, invalid order type for the venue, price outside acceptable range, insufficient permissions, or market closed. This is a terminal state.
• Expired: The order's time-in-force instruction caused it to expire without being fully filled. A DAY order expires at market close; a GTD order expires on its specified date. This is a terminal state.
• Suspended: The order has been temporarily suspended by the venue, typically due to a trading halt on the security, a circuit breaker activation, or a regulatory halt. The order remains on the book but is not eligible for matching until the suspension is lifted.
• Done for Day: The order is not eligible for further execution on the current trading day but may resume on the next trading day. This applies to multi-day orders (GTC) that have not yet been fully filled.

Terminal vs. non-terminal states: Terminal states (Filled, Canceled, Replaced, Rejected, Expired) represent the end of an order's lifecycle — no further transitions are possible. Non-terminal states (New, Pending New, Accepted, Partially Filled, Pending Cancel, Pending Replace, Suspended, Done for Day) may transition to other states. The state machine must enforce the invariant that no transition out of a terminal state is ever permitted.

Valid state transitions (representative, not exhaustive):

• New -> Pending New (order submitted to venue)
• Pending New -> Accepted (venue acknowledges)
• Pending New -> Rejected (venue rejects)
• Accepted -> Partially Filled (first partial execution)
• Accepted -> Filled (single complete execution)
• Accepted -> Pending Cancel (cancel request sent)
• Accepted -> Pending Replace (replace request sent)
• Accepted -> Expired (time-in-force expiration)
• Accepted -> Suspended (trading halt)
• Partially Filled -> Partially Filled (additional partial execution)
• Partially Filled -> Filled (final execution completes order)
• Partially Filled -> Pending Cancel (cancel remaining quantity)
• Partially Filled -> Pending Replace (amend remaining quantity or price)
• Pending Cancel -> Canceled (cancel confirmed)
• Pending Cancel -> Filled (fill arrived before cancel was processed — race condition)
• Pending Cancel -> Partially Filled (partial fill during cancel processing)
• Pending Replace -> Replaced (replace confirmed, new order created)
• Pending Replace -> Filled (fill arrived before replace was processed)
• Pending Replace -> Partially Filled (partial fill during replace processing)
• Pending Replace -> Canceled (venue canceled instead of replacing, sometimes due to insufficient quantity after a fill)
• Suspended -> Accepted (halt lifted, order reactivated)
• Suspended -> Expired (order expires during halt)
• Done for Day -> Accepted (next trading day, order reactivated)
• Done for Day -> Expired (GTC expiration reached)

State persistence and recovery: The order state must be persisted durably — typically to a database or write-ahead log — before any acknowledgment is sent to the order originator or any action is taken on the order. If the OMS restarts after a crash, it must be able to reconstruct the current state of every active order from persisted state plus any messages received from execution venues during recovery. This requires idempotent message processing (handling duplicate execution reports without double-counting fills) and state reconciliation with venue order status queries.

Order Types

Order types define the execution instructions that govern how an order interacts with the market.

• Market order: Execute immediately at the best available price. Guarantees execution (in liquid markets) but not price. Appropriate for urgent execution needs. Risk: slippage in volatile or illiquid markets; the execution price may differ substantially from the last quoted price.
• Limit order: Execute at the specified price or better (buy at or below the limit; sell at or above the limit). Guarantees price but not execution. Appropriate when price control is more important than execution certainty. Risk: the order may not fill if the market does not reach the limit price; partial fills may leave a residual position.
• Stop order (stop-loss): Becomes a market order when the stop price is reached (or traded through). Used to limit losses or protect profits on existing positions. Risk: once triggered, the order executes as a market order and may fill at a significantly worse price than the stop price in a gapping or volatile market.
• Stop-limit order: Becomes a limit order (not a market order) when the stop price is reached. The stop price triggers the order; the limit price controls execution. Provides more price protection than a stop order. Risk: the order may trigger but not fill if the market gaps through the limit price.
• Trailing stop: A stop order where the stop price adjusts automatically as the market moves in the order's favor. The stop is set as a fixed amount or percentage below (for sells) or above (for buys) the market price. As the market moves favorably, the stop trails the market; when the market reverses by the trail amount, the stop is triggered. Risk: same as stop orders once triggered; additionally, the trail amount must be calibrated to avoid triggering on normal market noise.
• Market-on-close (MOC): Execute at the closing auction price. Used for benchmark-tracking strategies and end-of-day portfolio adjustments. Exchanges impose cutoff times for MOC orders (NYSE: 3:50 PM Eastern). Risk: no price control; closing auction prices can be volatile.
• Limit-on-close (LOC): Execute at the closing auction price only if the closing price is at or better than the specified limit. Provides price protection for close-targeted execution. Risk: the order may not fill if the closing price exceeds the limit.
• Pegged orders: The order price is pegged to a reference price (typically the NBBO midpoint, best bid, or best offer) and adjusts automatically as the reference price moves. Used in algorithmic and institutional trading to passively follow the market. Behavior is venue-specific.
• Iceberg (reserve) orders: Only a portion of the total order quantity is displayed on the order book; the rest is hidden (the "reserve" quantity). As the displayed quantity is filled, additional shares from the reserve are replenished on the book. Used to minimize market impact for large orders by concealing the full order size. Risk: sophisticated participants may detect iceberg patterns; not all venues support reserve orders.

Time-in-Force Instructions

Time-in-force (TIF) instructions specify how long an order remains active before it is automatically canceled or expires.

• DAY: The order is valid for the current trading day only. If not filled by market close, it is canceled. This is the default TIF for most venues and order management systems. Overnight risk: DAY orders do not carry forward; if the advisor intends to maintain the order, it must be resubmitted the next trading day.
• GTC (Good Til Canceled): The order remains active until explicitly canceled by the originator or until the venue's maximum GTC duration is reached (commonly 60 to 90 calendar days, venue-dependent). GTC orders survive market close and are reactivated each trading day. Risk: stale GTC orders may execute at prices that no longer reflect the current investment thesis; firms must implement GTC order review processes to periodically reassess open GTC orders.
• IOC (Immediate or Cancel): The order must execute immediately, in whole or in part. Any portion not immediately filled is canceled. IOC orders never rest on the order book. Appropriate for liquidity-taking strategies where the trader wants to interact with currently available liquidity without posting a passive order.
• FOK (Fill or Kill): The order must be filled in its entirety immediately or canceled entirely. No partial fills are accepted. More restrictive than IOC. Appropriate when partial execution is unacceptable — for example, a hedging trade that must fully offset a risk position.
• GTD (Good Til Date): The order remains active until a specified date or until canceled. Behaves like GTC but with a defined expiration date. Useful for orders tied to a specific event or deadline.
• OPG (At the Open): The order participates in the opening auction only. If not filled during the opening process, it is canceled. Used when the opening price is the desired execution benchmark.
• CLO (At the Close): The order participates in the closing auction. Functionally similar to MOC but expressed as a time-in-force instruction rather than an order type. Venue implementations vary.

Behavior at market close: DAY orders are canceled. GTC and GTD orders transition to Done for Day and are reactivated the next trading day. IOC and FOK orders, by definition, will have already been filled or canceled before close. MOC and LOC orders execute during the closing auction. The OMS must correctly handle each TIF at the end-of-day transition, including generating appropriate cancel confirmations for expired DAY orders and updating state for multi-day orders.

Overnight handling: GTC orders that are Done for Day must be resubmitted or reactivated at the venue on the next trading day. Some venues maintain GTC orders natively; others require the OMS to resubmit them each morning. The OMS must track which GTC orders need resubmission and handle the resubmission process as part of the start-of-day workflow.

FIX Protocol Fundamentals

The Financial Information eXchange (FIX) protocol is the dominant standard for electronic trading communication. Understanding FIX is essential for building or integrating with any execution venue, broker, or counterparty.

FIX message types for order flow:

• NewOrderSingle (MsgType=D): Submits a new order to the venue. Contains all order parameters: symbol, side, quantity, order type, price, time-in-force, and account.
• ExecutionReport (MsgType=8): The venue's primary response message. Used to acknowledge new orders (ExecType=New), report fills (ExecType=Trade or ExecType=Fill), report partial fills (ExecType=Trade with remaining quantity > 0), confirm cancellations (ExecType=Canceled), confirm replacements (ExecType=Replaced), report rejections (ExecType=Rejected), and report expirations (ExecType=Expired). The ExecutionReport is the most important message in the FIX order flow — it drives all state transitions in the OMS.
• OrderCancelRequest (MsgType=F): Requests cancellation of a previously submitted order. Includes the OrigClOrdID (the ClOrdID of the order to cancel) and a new ClOrdID for the cancel request itself.
• OrderCancelReplaceRequest (MsgType=G): Requests modification of a previously submitted order (price, quantity, or other parameters). Includes the OrigClOrdID and a new ClOrdID. The venue treats this as a cancel of the original order and acceptance of a new order with the amended terms — atomically, if possible.
• OrderCancelReject (MsgType=9): The venue's response when a cancel or replace request cannot be honored. Common reasons: the order has already been filled, the order has already been canceled, or the order is in a state that does not permit cancellation (e.g., suspended during a halt).

Key FIX tags: The tags that drive OMS state are ClOrdID (11) / OrderID (37) / OrigClOrdID (41) for order identification and chaining, OrdStatus (39) and ExecType (150) for state transitions, and CumQty (14) / LeavesQty (151) / AvgPx (6) for fill accounting. Trust the venue's LeavesQty rather than deriving remaining quantity independently — the two can diverge after partial fills and replacements.

FIX session vs. application layer: FIX operates on two layers: the session layer (connection management, heartbeats, sequence numbers, gap recovery) and the application layer (orders, executions, cancels — the subject of this skill). Session-layer management is owned by the exchange-connectivity skill (trading-operations); a lost session requires reconnection and sequence reconciliation there before application-level messaging can resume.

FIX versions: FIX 4.2 remains widely deployed and is the baseline for many venues. FIX 4.4 added improvements including better support for multi-leg orders and allocation messaging. FIX 5.0 introduced the FIXT transport layer (separating session and application protocols) and added support for market data and post-trade messaging. When connecting to a new venue, confirm which FIX version and which message extensions (if any) the venue supports.

Cancel and Replace Workflows

Cancel and replace workflows are among the most operationally sensitive parts of order lifecycle management. They involve concurrent state changes, race conditions, and the possibility of unexpected outcomes.

Cancel request flow:

1. The OMS sends an OrderCancelRequest (MsgType=F) to the venue, referencing the OrigClOrdID of the order to cancel and assigning a new ClOrdID to the cancel request.
2. The order transitions to Pending Cancel in the OMS.
3. The venue responds with either an ExecutionReport (ExecType=Canceled, OrdStatus=Canceled) confirming the cancel, or an OrderCancelReject (MsgType=9) rejecting the cancel request.
4. If canceled, the order transitions to Canceled (terminal). If rejected, the order reverts to its prior state (Accepted or Partially Filled).

Replace (amend) request flow:

1. The OMS sends an OrderCancelReplaceRequest (MsgType=G) to the venue, referencing the OrigClOrdID and providing the amended order parameters (new price, new quantity, or both) with a new ClOrdID.
2. The order transitions to Pending Replace.
3. The venue responds with either an ExecutionReport (ExecType=Replaced, OrdStatus=Replaced) confirming the replacement, or an OrderCancelReject rejecting the request.
4. If replaced, the original order transitions to Replaced (terminal) and a new order is created in the OMS with the amended parameters and the new ClOrdID. If rejected, the original order reverts to its prior state.

Race conditions — cancel vs. fill: The most critical race condition occurs when a cancel request and a fill cross in flight. The OMS sends a cancel request, but before the venue processes it, the order fills (fully or partially). The venue may respond with a fill ExecutionReport followed by an OrderCancelReject (because the order is now filled and cannot be canceled), or with both a fill and a cancel confirmation (if only a partial fill occurred and the remaining quantity was canceled). The OMS must handle all possible message orderings:

• Fill arrives first, then CancelReject: The order is Filled. The cancel request is moot.
• CancelReject arrives first, then Fill: The OMS must not revert from Pending Cancel to the prior state until it processes the fill. Sequence matters.
• Partial Fill and Cancel confirmation: The order was partially filled before the cancel took effect. The partial fill stands; the remaining quantity is canceled.

Order chaining (ClOrdID to OrigClOrdID linking): Each cancel or replace creates a new link in the order chain. The original order has ClOrdID=A. A replace request references OrigClOrdID=A and assigns ClOrdID=B. A subsequent replace references OrigClOrdID=B and assigns ClOrdID=C. The OMS must maintain this chain to correctly correlate all messages belonging to the same logical order. Breaking the chain — for example, referencing the wrong OrigClOrdID — will cause the venue to reject the request or, worse, cancel or replace the wrong order.

Pending state discipline: While an order is in Pending Cancel or Pending Replace, the OMS should not submit additional cancel or replace requests for the same order. Submitting concurrent cancel/replace requests creates ambiguity about which request the venue is processing and can lead to unexpected outcomes. Queue any new cancel or replace intent until the pending request is resolved.