The Execution Report 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 the post-trade fee calculations associated with a trade Execution Reports do not replace end-of-day confirmations. Separate Execution Reports are sent for each order in a [New Order List <35=E>](msg:E). An Execution Report communicates the current state of the order as understood by the broker, using [OrdStatus (39)](tag:39), and the purpose of the message, using [ExecType (150)](tag:150). In an Execution Report, [OrdStatus (39)](tag: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 used in the [OrdStatus (39)](tag:39) field. The order statuses are as follows, from highest to lowest precedence:

Precedence	OrdStatus	Description
11	Pending Cancel	Order with an Order Cancel Request pending, used to confirm receipt of an Order Cancel Request. Does not indicate that the order has been canceled.
10	Pending Replace	Order with an Order Cancel/Replace Request pending, used to confirm receipt of an Order Cancel/Replace Request. Does not indicate that the order has been replaced.
9	Done for Day	Order not filled, or partially filled; no further executions possible 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 time-in-force instructions. The only exceptions are fill-or-kill and immediate-or-cancel orders that have Canceled as their 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 the sell-side. 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 the sell-side's system but not yet accepted for execution. An execution message with this status will only be sent in response to a Status Request 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 “Disclosed” BidType List Order Trading model

[ExecType (150)](tag:150) is used to identify the purpose of the Execution Report. To transmit a change in [OrdStatus (39)](tag:39) for an order, the broker (sell-side) should send an Execution Report with the new [OrdStatus (39)](tag:39) value in both the [ExecType (150)](tag:150) and the [OrdStatus (39)](tag:39) fields to signify this message is changing the state of the order. The only exception to this rule is that when rejecting a cancel or cancel/replace request, the [Order Cancel Reject <35=9>](msg:9) message is used both to reject the request and to communicate the current [OrdStatus (39)](tag:39). An [ExecType (150)](tag:150) of Pending Cancel or Pending Replace is used to indicate that a cancel or cancel/replace request is being processed. An [ExecType (150)](tag:150) of Canceled or Replace 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 while an order is pending and waiting to reach a new state must contain the original order parameters, prior to state change request, i.e. [ClOrdID (11)](tag:11), [OrderQty (38)](tag:38), [Price (44)](tag:44), etc. These fills will cause the [CumQty (14)](tag:14) and [AvgPx (6)](tag:6) to be updated. An order cannot be considered replaced until it has been explicitly accepted and confirmed to have been replaced via an Execution Report with [ExecType (150)](tag:150) = 'Replace', at which time the effect of the replacement (new quantity, price, etc.) will be seen. Requests to cancel or cancel/replace an order are only acted upon when there is an outstanding order quantity. A request to replace the [OrderQty (38)](tag:38) to a level lower than the [CumQty (14)](tag:14) will be interpreted by the broker as a request to stop executing the order. A request to change the price of a filled order will be rejected. The [OrderQty (38)](tag:38), [CumQty (14)](tag:14), [LeavesQty (151)](tag:151), and [AvgPx (6)](tag: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)](tag:38), [CumQty (14)](tag:14), [LeavesQty (151)](tag:151), and [AvgPx (6)](tag: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)](tag:38) = [CumQty (14)](tag:14) + [LeavesQty (151)](tag:151). There can be exceptions to this rule when [ExecType (150)](tag:150) or [OrdStatus (39)](tag:39) are Canceled, DoneForDay, Expired, Calculated, or Rejected. In which case, the order is no longer active and [LeavesQty (151)](tag:151) could be 0. Execution Reports communicate new fills with [ExecType (150)](tag:150) = Trade. Execution Reports with [ExecType (150)](tag:150) = Trade Cancel or Trade Correct are used to cancel or correct a previously modified execution report as follows: - The [ExecType (150)](tag:150) of 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 the [ExecRefID (19)](tag:19) field. Note: [ExecType (150)](tag:150) of Trade Cancel should not be used to cancel a previous Execution Report with [ExecType (150)](tag:150) of Trade Cancel (e.g. cannot cancel a cancel). - The [ExecType (150)](tag:150) of Trade Correct applies at the execution level and is used to modify an incorrectly reported fill. The incorrect execution will be identified in the [ExecRefID (19)](tag:19) field. If a single execution is corrected more than once, [ExecRefID (19)](tag:19) should refer to the [ExecID (17)](tag:17) of the last corrected Execution Report (same convention as [ClOrdID (11)](tag:11) and [OrigClOrdID (41)](tag:41)). To correct an Execution Report which was previously canceled, an Execution Report with [ExecType (150)](tag:150)=Trade should be sent (e.g. cannot send [ExecType (150)](tag:150)=Trade Correct for an Execution Report with [ExecType (150)](tag:150)=Trade Cancel). Note: Data reported in the [CumQty (14)](tag:14), [LeavesQty (151)](tag:151), and [AvgPx (6)](tag: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. An [ExecType (150)](tag:150) of Order Status indicates that the execution messages contains no new information, only summary information regarding order status. It is used, for example, in response to an Order Status request message See "Order State Change Matrices" for examples of key state changes, processing of cancel and cancel/replace requests, and for execution cancel/corrects. An Execution Report with [ExecType (150)](tag:150) = Restated represents an Execution Report sent by the sellside communicating a change in the order or a restatement of the order's parameters without an electronic request from the customer. [ExecRestatementReason (378)](tag:378) must be set. This is used for GT orders and corporate actions (see below), changes communicated verbally to the sellside either due to normal business practices or as an emergency measure when electronic systems are not available, repricing of orders by the sellside (such as making Sell Short orders compliant with uptick / downtick rules), or other reasons (Broker option). [ExecRestatementReason (378)](tag:378) can also be used to communicate unsolicited cancels. The field [ClOrdID (11)](tag:11) is provided for institutions or buy-side brokers or intermediaries to affix an identification number to an order to coincide with internal systems. The [OrderID (37)](tag:37) field is populated with the sell-side broker-generated order number (or fund manager-generated order number for CIVs). Unlike [ClOrdID (11)](tag:11) / [OrigClOrdID (41)](tag:41) which requires a chaining through Cancel/Replaces and Cancels, [OrderID (37)](tag:37) and [SecondaryOrderID (198)](tag: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 GTC and Good Till Date 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 Execution Report with [ExecType (150)](tag:150)='3' (Done for Day). When the [ExpireDate (432)](tag:432) or [ExpireTime (126)](tag:126) of a Good Till Date order is reached, or a GTC order reaches a maximum age, the order is considered expired and the broker may optionally send an Execution Report with [ExecType (150)](tag:150) and [OrdStatus (39)](tag:39)=Expired (C). In handling GT orders, the [OrderQty (38)](tag:38), [CumQty (14)](tag:14) and [AvgPx (6)](tag:6) fields will represent the entirety of the order over all days. The fields [DayOrderQty (424)](tag:424), [DayCumQty (425)](tag:425), and [DayAvgPx (426)](tag: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)](tag:425) and [DayAvgPx (426)](tag:426) are set to zero, and [DayOrderQty (424)](tag:424) becomes the [LeavesQty (151)](tag:151). The following relationship holds: [DayOrderQty (424)](tag:424) = [OrderQty (38)](tag:38) - ([CumQty (14)](tag:14) - [DayCumQty (425)](tag:425)). Since ([CumQty (14)](tag:14) - [DayCumQty (425)](tag:425)) represents the volume traded on all previous days, [DayOrderQty (424)](tag:424) = [OrderQty (38)](tag:38) - Volume traded on all previous days. Note that when changing the quantity of an order, both [OrderQty (38)](tag:38) and [DayOrderQty (424)](tag: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)](tag:38)=10000 and 2000 shares trade during the previous days, a request to change [OrderQty (38)](tag:38) to 15000 will mean that 13000 shares will be open. See "Order State Change Matrices" for examples of canceling and changing GT orders partially filled on previous days. A Cancel on an execution (trade bust, [ExecType (150)](tag:150) = Trade Cancel) happening the same day of the trade will result in [CumQty (14)](tag:14) and [DayCumQty (425)](tag:425) each decreasing by the quantity busted, and [LeavesQty (151)](tag:151) increasing by the quantity busted. [OrderQty (38)](tag:38) and [DayOrderQty (424)](tag: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)](tag:38) and [DayCumQty (425)](tag:425) will remain unchanged, the [LeavesQty (151)](tag:151) and [DayOrderQty (424)](tag:424) will increase by the quantity busted, and the [CumQty (14)](tag: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 DK message. Assuming no corporate actions have occurred, the broker will send an Execution Report with [ExecType (150)](tag:150) = Restated (D) and [ExecRestatementReason (378)](tag:378) = GT renewal / restatement (no corporate action) (1) for each open GT order. These Execution Reports may have [DayCumQty (425)](tag:425) and [DayAvgPx (426)](tag:426) restated to zero, and [DayOrderQty (424)](tag:424) restated to [LeavesQty (151)](tag:151) if the transmission occurs at the start of the following business day. The broker has the option of changing the [OrderID (37)](tag:37) and [SecondaryOrderID (198)](tag:198) fields, or leaving them unchanged. If they are changed, then the buy-side should use these new ID fields when sending [Order Cancel Request <35=F>](msg:F), [Order Cancel/Replace Request <35=G>](msg:G), and [Order Status Request <35=H>](msg:H) messages. In the case of a corporate action resulting in the adjustment of an open GT order, the broker will send an Execution Report with [ExecType (150)](tag:150) = Restated (D) and [ExecRestatementReason (378)](tag:378) = GT Corporate action (0) with the order's state after the corporate action adjustment. In the case of stock splits, [OrderQty (38)](tag:38), [CumQty (14)](tag:14), [AvgPx (6)](tag:6), and [LeavesQty (151)](tag: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 "Order State Change Matrices" for examples of GT order restatement with and without a corporate action. CIV orders to be executed by the fund manager do not use the [TimeInForce (59)](tag:59) field and only a subset of [OrdStatus (39)](tag:39) values are expected to be used. See VOLUME 7 - "PRODUCT: COLLECTIVE INVESTMENT VEHICLES" for the CIV-specific [OrdStatus (39)](tag:39) values. The Execution Report message is also used for multileg instrument. See "Use of the Execution Report for Multileg Instruments" for multileg-specific details.