Order State Transition Model

The Order state transition model is normalised and consistent across all trading workflows, as outlined in the diagram below.

Where Venue events are absent, synthetic equivalents are generated by Whisperer in their place. These messages are easily discernible by reference to the TradingFlags.IsSynthetic field.

OrdStatus vs ExecType

The following table lists the possible OrdStatus and ExecType combinations the Client may receive in Whisperer ExecutionReport messages.

Should MultilegCancelReplaceRequest or OrderCancelRequest messages be rejected by the venue, the current working order status will be reported in the OrdStatus field of the OrderCancelReject message.

Aggressive vs  Resting Orders

Orders may be:

• Aggressive - These orders are matched against existing Resting orders held in the order book. Once submitted these orders cannot be cancelled or modified. Typically, these orders are not displayed in the venue MarketData feed.
• Resting - These orders are submitted at price levels away from the prevailing market, i.e.  buying at a price below or selling at a price above the market. Typically, these orders are displayed in the venue MarketData feed.

Time In Force

Details of the TimeInForce values supported by Whisperer Enterprise for both categories are provided below.

The time in force instruction may optionally be refined by the specification of order activation and expiry times:

• Activation - A specific order activation time may be specified via tag 168/EffectiveTime.
• Expiry - Order expiry may be specified as a specific time via tag 126/ExpireTime, or as a duration via tag 1629/ExposureDuration. The two representations may not be used together. 

Order Types

Standard Order Types

There are three broad categories of order type:

• Market - these are aggressive orders that are instructions to deal immediately at the best possible price. When buying, a market order will be filled at the currently prevailing Offer price; when selling, a market order will be filled at the currently prevailing Bid price.
• Limit - these are resting orders visible to the market - hence the existence of Central Limit Order Book (CLOB) ECNs. They are instructions to deal if a market moves to a specific (more favourable) price or better. Limit orders remain open until they are either entirely filled, or the client submits an order cancel request, or the order expires.
• Stop - these are resting orders that are not visible to the market and will activate once a specified Stop price has been met.

When matched in a CLOB ECN, Limit orders are said to be 'aggressed' by Market orders.

Details of the Order Type values supported by Whisperer Enterprise for all categories are provided below.

Algo Orders

Algo Orders extend on the StandardOrderTypes above and require the specification of additional Venue-specific custom parameters using the HasExtendedOrderFields.NoStrategyParameters repeating group in both NewOrderMultileg and MultilegOrderCancelReplaceRequest.

The Client specifies the name of the algo to be executed by providing the following entry in this repeating group:

• StrategyParameterType:  14/String
• StrategyParameterName:  "TargetStrategy"
• StrategyParameterValue: "LP-assigned name of desired Algo"

Where appropriate, Whisperer will normalise algos and algo parameters. Other strategy parameters must be populated as per LP requirements for the specific Algo; the Client will need to reference the venue-specifiec API documentation for this detail.

When a strategy parameter is populated for a venue which does not support it, the order or order modification will be rejected.

BenchmarkOrFixing Order Normalisation

Due to their widespread availability, these orders are supported in NewOrderMultileg and  MultilegOrderCancelReplaceRequest as follows:

FillNow Normalisation

"Fill Now" is an instruction to immediately fill a pre-existing order at the best price possible, supported by the following algo providers:

• bnpparibas_efx_algo
• fxspotstream_algo
• jpmorgan_fx_algo

FillNow is not supported in NewOrderMultileg - it is applicable to pre-existing orders only.

The following strategy parameters are supported in MultilegOrderCancelReplaceRequest:

Pegged Orders

Pegged Orders are smart Limit Orders that automatically adjust their limit price by tracking the market's BestBidOffer (BBO) or the mid-point price to remain competitive, achieve a fair price, and faster fills.

Clients are required to populate the following fields in the HasExtendedOrderFields repeating group to submit a Pegged order:

• PegPriceType
• PegOffsetValue
• PegOffsetType

A brief overview of a couple of Pegged order features offered by ECNs:

Collapse to Mid vs Mid Discretionary

Collapse to Mid (CTM) and Mid Discretionary (MDO) are pegged order features offered by ECNs to reduce the time to fill an order by improving the matching opportunity. CTM and MDO allow pegged orders to match at or up to the mid-point price of the BestBidOffer (BBO) when an opposing order arrives with the same entitlements.

Spread Orders

Overview

A calendar spread is a futures strategy with simultaneous long and short positions on the same underlying asset but with different expiry dates. 

• Bull spread: When a trader buys the nearby month and sells the deferred month.
• Bear spread: When a trader sells the nearby month and buys the deferred month. 

Whisperer currently only supports Bull Calendar Spreads which are defined with Buy near and Sell far legs.

Order Submission

Side: The LegSide of the first Leg on the client message to Whisperer will represent the Side of the Spread. 

Price: The Price on the order will be the spread price. The LegPrice must not be populated on the request.

ExecutionReport

The following ExecutionReport messages are published for Fills:

• 1 Notional Fill: Trade information for the overall Spread, followed by
• 2 Leg Fills: Trade information for each of the legs. 

The Notional fill and Leg fills for a given trade will all have the same SecondaryExecID

The legs on Notional fill will have the overall Notional fill information with 

• OrdStatus: Calculated
• ExecType: Calculated

Restatements

Restatements are ExecutionReport messages that are sent by the venue to notify the client of unsolicited changes to order status. They are identified with ExecType=Restated, with ExecRestatementReason also populated to specify the reason. MarketFactory categorises these according to the table below:

Trade Correct/Cancel

A trade correct/cancel message can be sent on ExecutionReports with ExecType=Trade to notify the clients of any trade amendments or cancellations. 

Trade amendments are  mostly limited to the below ExecutionReport fields (support for these may vary by venue):

• LegLastPx
• LegLastQty
• LegSettlDate

The correct/cancel messages to the clients are ExecutionReports with

• ExecType=TradeCancel or ExecType=TradeCorrect
• ExecRefID refers back to the ExecID of the original ExecutionReport for the trade being corrected or canceled. 

Order Session

Whisperer supports the trade correct/cancel on a best efforts basis.  Order attributes such as OrdType, TimeInForce, OrdStatus, LegCumQty, LegLeavesQty, LegAvgPx, etc are not mandatory for the correct/cancel ExecutionReports and may vary by venue.

In addition to the trade correct/cancel ExecutionReport, some venues (eg lseg_ftg) will provide the final ExecutionReport with ExecType=Restated to reflect the state of the order. 

DropCopy Session

If the venue supports trade correct/cancel messages on DropCopy sessions, then clients will be notified of these as ExecutionReports containing the adjustments.