> For the complete documentation index, see [llms.txt](https://initiativ.gitbook.io/initiativ/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://initiativ.gitbook.io/initiativ/mm_internal/6.-order-lifecycle-and-execution/6.1-order-status-and-lifecycle.md).

# 6.1 Order Status and Lifecycle

Every order carries a status that records where it is in its life, from the moment the Exchange receives it to the point it is complete, withdrawn or ended. The Exchange uses one shared set of statuses across all entry channels, so that an order means the same thing whether it arrived through the order book, RFQ or Block Clear, with a small number of channel-specific statuses added only where a channel genuinely needs them. This section is the canonical definition of those statuses and the transitions between them; other documents (the tabular data views, the RFQ and Order Validation specifications) refer here rather than defining their own.

## Shared statuses

These apply to orders on every channel.

| Status             | Meaning                                                                                                                                                                 | Who can act                        | Editable |
| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------- | -------- |
| Received           | The Exchange has acknowledged the order; validation has not yet completed, so it is neither live nor rejected. Transient.                                               | System                             | No       |
| Validating         | The order is passing through the validation checks (Chapter 7); resolves to Active or Rejected. Transient.                                                              | System                             | No       |
| Active             | The order has passed validation and is live on the book, available for matching.                                                                                        | Member                             | Yes      |
| Partially executed | Part of the order has filled; the remainder is live.                                                                                                                    | Member                             | Yes      |
| Executed           | The order is fully filled. Final.                                                                                                                                       | None                               | No       |
| Cancelled          | The order was withdrawn before completion, by the Member or an Administrator. Final.                                                                                    | None                               | No       |
| Rejected           | The order failed a validation check and never became live, whether at entry or at a later resource check. The Member may correct and resubmit. Final.                   | Member (resubmit)                  | No       |
| Expired            | The order reached the end of its time in force without completing. Final.                                                                                               | None                               | No       |
| Failed             | The order was accepted but fell over after acceptance and before execution, for a non-market reason such as a technical failure. The Member may resubmit. Final.        | Member (resubmit)                  | No       |
| Blocked            | The order is subject to intervention (by the Member’s clearing member, the Exchange, or arising from a central counterparty default) and cannot proceed until released. | Exchange, clearing member or Admin | No       |

Received and Validating are the transient in-flight states. They pass in well under a second for a normal order-book order and a person watching a screen sees them as a single moment, but they are distinct events: Received answers “the Exchange has your order,” Validating answers “the checks are running,” and a system integrating over the API relies on the two being separate, particularly on an amendment, which re-runs validation in full.

Blocked covers intervention rather than a Member’s own action or an ordinary validation outcome: a clearing member withdrawing or restricting cover, the Exchange suspending a Member, or the central counterparty declaring a clearing member in default. The leading design follows the clearing-member kill switch: on a block, the Member’s working orders are cancelled and new order entry is prevented, with a manual, logged re-enablement step, which is the safest treatment because a Member pulled for non-payment is a live credit risk and leaving resting orders exposes the clearing member to fills it must guarantee. A lighter tier, reducing a Member’s pre-trade limits, blocks only new risk-increasing orders while leaving resting orders live. Blocked is fully operational at launch. Its exact behaviour, the division of trigger authority between the Exchange, the clearing member and the central counterparty, and the supporting data flows depend on the chosen CCP and clearing member; they are set out in Chapter 7 (Risk Controls), described there at the level of intent until the CCP and clearing model are fixed.

## Channel-specific statuses

These sit alongside the shared set for the channel named.

Pending has one meaning wherever it appears: an order or request awaiting a required response or action from another party before it can proceed. It occurs in two channels, with the party and the action differing:

* **RFQ (Section 4.2):** *Pending* (the request is awaiting responders’ quotes), *Quoted* (at least one firm quote has been received), *Declined* (a targeted responder has declined to quote), *Not selected* (a submitted quote was not chosen by the initiator).
* **Block Clear (Section 4.3):** *Pending* (the submission is awaiting the counterparty’s approval), *Approved* (both counterparties have approved; the trade proceeds to validation and execution).
* **Trade Scheduler (Section 4.4):** *Scheduled* (the order is resting in the Scheduler for execution at the settlement price, not shown in the public book and not in continuous matching, modifiable or cancellable up to the daily cutoff on its settlement date).

## Trade status

Once an order matches, the resulting trade is Executed: matched, novated to the central counterparty, and final. The Exchange launches with futures and with a central counterparty on an integrated venue-to-CCP basis, so clearing-driven trade handling is in scope from launch; what is not yet fixed is its exact shape, which depends on the chosen CCP and the clearing member arrangements. The intent is that a novated trade is final and is not reversed: a Member that cannot meet its obligations after execution is a clearing, margin and default matter, handled by the central counterparty and the clearing member (Chapters 7 and 9), surfacing on the venue as that Member’s orders being Blocked rather than as any change to the trade. Whether any post-execution trade-level state is possible at all, and if so how it behaves and what status it carries, is an open item to be confirmed once the CCP and clearing model are chosen.

## Transitions

The legal moves between the core states are:

| From               | To                                                                |
| ------------------ | ----------------------------------------------------------------- |
| Received           | Validating                                                        |
| Validating         | Active, Rejected                                                  |
| Active             | Partially executed, Executed, Cancelled, Expired, Failed, Blocked |
| Partially executed | Executed, Cancelled, Expired, Failed, Blocked                     |
| Blocked            | Cancelled, Active                                                 |

An amendment to an Active or Partially executed order re-runs validation: the order returns to Validating and then to Active (or Partially executed) if it passes, or Rejected if it does not. A cancellation moves an Active or Partially executed order to Cancelled. Under the kill-switch design a Blocked order is cancelled as part of the block; the Active exit applies only to a lighter hold tier, and the exact behaviour is confirmed with the CCP and clearing model (Chapter 7). The mechanics of amendment and cancellation are in Section 7.2 and the Order Validation and Entry Controls specification.

## Worked journeys

* **Order book, with a partial fill.** A Limit order goes Received, Validating, Active, and as it fills in two parts, Partially executed, then Executed.
* **RFQ.** A request goes Pending, then Quoted as firm quotes arrive. On the initiator accepting one, the resulting trade runs Validating, then Executed; the quotes not chosen end Not selected.
* **Block Clear.** A submission goes Received, then Pending while it awaits the counterparty, then Approved on approval, then Validating, then Executed.
* **Trade Scheduler.** A scheduled order goes Scheduled, then at execution Validating, then Executed. When execution happens and how an uncovered order is handled (which ends Rejected) depends on the Trade Scheduler design in Section 4.4, which is still open; this journey will need updating once that is settled.
* **Exception, a Blocked order.** A Member has an Active order resting and an earlier trade already Executed, when its clearing cover is withdrawn. The executed trade is unaffected and stays Executed, guaranteed by the central counterparty. Under the leading kill-switch design the Member’s Active order is Blocked and cancelled as part of the block, with re-enablement manual and logged; the exact behaviour is confirmed with the CCP and clearing model (Chapter 7).