Emulated orders

Emulation lets you use order types even when your trading venue does not natively support them.

The OrderEmulator monitors the market data selected by emulation_trigger. When the local order matches its release condition, the emulator transforms it into a MARKET or LIMIT order and sends that order through the normal risk and execution path. For example, an emulated STOP_LIMIT becomes a LIMIT order after its stop price triggers.

Submitting an order for emulation

Set emulation_trigger on an order constructor or OrderFactory method. The local emulator accepts these values:

Other TriggerType values describe trigger methods that some venues support, but the local OrderEmulator does not accept them as emulation_trigger values.

The choice of trigger type determines how the order emulation will behave:

• For stop orders, the emulator compares the trigger price with the selected market data.
• For trailing‑stop orders, it updates the trailing trigger from that market data.
• For emulated LIMIT orders, it compares the limit price with that market data and releases a MARKET order when matched.

Technical details

The same OrderEmulator component manages supported emulated order types in all environment contexts.

Lifecycle

An emulated order progresses through these stages:

1. A Strategy submits it through submit_order.
2. The RiskEngine applies pre‑trade checks and may deny it.
3. The OrderEmulator holds and monitors it locally.
4. A matching market update transforms it into a MARKET or LIMIT order and releases it.
5. The RiskEngine checks the released order again before venue submission.

Held emulated orders

While the OrderEmulator holds an order:

• It caches the original SubmitOrder command.
• It processes the order in a local matching core.
• It subscribes to the required quotes or trades if no matching subscription exists.
• It accepts strategy modifications and market‑driven updates until release or cancellation.

Released emulated orders

When market data matches an emulated order, release performs these actions:

• It transforms the order into a MARKET or LIMIT order through another OrderInitialized event.
• It sets the order's emulation_trigger to NO_TRIGGER so components no longer treat it as emulated.
• It sends the transformed order and original SubmitOrder command back through the RiskEngine.
• If the risk engine does not deny it, the ExecutionEngine routes it to an ExecutionClient.

Order types that can be emulated

The released type depends on the original emulated order type:

Querying

Use the cache or the order object to query emulation status.

Through the cache

The Cache provides these methods:

• self.cache.orders_emulated(...) returns all emulated orders that match its filters.
• self.cache.is_order_emulated(...) checks one client order ID.
• self.cache.orders_emulated_count(...) returns the number of matching emulated orders.

See the full API reference for additional details.

Direct order queries

Use order.is_emulated to query an order object directly. A False value means the order was released or was never emulated.

Persistence and recovery

On startup, the OrderEmulator reactivates emulated orders that the configured cache database restored into the cache. This preserves their state across restarts.

Best practices

When working with emulated orders:

1. Query the Cache instead of storing local order references.
2. Account for the order type changing on release.
3. Handle a denial at either the initial or release‑time risk check.

Related guides

• Orders - Order concepts, execution instructions, and the order factory.
• Advanced orders - Order lists, contingency types, and bracket orders.
• Strategies - Order management from strategies.