Order Rejection Events and Reconciliation in Trading Systems
Article NautilusTrader
Summary
This reference explains an order-rejection event in an execution system. A rejection marks an order as terminal, updates the order and cache, and is published to the message bus for handlers such as a strategy’s rejection callback. The event commonly follows an explicit venue rejection, but reconciliation may also create one from venue reports or local policies triggered by timeouts or missing orders. Its reconciliation flag indicates the event’s origin and does not establish that the venue confirmed the rejection.
Key ideas
- An order rejection moves an order into a terminal rejected state and is delivered through the event system.
- The event includes an account identifier, a reason, a post-only indicator, and a reconciliation indicator.
- Rejection may follow direct venue evidence or a local reconciliation policy, so the source should be interpreted carefully.
- Several earlier order states can transition to rejection through external or reconciliation paths.
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
# OrderRejected
# OrderRejected
`OrderRejected` records an order reaching the terminal `REJECTED` state. The `ExecutionEngine`
applies it to the order, updates the `Cache`, and publishes it on the `MessageBus`. It normally
comes from an explicit venue rejection. Reconciliation can also create it from a venue report or
after a local timeout or missing-order policy expires.
Typical transition: `SUBMITTED` -> `REJECTED`. External and reconciliation paths also allow
`INITIALIZED`, `ACCEPTED`, `PENDING_UPDATE`, `PENDING_CANCEL`, or `TRIGGERED` -> `REJECTED`.
Handler: `on_order_rejected`.
## Fields
Beyond the [common Python order event fields](index.md#common-python-order-event-fields),
`OrderRejected` carries:
| Field | Python type | Required/default | Description |
| ---------------- | ----------- | ---------------- | ------------------------------------------------------------------------------ |
| `account_id` | `AccountId` | Required | The account associated with the order. |
| `reason` | `str` | Required | The venue reason or local reconciliation policy reason. |
| `due_post_only` | `bool` | `False` | If rejected because it was post-only and would execute immediately as a taker. |
| `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_rejected(self, event: OrderRejected) -> None:
self.log.warning(f"Order {event.client_order_id} rejected: {event.reason}")
```
## 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.