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
An order is a state machine — created, validated, sent, acknowledged, then filled, partly filled, cancelled or rejected. The system must confirm each step from the broker rather than assume it, and give each order a unique ID so a retry after a timeout cannot double-send. On NSE, the exchange can reject an order the broker already accepted.
Definition: The Order Lifecycle
The Order Lifecycle is the sequence of states a trade instruction passes through, from creation and validation to a confirmed fill, cancellation or rejection, tracked to prevent duplicate execution.
Key takeaways: The Order Lifecycle
- 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
The Order Lifecycle at a glance
| Class | Execution state model |
|---|---|
| Transient states | Created, validated, sent, acknowledged |
| Terminal states | Filled, cancelled, rejected |
| Core rule | Confirm each transition, never assume |
| Partial fill | Track filled quantity and remainder |
| Idempotency | Unique order ID makes retries safe |
| India note | NSE can reject after broker acceptance |
The Order Lifecycle 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.
What The Order Lifecycle is for
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.
The Order Lifecycle — 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.
How The Order Lifecycle looks visually
Worked example: The Order Lifecycle
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.
Order states at a glance
| State | Meaning | Terminal? |
|---|---|---|
| Created | System decided to place the order | No |
| Validated | Passed local checks and risk limits | No |
| Sent | Transmitted to the broker | No |
| Acknowledged | Broker/exchange confirmed receipt | No |
| Partially filled | Some quantity filled, remainder open | No |
| Filled | Fully executed | Yes |
| Cancelled | Withdrawn before full fill | Yes |
| Rejected | Refused locally or by broker/exchange | Yes |
Advantages of The Order Lifecycle
- 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 of The Order Lifecycle
- 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
How professionals treat The Order Lifecycle
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.
Common misconceptions about The Order Lifecycle
Misconception: An acknowledged order is the same as a filled order.
Reality: Acknowledged just means the broker received it. Filled means it actually traded. Never update your position until it is really filled.
Common mistakes with The Order Lifecycle
- 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
The Order Lifecycle: frequently asked questions
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.
Can a network timeout cause the same order to be sent twice?
Yes — if an order request times out you may not know whether it reached the broker, and a blind retry can create a duplicate position. The order lifecycle guards against this by carrying a unique client order ID, so the broker recognises a retry of the same logical order as one order rather than two.
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.
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.
Voice search: how people ask about The Order Lifecycle
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 happens if only part of my order fills?
Then only some of your quantity trades and the remainder stays open as a live order, usually because there was not enough liquidity at your price to complete it at once. The lifecycle keeps tracking the open balance until it fills, is amended, or is cancelled.
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.
Sources & references
- NSE India — contract specifications, trading mechanics and market-data documentation
- Irene Aldridge, “High-Frequency Trading: A Practical Guide to Algorithmic Strategies and Trading Systems”, 2nd ed., Wiley, 2013
Published 10 July 2026. Educational content only — not investment advice. Markets and rules change; verify current conventions with SEBI, NSE/BSE and your broker.