FIX 4.2 : Execution Report <8> message

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 report contains three fields which are used to communicate both the current state of the order as understood by the broker and the purpose of the message: OrdStatus <39>, ExecType <150> and ExecTransType <20>.

In an execution report the 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 the OrdStatus <39> field. The order statuses are as follows (in highest to lowest precedence):

Precedence OrdStatus Description
12 Pending Cancel Order with an Order Cancel Request pending, used to confirm receipt of an Order Cancel Request <F>. DOES NOT INDICATE THAT THE ORDER HAS BEEN CANCELED.
11 Pending Replace Order with an Order Cancel/Replace Request pending, used to confirm receipt of an Order Cancel/Replace Request <G>. DOES NOT INDICATE THAT THE ORDER HAS BEEN REPLACED.
10 Done for Day Order not, or partially, filled; no further executions forthcoming for the trading day
9 Calculated Order has been completed for the day (either filled or done for day). Commission <12> or currency settlement details have been calculated and reported in this execution message
8 Filled Order completely filled, no remaining quantity
7 Stopped Order has been stopped at the exchange. Used when guranteeing or protecting a price and quantity
6 Suspended Order has been placed in suspended state at the request of the client
5 Canceled Canceled order with or without executions
5 Expired Order has been canceled in broker's system due to time in force instructions.
4 Partially Filled Outstanding order with executions and remaining quantity
3 Replaced Replaced order with or without executions
2 New Outstanding order with no executions
2 Rejected Order has been rejected by broker. 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 brokers system but not yet accepted for execution. An execution message with this status will only be sent in response to a Status Request <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 "Disclosed" BidType <394> List Order Trading model.

The ExecType <150> is used to identify the purpose of the Execution Report <8> message. 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 both the ExecType <150> AND the OrdStatus <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 Cancel Reject <9> message is used both to reject the request and to communicate the current OrdStatus <39>. An ExecType <150> of Pending Cancel or Pending Replace is used to indicate that a cancel or cancel/replace request is being processed. An ExecType <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 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) 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 the 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 execution report with ExecType <150> = 'Replace', at which time the effect of the replacement (ClOrdID <11>, new quantity or limit price etc) will be seen. Note that due to the precedence rules above, in reports where ExecType <150>=Replace, OrdStatus <39> may not = Replaced.

Requests to cancel or cancel/replace an order are only acted upon when there is an outstanding order quantity. Requests to replace the OrderQty <38> to a level less than the 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 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 (e.g. on a day order), Expired, Calculated, or Rejected in which case the order is no longer active and LeavesQty <151> could be 0.

Execution report messages are transmitted with a transaction type (ExecTransType <20>) NEW, CANCEL, CORRECT or STATUS. Transaction types CANCEL and CORRECT modify the state of the message identified in field ExecRefID <19>, and are used to cancel or correct a previously reported execution. 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>, ExecType <150>, 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. Note: ExecTransType <20> of Cancel should not be used to cancel a previous ExecutionRpt with ExecTransType <20> of Cancel (e.g. cannot cancel a cancel).
  • 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>). To correct an ExecutionRpt which was previously canceled, an ExecutionRpt with ExecTransType <20>=New should be sent (e.g. cannot send ExecTransType <20>=Correct for an ExecutionRpt with ExecTransType <20>=Cancel). 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.

See Appendix D: Order State Change Matrices for examples of key state changes, processing of cancel and cancel/replace requests, and for execution cancel/corrects.

An ExecutionRpt with ExecType <150> = Restated represents an ExecutionRpt 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> 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> can also be used to communicate unsolicited cancels.

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.

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 <8> with ExecType <150> ='3' (Done for Day). When the ExpireDate <432> or ExpireTime <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 <8> with ExecType <150> and OrdStatus <39> ='C' (Expired).

In handling GT orders, the OrderQty <38>, CumQty <14> and AvgPx <6> fields will represent the entirety of the order over all days. The fields 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 <424> = 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 Appendix D: Order State Change Matrices for examples of canceling and changing GT orders partially filled on previous days.

A Cancel on an execution (trade bust) 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 <425> 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 DK message. Assuming no corporate actions have occurred, the broker will send an Execution Report <8> with ExecType <150> ='D' (Restated) and ExecRestatementReason <378> = GT renewal / restatement (no corporate action) (1) for each open GT order. These Execution Reports 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 the OrderID <37> and SecondaryOrderID <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 <F>, Order Cancel/Replace Request <G>, and Order Status Request <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 <8> with ExecType <150> = Restated (D) and ExecRestatementReason <378> = GT Corporate action (0) 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 shares, not pre-split shares. See Appendix D: Order State Change Matrices for examples of GT order restatement with and without a corporate action.

Structure

Tag Field Name Req'd Comments
<MessageHeader> Y MsgType <35> = 8
37 OrderID Y

OrderID <37> is required to be unique for each chain of orders.

198 SecondaryOrderID N

Can be used to provide order id used by exchange or executing system.

11 ClOrdID N

Required for executions against electronically submitted orders which were assigned an ID by the institution. Not required for orders manually entered by the broker.

41 OrigClOrdID N

Conditionally required for response to an electronic Cancel or Cancel/Replace request (ExecType <150>=PendingCancel, Replaced, or Canceled). ClOrdID <11> of the previous order (NOT the initial order of the day) when canceling or replacing an order.

109 ClientID N

Used for firm identification in third-party transactions (should not be a substitute for OnBehalfOfCompID <115>/DeliverToCompID <128>).

76 ExecBroker N

Used for firm identification in third-party transactions (should not be a substitute for OnBehalfOfCompID <115>/DeliverToCompID <128>).

382 NoContraBrokers N

Number of ContraBrokers repeating group instances.

=> 375 ContraBroker N

First field in repeating group. Required if NoContraBrokers <382> > 0.

=> 337 ContraTrader N
=> 437 ContraTradeQty N
=> 438 ContraTradeTime N
66 ListID N

Required for executions against orders which were submitted as part of a list.

17 ExecID Y

Must be unique for each Execution Report <8> message

20 ExecTransType Y
19 ExecRefID N

Required for Cancel and Correct ExecTransType <20> messages

150 ExecType Y

Describes the type of execution report. Same possible values as OrdStatus <39>.

39 OrdStatus Y

Describes the current state of a CHAIN of orders, same scope as OrderQty <38>, CumQty <14>, LeavesQty <151>, and AvgPx <6>

103 OrdRejReason N

For optional use with ExecType <150> ='8' (Rejected)

378 ExecRestatementReason N

Required for ExecType <150> ='D' (Restated).

1 Account N

Required for executions against electronically submitted orders which were assigned an account by the institution

63 SettlmntTyp N

Absence of this field is interpreted as Regular.

64 FutSettDate N

Required when SettlmntTyp <63> ='6' (Future) or SettlmntTyp <63> ='8' (Sellers Option)

55 Symbol Y
65 SymbolSfx N
48 SecurityID N
22 IDSource N
167 SecurityType N

Must be specified if a Future or Option. If a Future: Symbol <55>, SecurityType <167>, and MaturityMonthYear <200> are required. If an Option: Symbol <55>, SecurityType <167>, MaturityMonthYear <200>, PutOrCall <201>, and StrikePrice <202> are required.

200 MaturityMonthYear N

Specifiesthe month and year of maturity. Required if MaturityDay <205> is specified.

205 MaturityDay N

Can be used in conjunction with MaturityMonthYear <200> to specify a particular maturity date.

201 PutOrCall N

For Options.

202 StrikePrice N

For Options.

206 OptAttribute N

For Options.

231 ContractMultiplier N

For Fixed Income, Convertible Bonds, Derivatives, etc. Note: If used, quantities should be expressed in the "nominal" (e.g. contracts vs. shares) amount.

223 CouponRate N

For Fixed Income.

207 SecurityExchange N

Can be used to identify the security.

106 Issuer N
348 EncodedIssuerLen N

Must be set if EncodedIssuer <349> field is specified and must immediately precede it.

349 EncodedIssuer N

Encoded (non-ASCII characters) representation of the Issuer <106> field in the encoded format specified via the MessageEncoding <347> field.

107 SecurityDesc N
350 EncodedSecurityDescLen N

Must be set if EncodedSecurityDesc <351> field is specified and must immediately precede it.

351 EncodedSecurityDesc N

Encoded (non-ASCII characters) representation of the SecurityDesc <107> field in the encoded format specified via the MessageEncoding <347> field.

54 Side Y
38 OrderQty N

Either CashOrderQty <152> or OrderQty <38> is required. Not required for a rejected cash order or an order ack for a cash order.

152 CashOrderQty N

Either CashOrderQty <152> or OrderQty <38> is required. Specifies the approximate 'monetary quantity' conveyed on the order. Broker is responsible for converting and calculating OrderQty <38> in shares for subsequent messages involving fills.

40 OrdType N
44 Price N

Required if specified on the order

99 StopPx N

Required if specified on the order

211 PegDifference N

Required if specified on the order

388 DiscretionInst N

Code to identify the price a DiscretionOffset <389> is related to and should be mathematically added to. Required if DiscretionOffset <389> is specified.

389 DiscretionOffset N

Amount (signed) added to the 'related to' price specified via DiscretionInst <388>.

15 Currency N
376 ComplianceID N
377 SolicitedFlag N
59 TimeInForce N

Absence of this field indicates Day order

168 EffectiveTime N

Time specified on the order at which the order should be considered valid

432 ExpireDate N

Conditionally required if TimeInForce <59> = GTD and ExpireTime <126> is not specified.

126 ExpireTime N

Conditionally required if TimeInForce <59> = GTD and ExpireDate <432> is not specified.

18 ExecInst N

Can contain multiple instructions, space delimited.

47 Rule80A(aka OrderCapacity) N
32 LastShares N

Quantity of shares bought/sold on this (last) fill. Not required ExecTransType <20> ='3' (Status). When required, should be "0" for non-fills ("fill" defined as ExecTransType <20>=New and ExecType <150>=Partial Fill or Fill) unless noted below.

If ExecType <150>=Stopped, represents the quantity stopped/guaranteed/protected for.

31 LastPx N

Price of this (last) fill. Not required for ExecTransType <20> ='3' (Status), Should represent the 'all-in' (LastSpotRate <194> + LastForwardPoints <195>) rate for F/X orders. ). When required, should be "0" for non-fills ("fill" defined as ExecTransType <20>=New and ExecType <150>=Partial Fill or Fill) unless noted below.

If ExecType <150>=Stopped, represents the price stopped/guaranteed/protected at.

194 LastSpotRate N

Applicable for F/X orders

195 LastForwardPoints N

Applicable for F/X orders

30 LastMkt N
336 TradingSessionID N
29 LastCapacity N
151 LeavesQty Y

Amount of shares open for further execution. If the OrdStatus <39> is Canceled, DoneForTheDay, Expired, Calculated, or Rejected (in which case the order is no longer active) then LeavesQty <151> could be 0, otherwise LeavesQty <151> = OrderQty <38> - CumQty <14>.

14 CumQty Y

Currently executed shares for chain of orders.

6 AvgPx Y
424 DayOrderQty N

For GT orders on days following the day of the first trade.

425 DayCumQty N

For GT orders on days following the day of the first trade.

426 DayAvgPx N

For GT orders on days following the day of the first trade.

427 GTBookingInst N

States whether executions are booked out or accumulated on a partially filled GT order

75 TradeDate N

Used when reporting other than current day trades.

60 TransactTime N

Time the transaction represented by this ExecutionReport occurred

113 ReportToExch N
12 Commission N

On a fill/partial fill messages, it represents value for that fill/partial fill, on ExecType <150>=Calculated, it represents cumulative value for the order. Monetary commission values are expressed in the currency reflected by the Currency <15> field.

13 CommType N
381 GrossTradeAmt N
119 SettlCurrAmt N

Used to report results of forex accommodation trade

120 SettlCurrency N

Used to report results of forex accommodation trade

155 SettlCurrFxRate N

Foreign exchange rate used to compute SettlCurrAmt <119> from Currency <15> to SettlCurrency <120>

156 SettlCurrFxRateCalc N

Specifies whether the SettlCurrFxRate <155> should be multiplied or divided

21 HandlInst N
110 MinQty N
111 MaxFloor N
77 OpenClose N

For options

210 MaxShow N
58 Text N
354 EncodedTextLen N

Must be set if EncodedText <355> field is specified and must immediately precede it.

355 EncodedText N

Encoded (non-ASCII characters) representation of the Text <58> field in the encoded format specified via the MessageEncoding <347> field.

193 FutSettDate2 N

Can be used with OrdType <40> = 'Forex - Swap' to specify the 'value date' for the future portion of a F/X swap.

192 OrderQty2 N

Can be used with OrdType <40> = 'Forex - Swap' to specify the order quantity for the future portion of a F/X swap.

439 ClearingFirm N
440 ClearingAccount N
442 MultiLegReportingType N

Default is a single security if not specified.

<MessageTrailer> Y

 

Related Messages

Onix Solutions