Handling Trigger Events for Conditional Orders

Summary

This reference explains an order-trigger event in a trading system. A venue, simulated matching engine, or reconciliation process can report that a conditional order has reached its trigger. The event applies to order types such as stop limit, limit if touched, and trailing stop limit. The typical state change is from accepted to triggered, after which the event pipeline updates the order, refreshes the cache, and publishes the event on a message bus for strategy handlers.

The document identifies two optional identifiers, for the venue order and account, plus a required flag indicating whether reconciliation generated the event. It also names the handler used by a strategy to receive the notification. This is implementation documentation rather than a trading method, and it offers no evidence about execution quality, trigger-price handling, or how triggered orders subsequently fill. A triggered state signals that the condition was met; it does not by itself establish that the order executed. Users of the event should distinguish the trigger notification from later order lifecycle events.

Key ideas

• A trigger event records that a conditional order's trigger condition was reached.
• The described order types include stop limit, limit if touched, and trailing stop limit.
• The pipeline updates the order and cache, then publishes the event.
• Venue and account identifiers may be absent, while the reconciliation indicator is required.
• A trigger notification does not establish that the order has filled.

Tags

# OrderTriggered


# OrderTriggered

`OrderTriggered` records that a limit-style conditional order has triggered. The execution pipeline
applies it to the order, updates the `Cache`, and publishes it on the `MessageBus`. A trading venue,
simulated matching engine, or reconciliation can report the trigger for a `StopLimit`,
`LimitIfTouched`, or `TrailingStopLimit` order.

Typical transition: `ACCEPTED` -> `TRIGGERED`. Handler: `on_order_triggered`.

## Fields

Beyond the [common Python order event fields](index.md#common-python-order-event-fields),
`OrderTriggered` 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. |
| `reconciliation` | `bool`                   | Required         | If generated during reconciliation.              |

## Example

Reading the event in a strategy handler:

```python
def on_order_triggered(self, event: OrderTriggered) -> None:
    self.log.info(f"Order {event.client_order_id} triggered")
```

## Related guides

- [Events](index.md) - Event categories, dispatch, and the common order event fields.
- [Orders](../orders/) - Order types and the state machine.

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.