Page History
| Table of Contents |
|---|
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.
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
| Info | ||
|---|---|---|
| ||
| It's worth remembering that while all inbound messages will adhere to the same state transition model, there will necessarily be Venue-specific variation in whether and how outbound ExecutionAck messages are handled. |
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.
| Category | OrdStatus | ExecType | Description |
|---|---|---|---|
| Transitional | PendingNew | PendingNew | Venue acknowledgement of receipt of Order. |
| Active | New | New | Venue notification of acceptance of Order. |
| Replaced | Venue notification of acceptance of a replacement Order (including client-initiated Order release). | ||
| Restated | Venue notification of venue-initiated Order release. | ||
| Active | PartiallyFilled | PendingMatch | Venue notification of a potential match. E.g. EBS eFix. |
| Trade | Venue notification of a done trade. | ||
| Replaced | Venue notification of acceptance of a replacement Order (including client-initiated Order release). Note: Order Suspend/Release should not be combined with other parameter changes. | ||
| Restated | Venue notification of venue-initiated Order change eg:
| ||
| Active | Suspended | Replaced | Venue notification of acceptance of client-initiated Order suspension. NOTE: Note: Order Suspend/Release should not be combined with other parameter changes. |
| Restated | Venue notification of venue-initiated Order change eg:
| ||
| Terminal | Filled | PendingMatch | Venue notification of a potential match. E.g. EBS eFix. |
| Trade | Venue notification of a done trade. | ||
| Transitional | PendingCancel | PendingCancel | Venue acknowledgement of receipt of OrderCancelRequest. |
| Terminal | Canceled | Canceled | Venue notification of Order cancellation. |
| Restated | Venue notification of venue-initiated Order change eg:
| ||
| Transitional | PendingReplace | PendingReplace | Venue acknowledgement of receipt of OrderCancelReplaceRequest. |
| Terminal | Rejected | Rejected | Venue rejection of order. |
| Terminal | Calculated | Trade | Venue notification of Fixing Order rate confirmations (EBS eFix), and notification of individual legs for spread instruments (CME). |
| Terminal | Expired | Expired | Venue notification of the expiry of specified TimeInForce. |
| Restated | Venue notification of venue-initiated Order change eg:
|
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 typically 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.
...
| Name | Nature | Description | 59/TimeInForce | 168/EffectiveTime | 126/ExpireTime | 1629/ExposureDuration |
|---|---|---|---|---|---|---|
| Immediate Or Cancel | Aggressive | The Order must be executed immediately, at least in part (Partial fills are allowed), otherwise the Order is cancelled. AKA 'Fill and Kill'. | IOC | Optional | - | - |
| Fill Or Kill | Aggressive | The Order must be executed immediately, in full (no Partial fills), otherwise the Order is cancelled. | FOK | Optional | - | - |
| Good For Auction | Resting | The order is only active when the instrument enters an auction state. At all other times, the order remains inactive. | GFA | OptionalOptional | - | Optional- |
| Good For Day | Resting | The Order expires automatically on close of the trading day, if it is still unfilled. | GFDDAY | OptionalOptional | - | Optional- |
| Good For Time | Resting | Order is active for a specified duration. | GFT | Optional | - | Mandatory |
| Good 'Til Date | Resting | Order is active until a specified time. | GTD | Optional | Mandatory | - |
| Good 'Til Canceled | Resting | The Order remains active until it is either executed or cancelled. NOTE: Maximum possible duration is one trading week, but is equivalent to DAY for most Venues that reset daily. | GTC | Optional | - | - |
| At Market Open | Resting | The order is only active when the instrument market opens. At all other times, the order remains inactive. It is typically entered when the market is in pre-open state. | AMO | Optional | - | - |
| At Market Close | Resting | The order is only active when the instrument market closes. At all other times, the order remains inactive. It is typically entered when the market is in pre-close state. | AMC | Optional | - | - |
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 OrderType Order Type values supported by Whisperer Enterprise for all categories are provided below.
| NameOrder Type | Category | Description | 40/OrdType | 44/Price | 99/StopPrice | 210/MaxShow | 110/MinQty | 389/DiscretionOffsetValue | 211/PegOffsetValue | 836/PegOffsetType | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Limit price | Stop price | Iceberg tip size | Added to Bid or subtracted from Offer limit price to specify the allowed slippage for the | order.Previously Quoted | Market | Anorder | to hit an individual quote. To hit multiple quotes, aka sweeping, the user must submit individual orders from best to worst price. | PreviouslyQuoted | Mandatory- | - | -' | - | - | ||||||||
| Market | Market | An instruction to deal immediately at the best possible price (the current rate) OR An instruction to deal during the auction/fixing time at the closing auction/fixing price if sent with TIF=GFA. (eg, eFIX orders on EBS) | Market | - | - | - | - | - | - | - | |||||||||||
| Dark Market | Market | Equities-specific. | Market | - | - | Zero | Optional | - | - | - | |||||||||||
| Market Range | Market | AKA "Market With Protection". A market order with specified slippage. | Market | - | - | - | - | Mandatory | - | - | |||||||||||
| Market To Limit | Market | Order that starts as a Market order and in the event of a partial fill, executes any leaves quantity as a Limit order. | MarketLimit | - | - | - | - | - | - | - | |||||||||||
| Market If Touched | Market | Market order will be submitted to market when a specified price is reached. Here, StopPrice is used to convey the Trigger price. This value should be better than the market price. | IfTouched | - | Mandatory | - | - | - | - | - | |||||||||||
| Previously Quoted | Limit | An order to hit an individual quote. To hit multiple quotes, aka sweeping, the user must submit individual orders from best to worst price. | PreviouslyQuoted | Mandatory | - | - | -' | - | - | - | |||||||||||
| Limit | Limit | AKA "Take Profit". An instruction to deal if a market moves to a more favourable level. Where multiple partial fills are allowed, a Volume Weighted Average Price (VWAP) of the total order quantity may be provided as the limit price. | Limit | Mandatory | - | - | Optional | - | - | - | |||||||||||
| Dark Limit | Limit | AKA "Hidden Limit", "Ghost", "Sniper". A form of Iceberg, where the market-visible order qty is set to zero. | Limit | Mandatory | - | Zero | Optional | - | - | - | |||||||||||
| Limit To Market | Limit | Order that starts as a Limit order and in the event of a partial fill, executes any leaves quantity as a Market order. | Funari | Mandatory | - | - | Optional | - | - | - | |||||||||||
| Limit If Touched | Limit | Limit order will be submitted to market when a specified price is reached | IfTouched | Mandatory | Mandatory | - | Optional | - | - | - | |||||||||||
| Iceberg | Limit | AKA "Reserve". A limit order that has both displayed and hidden components. | Limit | Mandatory | - | Mandatory | - | - | - | - | |||||||||||
| AllOrNone | Limit | A limit order with the remaining order quantity as MinQty. | Limit | Mandatory | - | - | Mandatory | - | - | - | |||||||||||
| Pegged | Limit | An order with an | optionaloffset to the prevailing market rate. The displayed quantity will float with the market. | Pegged | - | - | Optional | - | - | Mandatory | Mandatory | ||||||||||
| Pegged To Limit | Limit | A Pegged order, but the displayed quantity will only float up to the limit price of the order. | Pegged | OptionalMandatory | - | Optional | - | - | OptionalMandatory | Mandatory | |||||||||||
| Discretion | Limit | AKA "Limit With Protection". A limit order with specified slippage. The market sees only the limit price. | Limit | Mandatory | - | - | - | Mandatory | - | - | |||||||||||
| Stop | Stop | AKA "Stop Loss". An instruction to deal if a market moves to a less favourable level. | Stop | - | Mandatory | - | - | - | - | - | |||||||||||
| Trailing Stop | Stop | The Stop Price follows the market by a specified offset. | Stop | - | - | - | - | - | Mandatory | - | |||||||||||
| Stop Limit | Stop | Executes an exposure-reducing limit order when market exceeds order's price. | StopLimit | Mandatory | Mandatory | - | - | - | - | - | |||||||||||
| Trailing Stop Limit | Stop | A Stop Limit order where the stop trigger price is at a fixed amount below the market price, based on the user-defined "trailing" amount. The limit order price is also continually recalculated based on the limit offset. | StopLimit | - | - | - | - | Mandatory | Mandatory | - |
Algo Orders
More exotic variants of the above order types are generically categorised as Algo Orders and typically Algo Orders extend on the StandardOrderTypes above and require the specification of additional Venue-specific custom parameters . These are able to be specified via the TargetStrategy field and the NoStrategyParameters repeating group.
TWAP Orders
- TWAP
- Pegged TWAP
- Adaptive TWAP
Contingent Orders
- OCO - One Cancels the Other
- OTO - One Triggers the Other
- OUO - One Updates the Other
- OTOOCO - One Triggers OCO
OrdStatus vs ExecType
...
Venue notification of Order cancellation.
...
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/StringStrategyParameterName: "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:
| StrategyParameterName | StrategyParameterType | StrategyParameterValue |
|---|---|---|
TargetStrategy | String | BenchmarkOrFixing |
FixingSource | String | mandatory. Fixing sources vary by LP, but naming is normalised as follows:
|
| FixingDate | LocalMktDate | YYYYMMDD |
| FixingTime | TZTimeOnly | 16:00 |
| FixingTimeZone | String | Mandatory. Fixing timezones vary by LP, but naming is normalised 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:
FillNow is not supported in NewOrderMultileg - it is applicable to pre-existing orders only.
The following strategy parameters are supported in MultilegOrderCancelReplaceRequest:
| StrategyParameterName | StrategyParameterType | StrategyParamaterValue |
|---|---|---|
FillNow | Boolean |
|
FillNowQty | Qty |
|
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:
PegPriceTypePegOffsetValuePegOffsetType
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.
| Collapse to Mid | Mid Discretionary | |
|---|---|---|
Description | Collapse to Mid (CTM) pegged orders match at an ECN-defined mid-point price when an opposing order exists with the same entitlements. | Mid Discretionary pegged orders rest as a passive order, with the discretion to move up to the mid-point price of the BBO when an opposing order arrives with the same entitlements. |
Function & Priority | Faster fills compared to MDO. As CTM orders compete to match at the ECN-defined mid-point price from the start, the matching opportunity for CTM pegged orders is greater compared to MDO pegged orders. | When the attempt to match as a passive order fails, MDO orders move up to the mid-point price of the BBO to improve matching opportunity. |
Resting period | Aggressive. As a result of greater matching opportunity, the time that CTM orders rest on the book is shorter compared to MDO orders. | Passive. Rests on the book longer compared to CTM orders, as MDO starts as a passive order, and when attempting to match using mid-discretion, it should satisfy the price limitations of the opposing order to match. |
MF API interface | Clients trading CTM orders should populate the following fields in the
| Clients trading MDO orders should populate the following fields in the
|
Supported venues | Offered by the following ECN(s): | Offered by the following ECN(s): |
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.
Leg1 | Leg2 | Action on Spread |
|---|---|---|
Buy | Sell | Buys the spread - buys leg1, sells leg2 |
Sell | Buy | Sells the spread - sells leg1, buys leg2 |
Price: The Price on the order will be the spread price. The LegPrice mustnot 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: CalculatedExecType: 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:
| Category | ExecRestatementReason |
|---|---|
| Unsolicited pause/resume |
|
| Unsolicited cancellation |
|
| Unsolicited amendment |
|
Order Restatement (no changes - e.g. start of week renewal of GTC order) |
|
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):
LegLastPxLegLastQtyLegSettlDate
The correct/cancel messages to the clients are ExecutionReports with
ExecType=TradeCancelorExecType=TradeCorrectExecRefIDrefers back to theExecIDof the originalExecutionReportfor 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#TradeCorrect/Cancel) will provide the final ExecutionReport with ExecType=Restated to reflect the state of the order.
| Note | ||
|---|---|---|
| ||
When a trade is corrected (quantity reduction) or cancelled, the quantity corrected or cancelled does not go back to the order book and is not available for trading. |
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.
...