Introduction

“Orders and Executions” (or “Trade”) messaging is characterized as messages which are used to place or amend orders and communicate the results and status of orders.

The specific FIX “Orders and Executions” (or “Trade”) messaging categories are:

  1. SINGLE/GENERAL ORDER HANDLING
  2. ORDER MASS HANDLING
  3. CROSS ORDER HANDLING
  4. MULTILEG ORDER HANDLING
  5. LIST/PROGRAM/BASKET TRADING
  6. APPENDIX: COMPONENTS AND MESSAGES

Descriptions of the specific FIX pre-trade application messages follow. There is a diagram for each of the messages depicting its components. Required components are shown with a red outline and repeating groups contain an arrow symbol. Some messages do not have any components.

List of Component Blocks and Messages for Trade

Component Blocks

This section lists component blocks used by trade messages defined in this part of the FIX specification. Some of these are Common Component blocks used by more than one category in this area. Messages may also reference Global Component blocks, which are components used by messages across all areas. Global Common Components are defined in the overall introduction to the FIX specification as well as online.

Component blocks can be either repeating (aka a group) or non-repeating, i.e. contain multiple instances of a set of fields. Component blocks can be nested to any level.

Type NameCategory
RepeatingAffectedOrdGrpOrderMassHandling
RepeatingBidCompReqGrpProgramTrading
RepeatingBidCompRspGrpProgramTrading
RepeatingBidDescReqGrpProgramTrading
RepeatingContraGrpSingleGeneralOrderHandling
Non-RepeatingDiscretionInstructionsCommon Components
RepeatingFillsGrpSingleGeneralOrderHandling
RepeatingInstrmtLegExecGrpSingleGeneralOrderHandling
RepeatingInstrmtStrkPxGrpProgramTrading
RepeatingLegOrdGrpMultilegOrderHandling
RepeatingLegPreAllocGrpCommon Components
RepeatingListOrdGrpProgramTrading
RepeatingNestedParties3Common Components
RepeatingNestedParties4SingleGeneralOrderHandling
RepeatingNotAffectedOrdersGrpOrderMassHandling
RepeatingNstdPtys3SubGrpCommon Components
RepeatingNstdPtys4SubGrpSingleGeneralOrderHandling
RepeatingOrdListStatGrpProgramTrading
Non-RepeatingPegInstructionsCommon Components
RepeatingPreAllocGrpCommon Components
RepeatingPreAllocMlegGrpMultilegOrderHandling
RepeatingSideCrossOrdCxlGrpCrossOrderHandling
RepeatingSideCrossOrdModGrpCrossOrderHandling
RepeatingStrategyParametersGrpCommon Components
Non-RepeatingTriggeringInstructionCommon Components

Messages

This section lists the trade messages and the single category each of them belongs to.

MsgType(35)NameCategory
kBidRequestProgramTrading
lBidResponseProgramTrading
tCrossOrderCancelReplaceRequestCrossOrderHandling
uCrossOrderCancelRequestCrossOrderHandling
QDontKnowTradeSingleGeneralOrderHandling
BNExecutionAcknowledgementSingleGeneralOrderHandling
8ExecutionReportSingleGeneralOrderHandling
KListCancelRequestProgramTrading
LListExecuteProgramTrading
NListStatusProgramTrading
MListStatusRequestProgramTrading
mListStrikePriceProgramTrading
ACMultilegOrderCancelReplaceMultilegOrderHandling
sNewOrderCrossCrossOrderHandling
ENewOrderListProgramTrading
ABNewOrderMultilegMultilegOrderHandling
DNewOrderSingleSingleGeneralOrderHandling
9OrderCancelRejectSingleGeneralOrderHandling
GOrderCancelReplaceRequestSingleGeneralOrderHandling
FOrderCancelRequestSingleGeneralOrderHandling
BZOrderMassActionReportOrderMassHandling
CAOrderMassActionRequestOrderMassHandling
rOrderMassCancelReportOrderMassHandling
qOrderMassCancelRequestOrderMassHandling
AFOrderMassStatusRequestOrderMassHandling
HOrderStatusRequestSingleGeneralOrderHandling

Common Components

DiscretionInstructions

This common component is used on an order to indicate that the trader wishes to display the order at one price but will accept trades at another price based on the discretion parameters specified in the component. The component layout is available here.

LegPreAllocGrp

This common component is a repeating group and used on a multileg order to convey the allocation information prior to an execution at each instrument leg level. The component layout is available here.

NestedParties3

This common component is a repeating group that is identical to the global Parties component. It provides information about one or more party(-ies) within the context of where this component appears in. The component layout is available here.

NstdPtys3SubGrp

This common component is a repeating group that is part of the repeating group NestedParties3. It is used to provide additional or supplemental information related to the instance of the party identifier it is attached to. The component layout is available here.

PegInstructions

This common component is used on an order to tie the price of a security to a market event such as opening price, mid-price, or best price and may also be used to tie the price to the behavior of a related security. The component layout is available here.

PreAllocGrp

This common component is a repeating group that is used on a single leg order to convey allocation information that is to be applied once the trade is completed. The component layout is available here.

StrategyParametersGrp

This common component is a generic repeating group that is used on an order to convey name, data type, and value of parameters for algorithmic trading strategies. The component layout is available here.

TriggeringInstruction

This common component is used on an order to convey the conditions under which an order will be triggered by related market events as well as the behavior of the order in the market once it is triggered. The component layout is available here.

Category – Single/General Order Handling

Components

ContraGrp

This component is a repeating group that is part of the ExecutionReport(35=8) message to convey one or more brokers acting as counterparties to a trade. It supports the identification of the broker’s trader as well as related quantity and time. In case of multileg order executions it is possible to reference an individual leg with ContraLegRefID(655). The component layout is available here.

FillsGrp

This component is a repeating group that is part of the ExecutionReport(35=8) message to convey one or more partial executions of a single match event resulting in multiple executions. The component layout is available here.

InstrmtLegExecGrp

This component is a repeating group that is part of the ExecutionReport(35=8) message to convey leg level execution information. Apart from a number of individual attributes, it also supports the repetition of leg level information (instrument definition, pre-allocation information, stipulations) provided during the order submission with LegOrdGrp. The component layout is available here.

NestedParties4

This component is a repeating group that is identical to the global Parties component. It provides information about one or more party(-ies) within the context of where this component appears in. The component layout is available here.

NstdPtys4SubGrp

This component is a repeating group that is part of the repeating group NestedParties4. It is used to provide additional or supplemental information related to the instance of the party identifier it is attached to. The component layout is available here.

Messages

New Order – Single

The NewOrderSingle(35=D) message type is used by institutions wishing to electronically submit securities and forex orders to a broker for execution.

The NewOrderSingle(35=D) message type may also be used by institutions or retail intermediaries wishing to electronically submit Collective Investment Vehicle (CIV) orders to a broker or fund manager for execution.

Orders can be submitted with special handling instructions and execution instructions. Handling instructions refer to how the broker should handle the order on its trading floor (see HandlInst(21)). Execution instructions contain explicit directions as to how the order should be executed (see ExecInst(18)).

NewOrderSingle(35=D) messages received with the PossResend(97) flag set in the StandardHeader component should be validated by ClOrdID(11). Implementations should also consider checking order parameters (Side(54), Symbol(55), OrderQty(38), etc.) to determine if the order had been previously submitted. Possible resends previously received should be acknowledged back to the client via an ExecutionReport(35=8) message with ExecType(150) = I (Order Status). Possible resends not previously received should be processed as a new order and acknowledged via an ExecutionReport(35=8) message with ExecType(150) = 0 (New).

The value specified in TransactTime(60) should allow the receiver of the order to apply business rules to determine if the order is potentially “stale” (e.g. in the event that there have been communication problems). To support forex accommodation trades, ForexReq(121) and SettlCurrency(120), are included in the message. To request a broker to execute a forex trade in conjunction with the securities trade, the institution would set ForexReq(121) = Y and SettlCurrency(120) to the intended settlement currency. The broker would then execute a forex trade from the execution currency to the settlement currency and report the results via the ExecutionReport(35=8) message in SettlCurrAmt(119) and SettlCurrency(120).

Orders involving or requiring pre-trade allocation consist of the following steps:

  • Buy-side sends a NewOrderSingle(35=D) message specifying one or more AllocAccount(79) and AllocQty(80) values within the repeating group designated by NoAllocs(78), i.e. PreAllocGrp.
  • Sell-side sends ExecutionReport(35=8) messages for the “New” with ExecType(150) = 0 (New) and resulting fills ExecType(150) = F (Trade).
  • Post-trade allocation messaging takes place

To “take” an IOI (or Quote) from an ECN or exchange and not display the order on the book, the NewOrderSingle(35=D) message should contain TimeInForce(59) = 3 (ImmediateOrCancel) and OrdType(40) = E (Previously Indicated) (or D (Previously Quoted)).

The message layout is available here. See also specification of Order State Changes.

Execution Reports

The ExecutionReport(35=8) message is used to:

  1. confirm the receipt of an order
  2. confirm changes to an existing order (i.e. accept cancel and replace requests)
  3. relay order status information
  4. relay fill information on working orders
  5. relay fill information on tradeable or restricted tradeable quotes
  6. reject orders
  7. report post-trade fees calculations associated with a trade

NOTE: ExecutionReport(35=8) messages with ExecType(150) = F (Trade) do not replace the end-of-day confirm. They are to be regarded only as replacements for the existing fill messages currently communicated via telephone.

NOTE: Individual ExecutionReport(35=8) messages are sent for each order on a NewOrderList(35=E) message.

Each ExecutionReport(35=8) message contains two fields which are used to communicate both the current state of the order as understood by the broker (OrdStatus(39)) and the purpose of the message (ExecType(150)).

In an ExecutionReport(35=8) message OrdStatus(39) is used to convey the current state of the order. If an order simultaneously exists in more than one order state, the value with highest precedence is the value that is reported in OrdStatus(39). The order statuses are as follows (in highest to lowest precedence):

PrecedenceOrdStatusDescription
11Pending CancelOrder with a pending cancel request, used to confirm receipt of an OrderCancelRequest(35=F) message. DOES NOT INDICATE THAT THE ORDER HAS BEEN CANCELED.
10Pending ReplaceOrder with a pending replacement request, used to confirm receipt of an OrderCancelReplaceRequest(35=G) message. DOES NOT INDICATE THAT THE ORDER HAS BEEN REPLACED.
9Done for DayOrder not, or partially, filled; no further executions forthcoming for the trading day
8CalculatedOrder has been completed for the day (either filled or done for day). Commission or currency settlement details have been calculated and reported in this execution message
7FilledOrder completely filled, no remaining quantity
6StoppedOrder has been stopped at the exchange. Used when guaranteeing or protecting a price and quantity
5SuspendedOrder has been placed in suspended state at the request of the client.
4CanceledCanceled order with or without executions
4ExpiredOrder has been canceled in broker’s system due to TimeInForce(59) instructions. The only exceptions are Fill or Kill and Immediate or Cancel orders that have Canceled as terminal order state.
3Partially FilledOutstanding order with executions and remaining quantity
2NewOutstanding order with no executions
2RejectedOrder has been rejected by sell-side (broker, exchange, ECN). NOTE: An order can be rejected subsequent to order acknowledgment, i.e. an order can pass from New to Rejected status.
2Pending NewOrder has been received by sell-side’s (broker, exchange, ECN) system but not yet accepted for execution. An execution message with this status will only be sent in response to a OrderStatusRequest(35=H) message.
1Accepted for biddingOrder has been received and is being evaluated for pricing. It is anticipated that this status will only be used with the BidType(394) = 2 (Disclosed style) List Order Trading model.

ExecType(150) is used to identify the purpose of the ExecutionReport(35=8) message. To transmit a change in OrdStatus(39) for an order, the broker (sell side) should send an ExecutionReport(35=8) message with the new OrdStatus(39) value and an ExecType(150) value that reflects the event that caused the order status to change. The only exception to this rule is that when rejecting a cancel or cancel/replace request the OrderCancelReject(35=9) message is used both to reject the request and to communicate the current OrdStatus(39). ExecType(150) = 6 (Pending Cancel) or E = Pending Replace is used to indicate that a cancel or cancel/replace request is being processed. ExecType(150) = 4 (Canceled) or 5 (Replaced) is used to indicate that the cancel or cancel/replace request has been successfully processed.

Execution information (e.g. new partial fill or complete fill) should not be communicated in the same report as one which communicates other state changes (such as pending cancel, pending replace, canceled, replaced, accepted, done for day etc).

Any fills which occur and need to be communicated to the customer while an order is “pending” and waiting to achieve a new state (e.g. via a OrderCancelReplaceRequest(35=G) (aka Order Modification)) must contain the “original” (current order prior to state change request) order parameters (i.e. ClOrdID(11), OrderQty(38), Price(44), etc). These fills will cause CumQty(14) and AvgPx(6) to be updated. An order cannot be considered replaced until it has been explicitly accepted and confirmed to have reached the replaced status via an ExecutionReport(35=8) message with ExecType(150) = 5 (Replace), at which time the effect of the replacement (ClOrdID(11), new quantity or limit price etc) will be seen.

Requests to cancel or cancel/replace an order are only acted upon when there is an outstanding order quantity. Requests to replace OrderQty(38) to a level less than CumQty(14) will be interpreted by the broker as requests to stop executing the order. Requests to change price on a filled order will be rejected (see OrderCancelReject(35=9) message). OrderQty(38), CumQty(14), LeavesQty(151), and AvgPx(6) should be calculated to reflect the cumulative result of all versions of an order. For example, if partially filled order A were replaced by order B, OrderQty(38), CumQty(14), LeavesQty(151), and AvgPx(6) on order B’s fills should represent the cumulative result of order A plus those on order B.

The general rule is: OrderQty(38) = CumQty(14) + LeavesQty(151).

There can be exceptions to this rule when ExecType(150) and/or OrdStatus(38) are 4 (Canceled), 3 (Done For Day) (e.g. on a day order), C (Expired), B (Calculated), or 8 (Rejected) in which case the order is no longer active and LeavesQty(151) could be 0.

Communication of information about a new fill is via the ExecutionReport(35=8) message with ExecType(150) = F (Trade). Execution Reports with ExecType = H (Trade Cancel) or G (Trade Correct) are used to cancel or correct a previously modified ExecutionReport(35=8) message as follows:

  • ExecType(150) = H (Trade Cancel) applies at the execution level and is used to cancel an execution which has been reported in error. The canceled execution will be identified in ExecRefID(19). Note: ExecType(150) = H (Trade Cancel) should not be used to cancel a previous ExecutionReport(35=8) message with ExecType(150) = H (Trade Cancel), i.e. one cannot cancel a cancel.
  • ExecType(150) = G (Trade Correct) applies at the execution level and is used to modify an incorrectly reported fill. The incorrect execution will be identified in ExecRefID(19). If a single execution is corrected more than once, ExecRefID(19) should refer to ExecID(17) of the last corrected ExecutionReport(35=8) message (same convention as ClOrdID(11) and OrigClOrdID(41)). To correct an ExecutionReport(35=8) message which was previously canceled, an ExecutionReport(35=8) message with ExecType(150) = F (Trade) should be sent (i.e. cannot send ExecType(150 ) = G (Trade Correct) for an ExecutionReport(35=8) message with ExecType(150) = F (Trade Cancel)). Note: Data reported in CumQty(14), LeavesQty(151), and AvgPx(6) represent the status of the order as of the time of the correction, not as of the time of the originally reported execution.

ExecType(150) = I (Order Status) indicates that the ExecutionReport(35=8) message contains no new information, only summary information regarding order status. It is used, for example, in response to an OrderStatusRequest(35=H) message.

See specification of Order State Changes for examples of key state changes, processing of cancel and cancel/replace requests, and for execution cancel/corrects.

An ExecutionReport(35=8) message with ExecType(150) = D (Restated) is sent by the sell-side communicating a change in the order or a restatement of the order’s parameters without an electronic request from the customer. ExecRestatementReason(378) must be set. This is used for GT (Good Till) orders (TimeInForce(59) = 1 (GTC) or 5 (GTX) or 6 (GTD)) and corporate actions (see below), changes communicated verbally to the sell-side either due to normal business practices or as an emergency measure when electronic systems are not available, repricing of orders by the sell-side (such as making sell short orders (Side(54) = 5 (Sell short)) compliant with uptick / downtick rules), or other reasons (Broker option). ExecRestatementReason(378) can also be used to communicate unsolicited cancels.

ClOrdID(11) is provided for institutions or buy-side brokers or intermediaries to affix an identification number to an order to coincide with internal systems. OrderID(37) is populated with the sell-side broker-generated order number (or fund manager-generated order number for CIVs). Unlike ClOrdID(11)/OrigClOrdID(41) which requires a chaining through OrderCancel/ReplaceRequest(35=G) and OrderCancelRequest(35=F) messages, OrderID(37) and SecondaryOrderID(198) are not required to change through changes to an order.

The underlying business assumption of orders that can trade over multiple days, such as TimeInForce(59) = 1 (GTC) and 6 (GTD) orders expiring on a future trading date (henceforth referred to as GT orders) is that a GT order that is not fully executed and has not been canceled and has not expired on a given day remains good for the broker to execute the following day. Note that the concept of “day” is determined by the market convention, which will be security specific. At the end of each trading day, once the order is no longer subject to execution, the broker may optionally send an ExecutionReport(35=8) with ExecType(150) = 3 (Done for Day). When the ExpireDate(432) or ExpireTime(132) of an order with TimeInForce(59) = 6 (GTD) is reached, or an order with TimeInForce(59) = 1 (GTC) reaches a maximum age, the order is considered expired and the broker may optionally send an ExecutionReport(35=8) with ExecType(150) = C (Expired) and OrdStatus(39) = C (Expired).

In handling GT orders, OrderQty(38), CumQty(14) and AvgPx(6) will represent the entirety of the order over all days. DayOrderQty(424), DayCumQty(425), and DayAvgPx(426) can be used on days following the day of the first trade on a GT order. Prior to the start of business each day, for all GT orders that have partial fills on previous days, DayCumQty(425) and DayAvgPx(426) are set to zero, and DayOrderQty(424) becomes the LeavesQty(151). The following relationship holds: DayOrderQty(424) = OrderQty(38) – (CumQty(14) – DayCumQty(425)). Since (CumQty(14) – DayCumQty(425)) represents the volume traded on all previous days, DayOrderQty(425) = OrderQty(38) – Volume traded on all previous days. Note that when changing the quantity of an order, both OrderQty(38) and DayOrderQty(424) will change. Requests to change or cancel an order will be made in terms of the total quantity for the order, not the quantity open today. For example, on an order where OrderQty(38) = 10000 and 2000 shares trade during the previous days, a request to change OrderQty(38) to 15000 will mean that 13000 shares will be open. See specification of Order State Changes for examples of cancelling and changing GT orders partially filled on previous days.

A cancel on an execution (trade bust, ExecType(150) = H (Trade Cancel)) happening the same day of the trade will result in CumQty(14) and DayCumQty(425) each decreasing by the quantity busted, and LeavesQty(151) increasing by the quantity busted. OrderQty(38) and DayOrderQty(424) will remain unchanged. If the business rules allow for a trade bust to be reported on a later date than the trade being busted, the OrderQty(38) and DayCumQty(424) will remain unchanged, the LeavesQty(151) and DayOrderQty(424) will increase by the quantity busted, and the CumQty(14) will decrease by the quantity busted.

If bilaterally agreed between counterparties, a broker may wish to transmit a list of all open GT orders, permitting reconciliation of the open orders. Typically this transmission may occur at the end of the trading day or at the start of the following trading day. There is no expected response to such retransmission; in the event of a reconciliation problem this should be resolved manually or via the DontKnowTrade(35=Q) message. Assuming no corporate actions have occurred, the broker will send an ExecutionReport(35=8) message with ExecType(150) = D (Restated) and ExecRestatementReason(378) = 1 (GT renewal / restatement (no corporate action)) for each open GT order. These ExecutionReport(35=8) messages may have DayCumQty(425) and DayAvgPx(426) restated to zero, and DayOrderQty(424) restated to LeavesQty(151) if the transmission occurs at the start of the following business day. The broker has the option of changing OrderID(37) and SecondaryOrderID(198), or leaving them unchanged. If they are changed, then the buy-side should use these new ID fields when sending OrderCancelRequest(35=F), OrderCancel/ReplaceRequest(35=G), and OrderStatusRequest(35=H) messages.

In the case of a corporate action resulting in the adjustment of an open GT order, the broker will send an ExecutionReport(35=8) message with ExecType(150) = D (Restated) and ExecRestatementReason(378) = 0 (GT Corporate action) with the order’s state after the corporate action adjustment. In the case of stock splits, OrderQty(38), CumQty(14), AvgPx(6), and LeavesQty(151) will be adjusted to reflect the order’s state in terms of current quantity (e.g. shares), not pre-split quantity (e.g. shares). See specification of Order State Changes for examples of GT order restatement with and without a corporate action.

The ExecutionReport(35=8) message is also used for multileg instruments. The message layout is available here.

Don’t Know Trades

The DontKnowTrade(35=Q) message (a.k.a. DK message) notifies a trading partner that an electronically received execution has been rejected. This message can be thought of as an execution reject message.

This message has special utility when dealing with one-way execution reporting. If the initial order acknowledgment (ExecutionReport(35=8) message with LastQty(32) = 0 and OrdStatus(39) = 0 (New)) does not match an existing order this message can be used to notify the broker of a potential problem order.

Note that the decision to “DK an execution” lies with the institution. Some of the mismatches listed in DKReason(127) may be acceptable and will not require a DontKnowTrade(35=Q) message to be generated. The message layout is available here.

Execution Report Acknowledgements

The ExecutionAck(35=BN) message is an optional message that provides dual functionality to notify a trading partner that an electronically received execution has either been accepted or rejected (DK’d).

The DK portion of this message does not replace the existing DontKnowTrade(35=Q) message for users who have already implemented the DontKnowTrade(35=Q) message. For users who have not implemented the DontKnowTrade(35=Q) message, through this single message they will be able to accept and DK an ExecutionReport(35=8) message. Users who wish to continue to use the DontKnowTrade(35=Q) message but also want a means to explicitly accept an execution report can also use this message. The message layout is available here.

Order Cancel/Replace Requests

The OrderCancelReplaceRequest(35=G) message (a.k.a. Order Modification Request) is used to change the parameters of an existing order.

Do not use this message to cancel the remaining quantity of an outstanding order, use the OrderCancelRequest(35=F) message for this purpose.

The OrderCancelReplaceRequest(35=G) message will be used to change any valid attribute of an open order (i.e. reduce/increase quantity, change limit price, change instructions, etc.), Subject to agreement between counterparties, it can be used to re-open a filled order by increasing OrderQty(38).

An immediate response to this message is required. It is recommended that an ExecutionReport(35=8) with ExecType(150) = E (Pending Replace) be sent unless the OrderCancelReplaceRequest(35=G) can be immediately accepted (ExecutionReport(35=8) with ExecType(150) = 5 (Replaced)) or rejected (OrderCancelReject(35=9) message).

The OrderCancelReplaceRequest(35=G) message will only be accepted if the order can successfully be pulled back from the exchange (floor) without executing. Requests which cannot be processed will be rejected using the OrderCancelReject(35=9) message. The OrderCancelReject(35=9) message should provide the ClOrdID(11) and OrigClOrdID(41) values which were specified on the OrderCancelReplaceRequest(35=G) message for identification.

Note that while it is necessary for the ClOrdID(11) to change and be unique, the broker’s OrderID(37) field does not necessarily have to change as a result of the OrderCancelReplaceRequest(35=G) message.

The protocol supports the chaining of multiple OrderCancelReplaceRequest(35=G) messages, though trading counterparties may not support this functionality. Care should be taken if the order sender wishes to send a OrderCancelReplaceRequest(35=G) message when there is one or more OrderCancelReplaceRequest(35=G) messages which have not been accepted or rejected – in general:

  • The order sender should chain client order IDs on an ‘optimistic’ basis, i.e. set the OrigClOrdID(41) to the last non rejected ClOrdID(11) sent
  • The order receiver should chain client order IDs on a ‘pessimistic’ basis, i.e. set the OrigClOrdID(41) on ExecutionReport(35=8) messages that convey the receipt or successful application of a OrderCancelReplaceRequest(35=G) and OrderCancelReject(35=9) message to be the last ‘accepted’ ClOrdID(11) (See specification of Order State Changes for examples of this.)

In the event that the order sender wants to chain order OrderCancelReplaceRequest(35=G) messages rapidly then they should ensure that each OrderCancelReplaceRequest(35=G) message contains the full details of the order as they would now like it to be. For example if an attempt is made to change the limit price and then an immediate request to change the quantity is issued then if the desired behaviour is that both the limit price and quantity should be changed then the second request should include the revised limit price (in case the first OrderCancelReplaceRequest(35=G) message is rejected).

All of the application-level fields in the original order should be retransmitted with the original values in the OrderCancelReplaceRequest(35=G) message, except the fields that are being changed. Any field may be changed with this message except those in the Instrument component block and limited changes to Side(54) (noted below), however, buy-side firms should note that sell-side firms may further restrict which fields they allow to change; hence bilateral agreement is required. For example, some sell-side firms may not allow fields such as Side(54), SettlDate(64), etc. to change. Sell-side firms should validate the OrderCancelReplaceRequest(35=G) message to ensure that the client is not requesting a change for a field that the sell-side cannot change; in this case the sell-side should send an OrderCancelReject(35=9) message with CxlRejReason(102) = 2 (Broker/Exchange Option).

When modifying ExecInst(18) values in a replacement order, it is necessary to re-declare all ExecInst(18) values in the replacement order. ExecInst(18) values will not be carried forward from the original order to the replacement unless re-declared. The message layout is available here.

Order Cancel Requests

The OrderCancelRequest(35=F) message requests the cancellation of all of the remaining quantity of an existing order. Note that the OrderCancelReplaceRequest(35=G) message should be used to partially cancel (reduce) an order.

The request will only be accepted if the order can successfully be pulled back from the exchange (floor) without executing.

A OrderCancelRequest(35=F) message is assigned a ClOrdID(11) and is treated as a separate entity. If rejected, the ClOrdID(11) of the OrderCancelRequest(35=F) message will be sent in the OrderCancelReject(35=9) message, as well as the ClOrdID(11) of the actual order in OrigClOrdID(41). The ClOrdID(11) assigned to the OrderCancelRequest(35=F) message must be unique amongst the ClOrdID(11) values assigned to regular orders and replacement orders.

An immediate response to this message is required. It is recommended that an ExecutionReport(35=8) with ExecType(150) = 6 (Pending Cancel) be sent unless the OrderCancelRequest(35=F) message can be immediately accepted (ExecutionReport(35=8) with ExecType(150) = 4 (Canceled)) or rejected (OrderCancelReject(35=9) message). The message layout is available here.

Order Cancel Rejections

The OrderCancelReject(35=9) message is issued by the broker upon receipt of a OrderCancelRequest(35=F) or OrderCancelReplaceRequest(35=G) message which cannot be honored. Requests to change price or decrease quantity are executed only when an outstanding quantity exists. Filled orders cannot be changed (i.e quantity reduced or price change. However, the broker/sell-side may support increasing the order quantity on a currently filled order).

When rejecting a OrderCancelReplaceRequest(35=G) (or OrderCancelRequest(35=F)) message, the OrderCancelReject(35=9) message should provide the ClOrdID(11) which was specified on the OrderCancelReplaceRequest(35=G) (or OrderCancelRequest(35=F)) message for identification, and the OrigClOrdId(41) should be that of the last accepted order (except in the case of CxlRejReason(102) = 1 (Unknown Order).

When rejecting an OrderMassCancelRequest(35=q) message, ClOrdID(11) should be set to the ClOrdID(11) value of the OrderMassCancelRequest(35=q) message. OrigClOrdID(41) is not specified for a rejected OrderMassCancelRequest(35=q) message.

The ExecutionReport(35=8) message responds to accepted OrderCancelReplaceRequest(35=G) (or OrderCancelRequest(35=F)) messages.

The message layout is available here.

Order Status Requests

The OrderStatusRequest(35=H) message is used by the institution to generate an ExecutionReport(35=8) message with ExecType(150) = I (Order Status) back from the broker.

(See specification of Order State Changes for usage examples of this message, including how to respond to an OrderStatusRequest(35=H) message for an unknown order.) The message layout is available here.

Category – Order Mass Handling

Components

AffectedOrdGrp

This component is a repeating group that is used to reference the orders that have been impacted by a mass action such as a mass cancellation. It does not provide any further attributes of the orders. The component layout is available here.

NotAffectedOrdersGrp

This component is a repeating group that is used to reference the orders that have not been impacted by a mass action such as a mass cancellation, i.e. an exception list. It does not provide any further attributes of the orders. The component layout is available here.

Messages

Order Mass Cancel Requests

The OrderMassCancelRequest(35=q) message requests the cancelation of all of the remaining quantity of a group of orders matching criteria specified within the request. NOTE: This message can only be used to cancel order messages (reduce the full quantity).

An OrderMassCancelRequest(35=q) message is assigned a ClOrdID(11) and is treated as a separate entity. It is acknowledged using an OrderMassCancelReport(35=r) message. The OrderMassCancelReport(35=r) message will contain the ClOrdID(11) that was specified on the OrderMassCancelRequest(35=q) message. The ClOrdID(11) assigned to the request must be unique amongst the ClOrdID(11) assigned to new orders, replacement requests, cancel requests, and mass cancel requests.

To transmit a change in OrdStatus(39) for an order, the broker (sell side) should send an ExecutionReport(35=8) message with the new OrdStatus(39) value and an ExecType(150) value that reflects the event that caused the order status to change. It is recommended that an ExecutionReport(35=8) with ExecType(150) = 6 (Pending Cancel) be sent unless the OrderMassCancelRequest(35=q) message can be immediately accepted (ExecutionReport(35=8) with ExecType(150) = 4 (Canceled)) or rejected (OrderCancelReject(35=9) message).

Order cancellation criteria are specified using MassCancelRequestType(530), see FIXimate for details. The message layout is available here.

Order Mass Cancel Reports

The OrderMassCancelReport(35=r) message is used to acknowledge an OrderMassCancelRequest(35=q) message. Note that each affected order that is canceled is acknowledged with a separate ExecutionReport(35=8) or OrderCancelReject(9) message. The message layout is available here.

Order Mass Status Requests

The OrderMassStatusRequest(35=AF) message requests the status for orders matching criteria specified within the request.

A mass status request is assigned a ClOrdID(11) and is treated as a separate entity.

ExecutionReport(35=8) messages with ExecType(150) = I (Order Status) are returned for all orders matching the criteria provided on the request.

Order selection criteria are specified using MassStatusReqType(585), see FIXimate for details. Some of the criteria require the specification of another FIX field. Note that MassStatusReqType(585) = 8 (Status for orders for a PartyID) requires the use of TargetPartyID(1462) and not PartyID(448). The message layout is available here.

Order Mass Action Requests

The OrderMassActionRequest(35=CA) message can be used to request the suspension or release of a group of orders that match the criteria specified within the request. This is equivalent to individual OrderCancelReplaceRequest(35=G) messages for each order with or without adding “S” to the ExecInst(18) values. It can also be used for mass order cancellation.

An OrderMassActionRequest(35=CA) message is assigned a ClOrdID(11) and is treated as a separate entity. It is acknowledged using an OrderMassActionReport(35=BZ) message. The OrderMassActionReport(35=BZ) message will contain the ClOrdID(11) that was specified on the OrderMassActionRequest(35=CA) message. The ClOrdID(11) assigned to the suspension or release request must be unique amongst the ClOrdID(11) values assigned to new orders, replacement requests, cancel requests, etc.

To transmit a change in OrdStatus(39) for an order, the broker (sell side) should send an ExecutionReport(35=8) message with the new OrdStatus(39) value and an ExecType(150) value that reflects the event that caused the order status to change. It is recommended that an ExecutionReport(35=8) with ExecType(150) = E (Pending Replace) (or ExecType(150) = 6 (Pending Cancel) if used for mass cancellation) be sent unless the OrderMassActionRequest(35=CA) message can be immediately accepted (ExecutionReport(35=8) with ExecType(150) = 5 (Replaced) or ExecType(150) = 4 (Canceled)).

Specifying filtering criteria is done using the MassActionType(1373) field.

The message layout is available here.

Order Mass Action Reports

The OrderMassActionReport(BZ) message is used to acknowledge an OrderMassActionRequest(35=CA) message. Note that each affected order that is suspended or released or canceled is acknowledged with a separate ExecutionReport(35=8) message for each order. The message layout is available here.

Category – Cross Order Handling

Components

SideCrossOrdCxlGrp

This component is a repeating group that is used to identify one or both sides (orders) of the cross order that is to be cancelled. It requires to specify the client order identifier and quantity for each given side. The component layout is available here.

SideCrossOrdModGrp

This component is a repeating group that is used to define one or both sides (orders) of a new cross order or an existing one that is to be modified. It requires to specify the client order identifier and quantity for each given side. It provides the ability to provide allocation and commission information. The component layout is available here.

Messages

Background

FIX provides support for a cross order using Side(54) = 8 (Cross) on a NewOrderSingle(35=D) message. For many markets the NewOrderSingle(35=D) message does not provide enough information about the counterparties of a trade to meet regulatory and post-trade requirements. Markets that find the use of a NewOrderSingle(35=D) message with Side(54)=Cross adequate for cross trading – can continue to use this implementation. When additional information regarding the counterparty to the cross trade is required – the NewOrderCross(35=s) message should be used.

New Order – Cross

The NewOrderCross(35=s) message is used to submit a cross order into a market. The cross order contains two order sides (a buy and a sell). The cross order is identified by its CrossID(548). The message layout is available here.

Cross Order Cancel/Replace Requests

The CrossOrderCancelReplaceRequest(35=t) message (a.k.a. Cross Order Modification Request) is used to modify a cross order previously submitted using the NewOrderCross(35=s) message. See the OrderCancelReplaceRequest(35=G) message for details concerning message usage.

Refer to the OrderCancelReplaceRequest(35=G) (a.k.a. Order Modification Request) message for restrictions on what fields can be changed during a cancel/replace.

The cross order-specific fields, CrossType(549) and CrossPrioritization(550), cannot be modified using the CrossOrderCancelReplaceRequest(35=t) message. The message layout is available here.

Cross Order Cancel Requests

The CrossOrderCancelRequest(35=u) message is used to fully cancel the remaining open quantity of a cross order. The message layout is available here.

Category – Multileg Order Handling

A multileg security is made up of multiple securities that are traded atomically. Swaps, option strategies, futures spreads, are a few examples of multileg securities. The requirement that all legs be traded in the quantities that make up the multileg security is the important distinction between a multileg order and a list order.

Two generalized approaches to trading multileg securities are supported by FIX. The first approach involves a market maintaining multileg securities as separate products for which markets can be created. This “product approach” is often used in electronic trading systems. The second approach is to trade the multileg security as a group of separate securities – as is commonly done today in open outcry markets.

Components

LegOrdGrp

This component is a repeating group that is used on a multileg order and contains the full definition of the individual legs of a multi-legged instrument. This includes pre-allocation information as well as stipulations for each leg. The component layout is available here.

PreAllocMlegGrp

This component is a repeating group that is used on a multileg order to convey allocation information that has to be applied once the trade is completed. Note that this component applies to the entire multileg order and not to an individual leg (provided by LegOrdGrp). The component layout is available here.

Messages

New Order – Multileg

The NewOrderMultileg(35=AB) message is provided to submit orders for securities that are made up of multiple securities, known as legs. The message layout is available here.

Multileg Order Cancel Replace Requests (a.k.a. Multileg Order Modification Requests)

The MultilegOrderCancelReplace(35=AC) message is used to modify a multileg order previously submitted using the NewOrderMultileg(35=AB) message. See OrderCancelReplaceRequest(35=G) for details concerning message usage. The message layout is available here.

Category – List/Program/Basket Trading

The List/Program/Basket Trading message set is used for the trading of lists/programs/baskets of orders.

A subset of the List/Program/Basket Trading message set, NewOrderList(35=E) and ListStatus(35=N) message, is also used to support contingent orders. Contingent orders include “one-cancels-other”, “one-triggers-other”, and “one-updates-other”.

The messages used in program trading support fragmentation for the same reason and in the same way as some other FIX messages (e.g. MassQuote(35=i)). If there are too many entries within a repeating group to fit into one physical message, then the entries can be continued in another message by repeating all of the top level information and then specifying the number of entries in the continued message. A “Total Entries” field is provided to specify the total number of entries in a repeating group which is split over multiple messages. This permits, but does not require, a receiving application to react in a stateful manner where it can determine if it has received all entries in a repeating group before carrying out some action. However, the overall approach to fragmentation is to permit each message to be processed in a stateless manner as it is received. Each message should contain enough information to have the entries applied to a system without requiring the next message if fragmentation has occurred. Also, a continued message should not require any information from the previous message. The messages that support fragmentation and the repeating groups supporting it are listed in the table below.

Message“Total Entries” fieldRepeating group that may be fragmented
NewOrderList(35=E)TotNoOrders(68)Orders repeating group following NoOrders(73) in the message definition table
ListStrikePrice(35=m)TotNoStrikes(422)Strike price repeating group following NoStrikes(428) in the message definition table
ListStatus(35=N)TotNoOrders(68)Status per order repeating group following the NoOrders field in the message definition table

Maximum message size for fragmentation purposes can be determined by using the optional MaxMessageSize(383) field in the Logon(35=A) message or by mutual agreement between counterparties.

Note: The TotNoOrders(68) field has been added to the ListStatus(35=N) message to support fragmentation in the same way as other FIX messages. NoRpts(82) and RptSeq(83) are preserved for backwards compatibility with previous versions of FIX which supported a stateful form of fragmentation.

Components

BidCompReqGrp

This component is a repeating group that can be used when BidType(394) = 2 (Disclosed style, e.g. Japanese model) where the NewOrderList(35=E) message is sent before the bidding process is started, by telephone or electronically. It is used to define which NewOrderList(35=E) messages (identified by ListID(66)) a bid is being sought for and the directions of the required bids. The component layout is available here.

BidCompRspGrp

This component is a repeating group that can be used for both the disclosed and the non disclosed convention for program trading. It must contain commission information in its global CommissionData component and echoes individual attributes from either the BidCompReqGrp or BidDescReqGrp component. The component layout is available here.

BidDescReqGrp

This component is a repeating group that can be used when BidType(394) = 1 (Non Disclosed style, e.g. US/European model) where the NewOrderList(35=E) message is sent after the bidding process is started, by telephone or electronically. It supports the definition of liquidity information of a program trade. The component layout is available here.

InstrmtStrkPxGrp

This component is a repeating group that is used to convey one or more strike prices for principal trades. It requires the definition of an instrument for each strike price, optionally together with its underlying instruments. The component layout is available here.

ListOrdGrp

This component is a repeating group that is used to convey a list of orders for program trading. It is equivalent to the information available for an individual order as part of the NewOrderSingle(35=D) message. The component layout is available here.

OrdListStatGrp

This component is a repeating group that is used to provides references to the orders in a given list as well as key information such as the status of each order and its executed and remaining quantities. The component layout is available here.

Messages

Bid Requests

The BidRequest(35=k) message can be used in one of two ways depending on which market conventions are being followed.

In the “Non disclosed” convention (e.g. US/European model) the BidRequest(35=k) message can be used to request a bid based on the sector, country, index and liquidity information contained within the message itself. In the “Non disclosed” convention the entry repeating group is used to define liquidity of the program.

In the “Disclosed” convention (e.g. Japanese model) the BidRequest(35=k) message can be used to request bids based on the NewOrderList(35=E) messages sent in advance of BidRequest message. In the “Disclosed” convention the list repeating group is used to define which NewOrderList(35=E) messages a bid is being sought for and the directions of the required bids.

The pair of fields SideValue1(396) and SideValue2(397) are used to show the monetary total value in either direction (buy or sell) of the transaction without revealing whether it is the buy-side institution’s intention to buy or sell.

The two repeating groups, BidDescrReqGrp (with NoBidDescriptors(398)) and BidCompReqGrp (with NoBidComponents(420)) are mutually exclusive and a function of which bidding model is being used. If the “Non-Disclosure” method is being used the portfolio of stocks being traded is described by a number of “bid descriptors” entries. If the “Disclosure” method is being used the portfolio is fully disclosed, except for side, by a number of “list” entries enumerating the lists (with ListID(66)) that list the stocks to be traded.

A BidRequest(35=k) message with BidRequestTransType(374) = C (Cancel) may be used to indicate to sell side firms that they no longer need to store details of the bid request as they have either lost the bid or the list has been canceled. The message layout is available here.

Bid Responses

The BidResponse(35=l, lowercase “L”) message can be used in one of two ways depending on which market conventions are being followed.

In the “Non disclosed” convention the BidResponse(35=l) message can be used to supply a bid based on the sector, country, index and liquidity information contained within the corresponding BidRequest(35=k) message.

In the “Disclosed” convention the BidResponse(35=l) message can be used to supply bids based on the NewOrderList(35=E) messages sent in advance of the corresponding BidRequest(35=k) message. The message layout is available here.

New List Orders

The NewOrderList(35=E) message can be used in one of two ways depending on which market conventions are being followed.

In the “Non disclosed” convention the NewOrderList(35=E) message is sent after the bidding process has been completed, by telephone or electronically. The NewOrderList(35=E) message enumerates the stocks, quantities, direction for the trade and may contain pre-allocation information.

This message may also be used as the first message for the transmission of a program trade where the bidding process has been done by means other than FIX. In this scenario the messages may either be used as a staging process, in which case the broker will start execution once either a ListExecute(35=L) message is received or for immediate execution, in which case the orders will be executed on receipt.

In the “Disclosed” convention the NewOrderList(35=E) message is sent before the bidding process is started, by telephone or electronically. The NewOrderList(35=E) message enumerates the stocks and quantities from the bidding process, and may contain pre-allocation information. The direction of the trade is disclosed after the bidding process is completed.

Where multiple waves of a program trade are submitted by an institution or retail intermediaries, as a series of separate lists, to a broker ClOrdLinkID may be used to link the orders together.

The NewOrderList(35=E) message may also be used by institutions or retail intermediaries wishing to electronically submit multiple Collective Investment Vehicle orders to a broker or fund manager for execution. The message layout is available here.

List Strike Prices

The ListStrikePrice(35=m) message is used to exchange strike price information for principal trades. It can also be used to exchange reference prices for agency trades. The message layout is available here.

List Status

The ListStatus(35=N) message is issued as the response to a ListStatusRequest(35=M) message or sent in an unsolicited fashion by the sell-side. It indicates the current state of the orders within the list as they exist at the broker’s site. This message may also be used to respond to the ListCancelRequest(35=K) message.

Orders within the list are statused at the summary level. Individual executions are not reported, rather, the current state of the order is reported.

The message contains repeating fields for each order in the OrdListStatGrp component. The relative position of the repeating fields is important in this message, i.e. each instance of ClOrdID(11), CumQty(14), LeavesQty(151), CxlQty(84) and AvgPx(6) must be in the order defined for the fields in the OrdListStatGrp component.

Description of ListOrderStatus(431) values:

  • “In bidding process”: indicates that a list has been received and is being evaluated for pricing. It is envisaged that this status will only be used with the “Disclosed” List Order Trading model.
  • “Received for execution”: indicates that a list has been received and the sell side is awaiting the instruction to start working the trade. It is envisaged that this status will be used under both models.
  • “Executing”: indicates that a list has been received and the sell side is working it.
  • “Canceling”: indicates that a ListCancelRequest(35=K) Message has been received and the sell side is in the process of pulling any orders that were being worked. The status of individual orders can be found out from the details in the repeating group OrdListStatGrp.
  • “All Done”: indicates that a list has been executed as far as possible for the day. This would also apply if a list has been previously cancelled. The status of individual orders can be determined from the details in the repeating group OrdListStatGrp.
  • “Alert”: used whenever any of the individual orders have a status that requires something to be done. For instance, an alert would be used when a buy-side firm has submitted a list that has individual stock rejects that have not been addressed.
  • “Rejected” used when a response cannot be generated. For example when the ListID(66) is not recognized. Text(58) should include an explanation of why the request has been rejected.

The message layout is available here.

List Execute

The ListExecute(35=L) message is used by institutions to instruct the broker to begin execution of a previously submitted list. This message may or may not be used, as it may be mirroring a phone conversation. The message layout is available here.

List Cancel Request

The ListCancelRequest(35=K) message is used by institutions wishing to cancel previously submitted lists either before or during execution.

After the list has been staged with the broker, it can be canceled via the submission of the ListCancelRequest(35=K) message. If the list has not yet been submitted for execution, the ListCancelRequest(35=K) message will instruct the broker not to execute it, if the list is being executed, the ListCancelRequest(35=K) message should trigger the broker’s system to generate cancel requests for the remaining quantities of each order within the list. Individual orders within the list can be canceled via the OrderCancelRequest(35=F) message.

The ListStatus(35=N) message is used by the recipient of the ListCancelRequest(35=K) message to communicate the status of the ListCancelRequest(35=K) message. The message layout is available here.

List Status Request

The ListStatusRequest(35=M) message is used by institutions to instruct the broker to generate status messages for a list of orders. The message layout is available here.