Order Canceled Events and Their Reconciliation Provenance
Summary
The document explains an order-canceled event in an execution system: it records an order entering the terminal canceled state, updates the order and cache, and is published to the message bus. Cancellation events may originate from a venue, a simulated matching engine, a local emulator, or reconciliation. Reconciliation can be based on venue reports or local timeout and missing-order policies.
The event may follow several order states, including pending cancellation, acceptance, submission, triggering, and partial fill. A late fill after an earlier cancellation can also lead to a second canceled event. The documented fields include optional venue and account identifiers, an optional reason, and a required reconciliation flag. That flag identifies the event's source; it does not confirm that the venue itself canceled the order. The page gives a handler example and links the event to the broader order state machine and execution policies.
Key ideas
- An OrderCanceled event records cancellation and is applied to the order, cache, and message bus.
- Events can come from venues, simulated matching, local emulation, or reconciliation.
- Reconciliation-generated cancellation does not by itself establish venue confirmation.
- A cancellation can follow multiple states, and a late fill may result in another cancellation event.
- The event includes optional venue, account, and reason fields plus a required reconciliation indicator.
Tags
Cited by
- Strategies Overnight-Return Daytime-Reversal Frequency, Dollar-Neutral Long-Short on 30 US Large Caps (USEQ 1-DAY, Akbas-Boehmer-Jiang-Koch tug-of-war)
- Hypotheses Overnight-Return Daytime-Reversal Frequency, Dollar-Neutral Long-Short on 30 US Large Caps (USEQ 1-DAY, Akbas-Boehmer-Jiang-Koch tug-of-war)
Full text
# OrderCanceled
# OrderCanceled
`OrderCanceled` records an order reaching the terminal `CANCELED` state. The execution pipeline
applies it to the order, updates the `Cache`, and publishes it on the `MessageBus`. It can come from
a trading venue, simulated matching engine, local order emulator, or reconciliation. Reconciliation
can create it from a venue report or from a local timeout or missing-order policy.
Typical transitions: `PENDING_CANCEL`/`ACCEPTED` -> `CANCELED`. External and recovery paths also
allow `INITIALIZED`, `EMULATED`, `RELEASED`, `SUBMITTED`, `PENDING_UPDATE`, `TRIGGERED`, or
`PARTIALLY_FILLED` -> `CANCELED`. A re-close can append `CANCELED` while the order is already
canceled when a late fill arrived after its earlier cancellation. Handler: `on_order_canceled`.
## Fields
Beyond the [common Python order event fields](index.md#common-python-order-event-fields),
`OrderCanceled` carries:
| Field | Python type | Required/default | Description |
| ---------------- | ------------------------ | ---------------- | ------------------------------------------------------------------------------ |
| `venue_order_id` | `VenueOrderId` or `None` | `None` | The venue-assigned order identifier, if known. |
| `account_id` | `AccountId` or `None` | `None` | The account associated with the order, if known. |
| `reason` | `str` or `None` | `None` | The cancellation reason supplied by the venue. |
| `reconciliation` | `bool` | Required | If reconciliation generated the event; this does not imply venue confirmation. |
## Example
Reading the event in a strategy handler:
```python
def on_order_canceled(self, event: OrderCanceled) -> None:
self.log.info(f"Order {event.client_order_id} canceled")
```
## Related guides
- [Events](index.md) - Event categories, dispatch, and the common order event fields.
- [Orders](../orders/) - Order types and the state machine.
- [Execution policies](../execution/policies.md#terminal-reconciliation-provenance) - Venue
evidence and synthetic terminal policies.Shown in full with attribution under the source's licence. Licence: LGPL-3.0
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.