Execution Report
The execution report message is very versatile and is used to: 1. confirm the receipt of an order not immediately executable 2. confirm changes or cancellation of an existing order (i.e. accept cancel and replace requests) 3. relay order status information 4. relay fill information on working orders 6. reject orders
Repos are traded atomically. The OrdQty, LeavesQty, CumQty, AvgPx apply to the overall strategy. Quantities of each individual leg are identical (LegRatioQty always 1).
The instrument leg repeating group is used to report: · Each leg of a Repo · The User supplied per leg information for Settlement allocation · Reporting of last sales price per leg, settlement type, and settlement date.
Important: Each execution report contains two fields which are used to communicate both the current state of the order (OrdStatus) and the purpose of the message (ExecType). 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 field. The order statuses are as follows (in highest to lowest precedence):
Message format:
| Precedence | OrdStatus | Description |
|---|---|---|
| 7 | Filled | Order completely filled, no remaining quantity |
| 4 | Canceled | Canceled order with or without executions |
| 4 | Expired | Order has been canceled in XCDE system due to time in force 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 | Order received with no executions yet |
| 2 | Rejected | Order has been rejected by XCDE. |
The ExecType is used to identify the purpose of the execution report message. To transmit a change in OrdStatus for an order, XCDE will send an Execution Report with the new OrdStatus value in both the ExecType AND the OrdStatus 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 CancelReject message is used both to reject the request and to communicate the current OrdStatus. An ExecType 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) will be communicated in a separate report from one which communicates other state changes (such as canceled, replaced, accepted etc).
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 = ‘Replace’, at which time the effect of the replacement (ClOrdID, 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 the OrderQty to a level less than the CumQty (amount already filled) will be interpreted by XCDE as requests to stop executing the rest of the order.
Requests to change price on a filled order will be rejected (see Order Cancel Reject message type). The OrderQty, CumQty, LeavesQty, and AvgPx fields will be calculated to reflect the cumulative result of all versions of an order. For example, if a partially filled order A were replaced by order B, the OrderQty, CumQty, LeavesQty, and AvgPx on order B’s fills should represent the cumulative result of order A plus those on order B.
The general rule is: OrderQty = CumQty + LeavesQty.
There can be exceptions to this rule when ExecType and/or OrdStatus are Canceled, Expired or Rejected, the order is no longer active and LeavesQty could be 0.
Communication of information about a new fill is via the Execution report with ExecType = Trade. Execution Reports with ExecType = Trade Cancel are used to cancel a previously modified execution report as follows:
An ExecType 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
The field ClOrdID is provided for Users to add their own identification number wich will be echoed back during the lifetime of the Order. Instead, the OrderID field is populated by XCDE with a self-generated order number. The ClOrdID/OrigClOrdID requires a chaining through Cancel/Replaces and Cancels, as opposed to the OrderID which is not changing during the lifecycle of the order.
When the ExpireDate or ExpireTime of a Good Till Date order is reached, the order is considered expired and XCDE will send an Execution Report with ExecType and OrdStatus = Expired(C).
In handling GT orders, the OrderQty, CumQty and AvgPx fields will represent the entirety of the order over all days. Requests to change or cancel an order must be made in terms of the initial total quantity for the order, not the quantity remaining now. For example, on an order where OrderQty = 100 and 20 have been filled, a request to change OrderQty to 150 will mean that only 130 will remain working (150 - 20 already filled). The ExecutionReport is also used to accept CancelRequest and cancel/replace request messages.
Message format:
| Field Name | Format | Req'd | Comments | |
|---|---|---|---|---|
| MsgType | String | ✓ | 8 = ExecutionReport | |
| MsgSeqNum | SeqNum | ✓ | User generated incremental number to allow receiver to identify possible message gaps | |
| SendingTime | UTCTimestamp | ✓ | UTC Time of message transmission | |
| OrderID | String | Provided by XCDE for this ExecReport | ||
| ClOrdID | String | ✓ | User generated Unique identifier of the order referred to by this report | |
| OrigClOrdID | String | ClOrdID (11) of the User’s previous order message (NOT the initial order of the day), used to identify the order in cancel and cancel/replace requests. | ||
| ClOrdLinkID | String | In case of grouping of Orders e.g. with OCAO | ||
| OrdStatusReqID | String | Echoes the User assigned ID of an Order Status Request message. | ||
| TrdMatchID | String | Identifier assigned by XCDE’s matching system (would be same for both sides of a trade) | ||
| ExecID | String | ✓ | Unique identifier of this execution message as assigned by XCDE | |
| ExecType | Char | ✓ | Describes the purpose of the execution report. Supported values: 4 = Canceled 5 = Replaced 8 = Rejected C = Expired F = Trade (partial fill or fill) I = Order Status | |
| OrdStatus | Char | ✓ | Current state of the Order. Possible values: 1 =Partially filled 2 = Filled 4 = Canceled 8 = Rejected C = Expired | |
| OrdRejReason | Int | For optional use with ExecType = 8 (Rejected) when Order placement is
rejected: 1 = Unknown symbol 3 = Order exceeds limit 5 = Unknown order 6 = Duplicate Order (e.g. dupe ClOrdID) 11 = Unsupported order characteristic 13 = Incorrect quantity 15 = Unknown account(s) 18 = Invalid price increment 99 = Other | ||
| Account | String | User account as defined by XCDE | ||
| AllocID | String | Echoes the User’s AllocID | ||
| <Instrument> Component block | ✓ | |||
| > | Symbol | String | BTC/EUR-2w-R | |
| Side | Char | ✓ | Identifies Near_Leg direction for Base currency. F = Lend (a.k.a repo Bid price) G = Borrow (a.k.a. Repo Offer price) | |
| <OrderQtyData> Component block | ||||
| > | OrderQty | Qty | Effectively required | |
| Price | Price | Echoed if specified on the order | ||
| TimeInForce | Char | Echoes the User’s intruction, supported: 0 =Day (or session) 1 =Good Till Cancel (GTC) 3 =Immediate Or Cancel (IOC) 4 =Fill Or Kill (FOK) 6 =Good Till Date (GTD) | ||
| ExpireDate | LocalMktDate | Echoes the User’s intruction | ||
| ExpireTime | UTCTimestamp | Echoes the User’s intruction | ||
| ExecInst | Char | Echoes the User’s intruction if provided (G = All or none only). | ||
| LastQty | Qty | Quantity bought/sold if this is a (last) fill. | ||
| LastPx | Price | Price of this (last) fill. This is the Repo traded price (Spread) | ||
| LastSpotRate | Price | Reference XCDE Spot rate at the time of the fill | ||
| TradingSessionID | String | 202220826 | ||
| LeavesQty | Qty | ✓ | Remaining quantity if this is a partially filled Order. If OrdStatus = Canceled, Expired, or Rejected (in which case the order is no longer active) then LeavesQty will be 0. In all other cases, LeavesQty = OrderQty - CumQty. | |
| CumQty | Qty | ✓ | Total executed quantity for the chain of this order. | |
| TradeDate | LocalMktDate | Used when reporting other than current day trades, NY local time | ||
| TransactTime | UTCTimestamp | Timestamp of the event this message is about | ||
| <CommissionData> Component block | ||||
| > | Commission | Amt | 1.25 | |
| > | CommType | Char | 3 = Absolute (total monetary amount) | |
| > | CommCurrency | Currency | Generally USD or currency agreed with User | |
| MinQty | Qty | Relays User instruction | ||
| MatchIncrement | Qty | Relays User instruction | ||
| Text | String | Unessential freeform field to post information | ||
| PriceImprovement | PriceOffset | 0.15 (example) If any | ||
| <InstrmtLegExecGrp> Component block | Number of legs Identifies a Multi-leg Execution if present and non-zero. | |||
| <InstrumentLeg> Repeating group | Effectively required | |||
| >> | LegSymbol | String | BTC/USD-SPOT | |
| >> | LegMaturityDate | LocalMktDate | 20220826 (example) Date of Settlement of the leg | |
| >> | LegMaturityTime | TZTimeOnly | 17:00-05 Time of Settlement local NY only if leg is not CASH | |
| >> | LegSecurityDesc | String | BTC/USD Spot | |
| >> | LegSide | Char | E.g. 1 = BUY | |
| >> | LegAllocID | String | Echo the User’s LegAllocID | |
| <LegPreAllocGrp> Repeating group | ||||
| >>> | LegAllocAccount | String | User defined Allocation destination, previously whitelisted | |
| >> | LegSettlType | Char | For Intra-day the Near_Leg is 1 = Cash, the Far_Leg is 0 = Spot (5pm NY) 0 = Regular / Spot (means today 5pm NY) 1 = Cash (mean immediate settlement) 2 = Next Day (means next settlement day at 5pm NY) | |
| >> | LegSettlDate | LocalMktDate | If not defined by LegSettleType | |
| >> | LegLastPx | Price | Execution price of this leg of the Repo | |
| >> | LegSettlCurrency | Currency | To indicate preference for USD value in Stablecoins | |
| >> | LegLastQty | Qty | Quantity of this Leg execution | |
| <MiscFeesGrp> Component block | Required if any miscellaneous fees are reported. | |||
| > | NoMiscFees | NumInGroup | Indicates number of repeating entries. | |
| > | MiscFeeAmt | Amt | Fee amount | |
| > | MiscFeeCurr | Currency | Fee currency e.g. USD | |
| > | MiscFeeType | String | 4 = Exchange Fee | |
1MsgType: 8
2MsgSeqNum: 823786453
3SendingTime: 20220907-01:11:25.825
4OrderID: jd783523654-jjsh-224
5ClOrdID: gdgdte-2763645
6OrigClOrdID: gdgdte-2763646
7TrdMatchID: tm-6354-w75
8ExecID: ex-75612435-hd
9ExecType: F
10OrdStatus: 2
11Account: 42119
12Instrument
13 Symbol: BTC/USDT-ID-R
14 Side: F
15OrderQtyData
16 OrderQty: 200
17Price: 3.15
18TimeInForce: 1
19ExecInst: G
20LastQty: 200
21LastPx: 3.10
22LastSpotRate: 19,327
23TradingSessionID: 20220907
24LeavesQty: 0
25CumQty: 200
26TradeDate: 20220906
27TransactTime: 20220907-01:11:25.263
28CommissionData
29 Commission: 1.25
30 CommType: 3
31 CommCurrency: USD
32MinQty: 100
33Text: Order Filled
34PriceImprovement: 0.05
35InstrmtLegExecGrp
36InstrumentLeg
37 LegSymbol: BTC/USD-CASH
38 LegMaturityDate: 20220907
39 LegSecurityDesc: BTC/USD Cash
40 LegSide: 2
41 LegSettlType: 1
42 LegSettlDate: 20220907
43 LegLastPx: 19,327
44 LegLastQty: 200
45InstrumentLeg
46 LegSymbol: BTC/USD-SPOT
47 LegMaturityDate: 20220907
48 LegSecurityDesc: BTC/USD Spot
49 LegSide: 1
50 LegSettlType: 0
51 LegSettlDate: 20220907
52 LegMaturityTime: 17:00-05
53 LegLastPx: 19,330.10
54 LegLastQty: 200
55MiscFeesGrp
56NoMiscFees
57 MiscFeeAmt: 0
58 MiscFeeCurr: USD
59 MiscFeeType: 4 1{
2 "Header": {
3 "MsgType": "8",
4 "MsgSeqNum": "823786453",
5 "SenderCompID": "SENDER",
6 "TargetCompID": "TARGET",
7 "SendingTime": "20220907-01:11:25.825"
8 },
9 "OrderID": "jd783523654-jjsh-224",
10 "ClOrdID": "gdgdte-2763645",
11 "OrigClOrderID": "gdgdte-2763645",
12 "TrdMatchID": "tm-6354-w75",
13 "ExecID": "ex-75612435-hd",
14 "ExecType": "F",
15 "OrdStatus": "2",
16 "Account": "42119",
17 "Instrument": {
18 "Symbol": "BTC/USDT-ID-R"
19 },
20 "Side": "F",
21 "OrderQtyData": {
22 "OrderQty": "200"
23 },
24 "Price": "3.15",
25 "TimeInForce": "1",
26 "ExecInst": "G",
27 "LastQty": "200",
28 "LastPx": "3.10",
29 "LastSpotRate": "19327",
30 "TradingSessionID": "20220907",
31 "LeavesQty": "0",
32 "CumQty": "200",
33 "TradeDate": "20220906",
34 "TransactTime": "20220907-01:11:25.263",
35 "CommissionData": {
36 "Commission": "1.25",
37 "CommType": "3",
38 "CommCurrency": "USD"
39 },
40 "MinQty": "100",
41 "Text": "Order Filled",
42 "PriceImprovement": "0.05",
43 "InstrmtLegExecGrp": {
44 "InstrumentLeg": [
45 {
46 "LegSymbol": "BTC/USD-CASH",
47 "LegMaturityDate": "20220907",
48 "LegSecurityDesc": "BTC/USD Cash",
49 "LegSide": "2",
50 "LegSettlType": "1",
51 "LegSettlDate": "20220907",
52 "LegLastPx": "19327",
53 "LegLastQty": "200"
54 },
55 {
56 "LegSymbol": "BTC/USD-SPOT",
57 "LegMaturityDate": "20220907",
58 "LegSecurityDesc": "BTC/USD Spot",
59 "LegSide": "1",
60 "LegSettlType": "0",
61 "LegSettlDate": "20220907",
62 "LegMaturityTime": "17:00-05",
63 "LegLastPx": "19330.10",
64 "LegLastQty": "200"
65 }
66 ]
67 },
68 "MiscFeesGrp": {
69 "MiscFeeAmt": "0",
70 "MiscFeeCurr": "USD",
71 "MiscFeeType": "4"
72 }
73}