Execution Reports: LastShares, LastPX, CumQty, and AvgPx

Imported from previous forum

[ original email was from Ben Santello - ]
Seeking input/advice on the following:

  1. After the description of the "CORRECT" transaction type for an execution the following note appears "NOTE: Data reported in the CumQty and AvgPx fields represent the status of the order as of the time of the correction, not as of the time of the originally reported execution." However, it is unclear what the CumQty and AvgPX should be in a "CANCEL" execution message. Should they be set to the values they were before the execution being cancelled was originally sent? Should they be set to the new CumQty and AvgPx after removing the effect of the fills reported in the execution being cancelled? It seems obvious to me that the latter is the case. We always report the current CumQty and AvgPX when sending an execution, regardless of its transaction type (NEW, CANCEL, CORRECT, or STATUS). It seems that the specification would be clearer if it stated that this should always be the case - "The CumQty and AvgPX in ANY execution message indicates the current CumQty and AvgPx as know by the sending party." Obviously, the current CumQty and AvgPx takes into consideration the effect of all fills, cancelled fills, and corrected fills."

I think the above suggestion makes sense because an order always has a known CumQty and AvgPx - at anytime in its life. What do people think???

  1. I think the LastShares and LastPX fields require clarification as well. According to the spec - they are required in all executions accept for the STATUS type. In many cases it seems confusing as to what to set their value to - i.e. in a CANCEL type execution, in an execution message rejecting an order, in an execution message acknowledging an order, in an execution message accepting a cancel or cancel/replace request, when reporting miscellaneouse fees calucalations, etc. It seems to me that this confusion could be greatly simplified by only requiring LastShares and LastPX in execution messages relaying "fills" information. This is the case for NEW executions carrying fills and CORRECT executions (which are only used to modify an incorrectly reported fill) only. What do people think???

Thanks, Ben