Home / Algo Trading Basics / The Order Lifecycle
ExecutionIntermediate

The Order Lifecycle

The order lifecycle is the sequence of states a single order passes through from creation to a terminal state — created, validated, sent, acknowledged, and then partially or fully filled, cancelled or rejected — governed by confirmations from the exchange and by idempotency to prevent duplication.

Quick answer: The order lifecycle is the sequence of states a single order passes through from creation to a terminal state — created, validated, sent, acknowledged, and then partially or fully filled, cancelled or rejected — governed by confirmations from the exchange and by idempotency to prevent duplication.

In simple words

The order lifecycle is the set of stages one order goes through after your system decides to trade. It is created, checked, sent to the broker, acknowledged, and then either filled, partly filled, cancelled or rejected. Tracking these states accurately, and confirming each transition rather than assuming it, is what keeps an automated system from losing track of what it actually has in the market.

Purpose

It exists to give an automated system a precise, confirmed model of what has happened to every order, so it never acts on a false belief about its positions and never accidentally duplicates an order.

Visual explanation

The Order Lifecycle

The states an order moves through from creation to a terminal filled, cancelled or rejected outcome.

Order LifecycleCreatedValidatedSentAcknowledgedPartiallyFilledFilledRejectedCancelledrejectcancel

Professional explanation

The states of an order

An order is best modelled as a small state machine. It is created when the system decides to trade; validated when it passes local checks (valid symbol, quantity, price, sufficient margin, risk limits); sent when transmitted to the broker; acknowledged when the broker or exchange confirms receipt and assigns an order ID. From there it moves toward a terminal state: fully filled, partially filled and then filled or cancelled, cancelled before any fill, or rejected. Rejection can occur at validation (locally) or after sending (by the broker or exchange). Modelling these states explicitly, rather than treating an order as simply sent-and-done, is the foundation of reliable execution.

Acknowledgements and confirmations

The critical discipline is that each transition must be confirmed by the counterparty, not assumed by the sender. Sending an order does not mean it was received; receiving an acknowledgement does mean it was. A fill is only real when the broker confirms it. Systems that assume success — send an order and immediately treat the position as open — will eventually act on a false belief when an order is silently rejected, delayed, or only partially filled. The order lifecycle is, in essence, a protocol of send-then-confirm, where the system updates its internal state only on confirmed events from the broker.

Partial fills

A single order need not fill all at once. In a market with limited liquidity at a given price, an order for a larger quantity may fill in pieces over time, or only partially before being cancelled or expiring. The system must handle a sequence of partial-fill events, accumulating the filled quantity and average price, and know at every moment how much remains open. Mishandling partial fills is a classic source of error: the system may believe it has a full position when only part filled, or double-count, or send a correcting order based on wrong quantities. Correct accounting of partials is essential to knowing the true position.

Idempotency and avoiding duplicates

Networks are unreliable: a request can time out with the order actually placed, or an acknowledgement can be lost. If the system naively retries, it can send the same order twice and acquire an unintended position. Idempotency is the property that submitting the same logical order more than once has the effect of submitting it once. It is typically achieved with a client-generated unique order identifier that the broker uses to deduplicate, so a retry after an uncertain outcome is safe. Without idempotency, the safe response to uncertainty is to query state before retrying; with it, retries become robust. This is one of the most important correctness properties in automated execution.

Reconciliation and terminal states

Because messages can be lost and states can diverge, a robust system periodically reconciles its own record of each order against the broker's authoritative record, especially after any disruption or reconnection. Every order should eventually reach a terminal state — filled, cancelled or rejected — and the system should not leave orders in an unknown limbo. Reconciliation resolves discrepancies: an order the system thought was open may have filled or been cancelled at the exchange. Treating the broker as the source of truth and reconciling against it is what keeps the system's model of its positions honest over a long trading session.

Order states at a glance

StateMeaningTerminal?
CreatedSystem decided to place the orderNo
ValidatedPassed local checks and risk limitsNo
SentTransmitted to the brokerNo
AcknowledgedBroker/exchange confirmed receiptNo
Partially filledSome quantity filled, remainder openNo
FilledFully executedYes
CancelledWithdrawn before full fillYes
RejectedRefused locally or by broker/exchangeYes

Practical example

Illustrative example (Indian market)

A system decides to buy 3 lots of a Bank Nifty option. It creates the order, validates it against margin and a risk limit, and sends it to the broker, which acknowledges with an order ID. Liquidity at the limit price fills 1 lot immediately (partial fill), then another lot a moment later, leaving 1 lot open. The system now knows it holds 2 lots with 1 remaining, not 3. Suppose the network then times out on a modify request; because each order carries a unique client ID, the system can safely query or retry without risking a duplicate order. If the final lot does not fill before the system cancels it, the order reaches the terminal cancelled state with 2 of 3 lots filled. At session end, the system reconciles its record against the broker and confirms it holds exactly 2 lots — the confirmed truth, not an assumed one.

On NSE, orders can be rejected by the exchange for reasons such as breaching price bands or circuit limits even after the broker accepts them, so an Indian automated system must treat broker acknowledgement and exchange confirmation as distinct events and wait for the actual fill or reject before updating its position state.

Advantages

  • Gives the system a precise, confirmed model of every order's status
  • Prevents acting on false assumptions about open positions
  • Handles partial fills so the true position is always known
  • Idempotency makes retries after network uncertainty safe

Limitations

  • Correct state handling adds real engineering complexity
  • Messages can still be lost, requiring reconciliation to recover truth
  • Latency between states can leave brief windows of uncertainty
  • Broker and exchange behaviours vary, complicating a uniform model

Common mistakes

  • Assuming an order succeeded on send instead of waiting for acknowledgement and fill
  • Ignoring partial fills and treating an order as fully filled or not at all
  • Retrying without idempotency, sending duplicate orders after a timeout
  • Never reconciling the system's records against the broker's authoritative state
  • Leaving orders in an unknown state with no path to a terminal outcome
  • Conflating broker acknowledgement with an actual fill, updating position too early

Professional usage

Serious execution systems model orders as explicit state machines, update internal state only on confirmed events from the broker, and attach a unique client identifier to every order so retries are idempotent. They handle partial fills as first-class events, treat the broker as the source of truth, and reconcile continuously — especially after any reconnection — so the system's belief about its positions never silently drifts from reality. The governing principle is confirm, never assume, because in execution an incorrect belief about state is a direct path to unintended risk.

Key takeaways

  • An order is a state machine: created, validated, sent, acknowledged, then filled, cancelled or rejected
  • Confirm every transition from the broker rather than assuming success on send
  • Handle partial fills so the true open and filled quantities are always known
  • Idempotency via a unique order ID makes retries after network uncertainty safe

Frequently asked questions

What is the order lifecycle?
It is the sequence of states a single order passes through from creation to a terminal outcome: created, validated, sent, acknowledged, then partially or fully filled, cancelled or rejected. Modelling these states and confirming each transition is the basis of reliable automated execution.
What are the main states of an order?
Created, validated, sent, acknowledged, partially filled, filled, cancelled and rejected. The first four are transient stages toward a terminal state; filled, cancelled and rejected are terminal. Rejection can happen locally at validation or after sending, by the broker or exchange.
Why must I confirm an order rather than assume it succeeded?
Because sending an order does not guarantee it was received or filled. It can be delayed, rejected or only partially filled. A system that assumes success will eventually act on a false belief about its position, so robust execution updates state only on confirmed events from the broker.
What is a partial fill?
A partial fill is when only part of an order's quantity executes, leaving the rest open. It happens when there is not enough liquidity at the price to fill the whole order at once. The system must accumulate filled quantity and average price and track how much remains open.
What is idempotency in order placement?
Idempotency means submitting the same logical order more than once has the same effect as submitting it once. It is usually achieved with a unique client-generated order ID that the broker uses to deduplicate, so a retry after a timeout cannot create a duplicate order and an unintended position.
Why is idempotency important in automated trading?
Because networks are unreliable — a request can time out even though the order was placed. Without idempotency, retrying can double-send the order. With a unique order ID for deduplication, retries after uncertain outcomes become safe, which is essential for correct, resilient execution.
What is order reconciliation?
Reconciliation is periodically comparing the system's own record of each order against the broker's authoritative record, especially after a disruption or reconnection, and resolving any discrepancy. It keeps the system's model of its positions honest, treating the broker as the source of truth.
What is the difference between acknowledged and filled?
Acknowledged means the broker or exchange confirmed receipt of the order and assigned it an ID; filled means the order actually executed against the market. An acknowledgement is not a fill, and updating a position on acknowledgement rather than fill is a common and dangerous error.
Can an order be rejected after the broker accepts it?
Yes. An order can pass local validation and broker acceptance and still be rejected by the exchange, for example for breaching price bands or circuit limits. This is why a system should treat broker acknowledgement and the final exchange outcome as distinct and wait for the actual result.
What is a terminal order state?
A terminal state is a final outcome an order cannot leave: filled, cancelled or rejected. A robust system ensures every order eventually reaches a terminal state rather than lingering in an unknown limbo, which is resolved through confirmations and reconciliation.
How should a system handle a timeout when placing an order?
It should not blindly retry, because the order may have been placed. With idempotency via a unique order ID, a retry is safe; otherwise, the system should query the broker for the order's state before deciding, so it does not create a duplicate position.
Why model an order as a state machine?
Because an order genuinely has distinct states and transitions, and modelling them explicitly lets the system track exactly where each order is, handle partial fills and rejections correctly, and know its true position at all times. Treating an order as simply sent-and-done hides the states where errors occur.

Voice search & related questions

Natural-language questions people ask about The Order Lifecycle.

What is the order lifecycle?
It is the stages one order goes through: created, checked, sent, acknowledged, then filled, partly filled, cancelled or rejected.
What is a partial fill?
It is when only some of your order quantity trades and the rest stays open, usually because there is not enough liquidity at your price.
What does idempotency mean for orders?
It means sending the same order twice still counts as one, thanks to a unique order ID. It stops retries from creating duplicate positions.
Is an acknowledged order the same as a filled order?
No. Acknowledged just means the broker received it. Filled means it actually traded. Never update your position until it is really filled.
Why reconcile orders with the broker?
Because messages get lost and your record can drift from reality. The broker is the source of truth, so you check against it to stay accurate.
Can an order be rejected after the broker accepts it?
Yes. The exchange can still reject it, for example for breaching a price band, so you wait for the real outcome before updating your position.
What is a terminal order state?
It is a final outcome an order cannot leave: filled, cancelled or rejected. Every order should end up in one of these, not stuck in limbo.
What should I do if placing an order times out?
Do not blindly resend. With a unique order ID a retry is safe; otherwise, ask the broker for the order's status first to avoid a duplicate.

Sources & references

    Last reviewed 11 July 2026. Educational content only — not investment advice. Markets and rules change; verify current conventions with SEBI, NSE/BSE and your broker.

    ← Previous
    The Trading Lifecycle
    Educational content only — not investment advice. Examples use illustrative numbers and simplified models. Algorithmic trading and derivatives involve substantial risk. See our Risk Disclosure and SEBI Disclaimer.