Execution Report <8> message – FIX 4.1 – FIX Dictionary

Structure | Related Messages

Description

The Execution Report <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. reject orders
6. report post-trade fees calculations associated with a trade

NOTE: Execution reports do not replace the end-of-day confirm. Execution reports are to be regarded only as replacements for the existing fill messages currently communicated via telephone.

Each execution message will contain information that will describe the current state of the order and execution status as understood by the broker. State changes should be sent as separate messages and should not be used to also convey new partial fill details (i.e. do not report a partial fill or filled in a Done for the Day, Reject, etc.)

Execution report messages can be transmitted as transaction types (ExecTransType <20>) NEW, CANCEL, CORRECT or STATUS. Transaction types CANCEL and CORRECT modify the state of the message identified in field ExecRefID <19>. Transaction type STATUS indicates that the execution message contains no new information, only summary information regarding order status.

• The NEW transaction type indicates that this message represents a new order, a change in status of the order, or a new fill against an existing order. The combination of the ExecTransType <20> and OrdStatus <39> fields will indicate how the message is to be applied to an order.
• The CANCEL transaction type applies at the execution level. The Cancel transaction will be used to cancel an execution which has been reported in error. The canceled execution will be identified in the ExecRefID <19> field.
• The CORRECT transaction type applies at the execution level and is used to modify an incorrectly reported fill. The incorrect execution will be identified in the ExecRefID <19> field. If a single execution is corrected more than once, ExecRefID <19> should refer to the ExecID <17> of the last corrected ExecutionRpt (same convention as ClOrdID <11> and OrigClOrdID <41>). Note: Data reported in the CumQty <14>, LeavesQty <151>, and AvgPx <6> fields represent the status of the order as of the time of the correction, not as of the time of the originally reported execution.

Any fills which occur and need to be communicated to the customer while an order is "pending" and waiting to achieve a new state (i.e. via a Order Cancel/Replace(aka Order Modification) Request <G>) must contain the "original" (current order prior to state change request) order parameters (i.e. ClOrdID <11>, OrderQty <38>, LeavesQty <151>, Price <44>, etc). An order cannot be considered replaced until it has been explicitly accepted and confirmed to have reached the replaced status (i.e OrdStatus <39> = "Replaced")--Care should be taken as the replaced order could still have reports coming which will update the CumQty <14> and AvgPx <6> of both the original and replacement, however, the effect on the replacement (ClOrdID <11>, new quantity or limit price, etc.) will not be seen until a report on the replacement has been generated.

The ExecType <150> field describes the specific ExecutionRpt while OrdStatus <39> will always identify the current order status.

See Appendix D: Order State Change Matrices.

To transmit a change in OrdStatus <39> for an order, the broker(sell side) should send an Execution Report <8> with the new OrdStatus <39> value in ExecType <150> AND OrdStatus <39> to signify this message is changing the state of the order. The only exception to this rule is when sending a Cancel Reject <9> in response to a Cancel <F> or Replace <G> request, the Cancel Reject <9> message is used. Furthermore, partial/complete fill information should be sent in a separate Execution Report <8> than order accept(New), cancel accept(Canceled), cancel/replace accept(Replaced) or Done For Day reports.

The OrdStatus <39> field is used to identify the status of the current order. If an order simultaneously exists in more than one order state, the value with highest precedence is the value that is reported in the OrdStatus <39> field. The order statuses are as follows:

NOTE: The canceled and replaced order status is set in response to accepted cancel and replace requests. These requests are only acted upon when there is an outstanding order quantity. Requests to replace OrderQty <38> to a level less than the CumQty <14> will be rejected. Requests to change price on a filled order will be rejected (see Order Cancel Reject <9> message type).

The OrderQty <38>, CumQty <14>, LeavesQty <151>, and AvgPx <6> fields 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, the 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 <39> are Canceled, DoneForTheDay, Expired, Calculated, or Rejected in which case the order is no longer active and LeavesQty <151> could be 0.

The field ClOrdID <11> is provided for institutions to affix an identification number to an order to coincide with internal systems. The OrderID <37> field is populated with the broker-generated order number. Unlike ClOrdID <11>/OrigClOrdID <41> which requires a chaining through Cancel/Replaces and Cancels, OrderID <37> and SecondaryOrderID <198> are not required to change through changes to an order.

Structure

Related Messages

• Reject <3>

• Order Cancel Reject <9>