Business Area: Trade
As of EP284, November 2023
FIX Global Technical Committee
Table of Contents
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:
- SINGLE/GENERAL ORDER HANDLING
- ORDER MASS HANDLING
- CROSS ORDER HANDLING
- MULTILEG ORDER HANDLING
- LIST/PROGRAM/BASKET TRADING
Descriptions of the specific FIX 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. The detailed layout of all messages and components is provided in the appendix.
List of Messages and Components for Trade
Messages
This section lists the trade messages and the category each of them belongs to.
Components
This section lists components used by trade messages defined in this part of the FIX specification. Some of these are Common Components used by more than one category in this area. Messages may also reference Global Components, which are components used by messages across more than one area. Global Components are defined in the overall Introduction to the FIX specification.
Components can be either non-repeating or repeating (a.k.a. a “group”), i.e. contain multiple instances of a set of fields. Components can be nested to any level.
Category – Single/General Order Handling
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:
- confirm the receipt of an order
- confirm changes to an existing order (i.e. accept cancel and replace requests)
- relay order status information
- relay fill information on working orders
- relay fill information on tradeable or restricted tradeable quotes
- reject orders
- report post-trade fees calculations associated with a trade
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.
NOTE: The TradingSessionID(336) and TradingSessionSubID(625) fields are on the root level of the ExecutionReport(35=8) message and identify the active trading (sub)session in which the event of the report occurred. They are not used to echo the order attributes given with the TrdgSesGrp component in the order handling messages where it contains one or more (sub)sessions for which the order is valid, and it is not part of the ExecutionReport(35=8) 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):
| Precedence | OrdStatus | Description |
|---|---|---|
| 11 | Pending Cancel | Order with a pending cancel request, used to confirm receipt of an OrderCancelRequest(35=F) message. DOES NOT INDICATE THAT THE ORDER HAS BEEN CANCELED. |
| 10 | Pending Replace | Order with a pending replacement request, used to confirm receipt of an OrderCancelReplaceRequest(35=G) message. DOES NOT INDICATE THAT THE ORDER HAS BEEN REPLACED. |
| 9 | Done for Day | Order not, or partially, filled; no further executions forthcoming for the trading day |
| 8 | Calculated | Order 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 |
| 7 | Filled | Order completely filled, no remaining quantity |
| 6 | Stopped | Order has been stopped at the exchange. Used when guaranteeing or protecting a price and quantity |
| 5 | Suspended | Order has been placed in suspended state at the request of the client. |
| 4 | Canceled | Canceled order with or without executions |
| 4 | Expired | Order 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. |
| 3 | Partially Filled | Outstanding order with executions and remaining quantity |
| 2 | New | Outstanding order with no executions |
| 2 | Rejected | Order 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. |
| 2 | Pending New | Order 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 an OrderStatusRequest(35=H) message. |
| 1 | Accepted for bidding | Order 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) (a.k.a. “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) may 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 may be used to notify the broker of a potential problem order.
The decision to “DK an execution” lies with the party receiving the execution message. 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. The OrderCancelReplaceRequest(35=G) message may 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 may be used to re-open a filled order by increasing OrderQty(38).
Do not use this message to cancel the remaining quantity of an outstanding order, use the OrderCancelRequest(35=F) message for this purpose.
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 is the response to accept 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.
Components
ContraGrp
This component is a repeating group that is part of the ExecutionReport(35=8) message to convey one or more contra brokers as counterparties to a trade. It supports the identification of the contra 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. It is used to convey one or more partial executions of a single match event resulting in multiple executions and reported in a single ExecutionReport(35=8) message. 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. In addition to a number of individual execution specific 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 conceptually identical to the 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 and conceptually identical to the PtysSubGrp component. 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.
OrderEventGrp
This component is a repeating group that may be used to convey a list of different types of events affecting orders. These can include entry, modification and deletion of orders as well as executions (fills). Modifications can be solicited or unsolicited, e.g. triggering of stop orders, replenishment of reserve orders, orders being suspended (locked) or released from suspension. The component layout is available here.
Category – Order Mass Handling
Messages
Mass Orders
The MassOrder(35=DJ) message is used to add, modify or delete multiple unrelated orders using a single message. Apart from clearing related attributes, only the key order attributes for high performance trading are available.
The behavior of individual orders within a MassOrder(35=DJ) message may vary depending upon its attributes, e.g. OrdType(40) and TimeInForce(59). Individual orders may be modified or deleted/cancelled with OrderCancelReplaceRequest(35=G) and OrderCancelRequest(35=F) messages. Each of the orders in the MassOrder(35=DJ) message are to be treated as stand-alone individual orders.
The message layout is available here.
Mass Order Acknowledgements
The MassOrderAck(35=DK) message is used to acknowledge the receipt of and the status for a MassOrder(35=DJ) message. The content of the acknowledgement depends on the setting of OrderResponseLevel(2427) in the MassOrder(35=DJ) message.
Only the order status is provided and not the immediate executions, which are communicated using ExecutionReport(35=8) messages instead. The message layout is available here.
Order Mass Cancel Requests
The OrderMassCancelRequest(35=q) message is used to request the cancellation of all of the remaining quantity of a group of orders matching criteria specified within the request using MassCancelRequestType(530). Some of the criteria require the specification of another FIX field. This message can only be used to cancel orders.
An OrderMassCancelRequest(35=q) message is assigned its own unique ClOrdID(11) and is treated as a separate entity. It is acknowledged using an OrderMassCancelReport(35=r) message, referencing the ClOrdID(11) that was specified on the OrderMassCancelRequest(35=q) 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. It is recommended that an ExecutionReport(35=8) with ExecType(150) = 6 (Pending Cancel) be sent for each affected order unless the OrderMassCancelRequest(35=q) message can be immediately accepted (ExecutionReport(35=8) with ExecType(150) = 4 (Canceled) for each affected order) or rejected (OrderCancelReject(35=9) message for each affected order).
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 using MassStatusReqType(585). Some of the criteria require the specification of another FIX field. The request is assigned its own unique 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.
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 is 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 its own unique 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.
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 for each affected order unless the OrderMassActionRequest(35=CA) message can be immediately accepted (ExecutionReport(35=8) with ExecType(150) = 5 (Replaced) or ExecType(150) = 4 (Canceled) for each affected order) or rejected (OrderCancelReject(35=9) message for each affected order).
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.
Components
AffectedMarketSegmentGrp
This component is a repeating group that is used to reference the market segment(s) that have been impacted by a mass action such as a mass cancellation. The component layout is available here.
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.
NotAffectedMarketSegmentGrp
This component is a repeating group that is used to reference the market segment(s) that have not been impacted by a mass action such as a mass cancellation. The component layout is available here.
NotAffectedOrdGrp
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.
OrderEntryGrp
This component is a repeating group of orders subject to the individual actions defined by OrderEntryAction(2429). The component layout is available here.
OrderEntryAckGrp
This component is a repeating group to acknowledge a group of orders subject to the individual actions defined by OrderEntryAction(2429). The acknowledgement may or may not echo back input values from the submission but it has to provide the current status of each order including the impact of immediate executions or suspensions. The component layout is available here.
TargetMarketSegmentGrp
This component is a repeating group that may be used to identify one or more market segments upon which an action is to be taken. The component layout is available here.
Category – Cross Order Handling
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. 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.
Components
SideCrossLegGrp
This component is a repeating group that is similar to the LegOrdGrp component in order to support leg level information per side of cross orders and is part of the SideCrossOrdModGrp component. The LegOrdGrp component cannot be re-used for this purpose as it contains the InstrumentLeg and NestedParties components that are already part of the cross messages. The difference to the LegOrdGrp component is that the SideCrossLegGrp component does not have an InstrumentLeg component to describe the legs, it only has a single reference field to identify the leg. This leg can be defined by the InstrumentLeg component that is present on a higher level of the message and outside of the side level. The component layout is available here.
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.
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.
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
The MultilegOrderCancelReplace(35=AC) message (a.k.a. Multileg Order Modification Request) 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.
Components
PreAllocMlegGrp
This component is a repeating group that is used on a multileg order to convey pre-allocation information that is 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) unless AllocLegRefID(2727) is used. The component 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” field | Repeating 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.
Messages
Bid Requests
The BidRequest(35=k) message may 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 may 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 may 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 may 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 may 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 may 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 may 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(583) 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 (CIV) 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.
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 submitted to the recipient, 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 recipient not to execute it and cancel the entire list. If the list is being executed, the ListCancelRequest(35=K) message should trigger the recipient’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.
Components
BidCompReqGrp
This component is a repeating group that may 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 may be used for both the disclosed and the non disclosed convention for program trading. It must contain commission information in its 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 may 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 list/program/basket trading. It is similar 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 along with key information such as the status of each order, its executed and remaining quantities, and prices. The component layout is available here.
Common Components
Common components are components that are used within a single business area but across two or more categories. Common components are global if they are used across two or more business areas and are described in the overall Introduction of the normative specification of the application layer.
DisclosureInstructionGrp
This component is a repeating group of instructions, each of which relates to one or more elements of an order. The instruction itself conveys whether the information should be disclosed or not, e.g. in market data, or not. The component layout is available here.
DiscretionInstructions
This 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.
PegInstructions
This 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 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 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 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.
