# Emulated Orders ¶

The platform makes it possible to emulate most order types locally, regardless of whether the type is supported on a trading venue. The logic and code paths for order emulation are exactly the same for all environment contexts (backtest, sandbox, live), and utilize a common  OrderEmulator  component.

## Limitations ¶

There is no limitation on the number of emulated orders you can have per running instance. Currently only individual orders can be emulated, so it is not possible to submit contingency order lists for emulation (this may be supported in a future version).

## Submitting for emulation ¶

The only requirement to emulate an order is to pass a  TriggerType  to the  emulation_trigger  parameter of an  Order  constructor, or  OrderFactory  creation method. The following emulation trigger types are currently supported:

•  DEFAULT  (which is the same as  BID_ASK  )

•  BID_ASK  (emulated using quote ticks)

•  LAST  (emulated using trade ticks)

Emulated orders are subject to the same risk controls as ‘regular’ orders, and can be modified and canceled by a trading strategy in the normal way. They will also be included when canceling all orders.

Note

An emulated order will retain its original client order ID throughout its entire life cycle, making it easy to query through the cache.

## Life cycle ¶

An emulated order will progress through the following stages:

• Submitted by a  Strategy  through the  submit_order  method

• Then sent to the  RiskEngine  for pre-trade risk checks (if may be denied at this point)

• Then sent to the  OrderEmulator  where it is held / emulated

### Held emulated orders ¶

The following will occur for an emulated order now inside the  OrderEmulator  component:

• The original  SubmitOrder  command will be cached

• The emulated order will be held inside a local  MatchingCore  component

• The  OrderEmulator  will subscribe to any needed market data (if not already) to update the matching core

• The emulated order will be modified (by the trader) and updated (by the market) until released or canceled

### Released emulated orders ¶

Once an emulated order is triggered / matched locally based on a data feed, the following release actions will occur:

• The order will be transformed to either a  MARKET  or  LIMIT  order (see below table) through an additional  OrderInitialized  event

• The orders  emulation_trigger  will be set to  NONE  (it will no longer be treated as an emulated order by any component)

• The order attached to the original  SubmitOrder  command will be sent back to the  RiskEngine  for additional checks since any modification/updates

• If not denied, then the command will continue to the  ExecutionEngine  and on to the trading venue via an  ExecutionClient  as normal

The following table lists which order types are possible to emulate, and which order type they transform to when being released for submission to the trading venue.

## Order types ¶

Can emulate

Released type

 MARKET 

No

-

 MARKET_TO_LIMIT 

No

-

 LIMIT 

Yes

 MARKET 

 STOP_MARKET 

Yes

 MARKET 

 STOP_LIMIT 

Yes

 LIMIT 

 MARKET_IF_TOUCHED 

Yes

 MARKET 

 LIMIT_IF_TOUCHED 

Yes

 LIMIT 

 TRAILING_STOP_MARKET 

Yes

 MARKET 

 TRAILING_STOP_LIMIT 

Yes

 LIMIT 

## Querying ¶

When writing trading strategies, it may be necessary to know the state of emulated orders in the system. It’s possible to query for emulated orders through the following  Cache  methods:

•  self.cache.orders_emulated(...) 

•  self.cache.is_order_emulated(...) 

•  self.cache.orders_emulated_count(...) 

See the full API reference for additional details.

You can also query order objects directly in pure Python:

•  order.is_emulated 

Or through the C API if in Cython:

•  order.is_emulated_c() 

If either of these return  False  , then the order has been released from the  OrderEmulator  , and so is no longer considered an emulated order.

Warning

It’s not advised to hold a local reference to an emulated order, as the order object will be transformed when/if the emulated order is released . You should rely on the  Cache  which is made for the job.

## Persisted emulated orders ¶

If a running system either crashes or shuts down with active emulated orders, then they will be reloaded inside the  OrderEmulator  from any configured cache database. It should be remembered that any custom  position_id  originally assigned to the submit order command will be lost (as per the above warning).