Imported from previous forum
Please could someone please explain to me, or point me to a document that does explain in definitive terms, how each of the fields in an ER should be set (and in particular ExecType) when the ExecTransType is set to CORRECT or CANCEL.
It seems that there are effectively three types of fields in an ER:
- Static Data - guaranteed not to change for all ERs relating to an order. eg. Symbol, SecurityId.
- Order Data - set according to the current status of the Order as at the time the CORRECT or CANCEL ER is sent. eg CumQty, LeavesQty & AvgPx.
- Execution Data - only applicable to an ER which reports an actual execution. In the case of a CORRECT set to the new corrected values and in the case of a CANCEL set to 0 (or null). eg. LastShares, LastPx.
It is stated in the spec that CumQty, LeavesQty, and AvgPx represent the order as of the time of the correction; ie type 2, no problem. By implication from the state change matrices in Appendix D OrdStatus and ClOrdID should also represent the order as of the time of the correction. However it is not clear how the ExecType field should be set. The only reference to it is in the state change matrices D34-D36 of the FIX 4.2 spec and in these it appears inconsistent. In the CORRECT examples D34 & D36 ExecType appears to be copied directly from OrdStatus but I suspect it is set as if the fill had occurred at the time of the correction. In the CANCEL example of D35 ExecType appears to be set to the value in the ER it is referring to. Is this the right interpretation of the matrices? If the correction comes after the ‘DONE FOR DAY’ ER will ExecType be set to ‘PARTIAL FILL’ or ‘FILL’ (depending on LeavesQty==0) or ‘DONE FOR DAY’? If the only fill of an Order is cancelled is ExecType set to ‘NEW’ to reflect that the OrdStatus has changed back to ‘NEW’ or is it set to ‘PARTIAL FILL’ or ‘FILL’ to reflect the ER that is being cancelled? And this raises another question: according to the spec “execution information should not be communicated in the same report as one which communicates other state changes” so if a cancellation or correction causes a change in OrdStatus does this need to be reported in two ERs?
While this is a specific query it does highlight the more general problem of defining the protocol in terms of a set of examples which are occasionally ambiguous. Wouldn’t it be more useful if the specification defined the meanings of the fields and the rules which govern how they are set in clear definitive terms rather than having to rely on case by case examples?
Thanks,
Andrew Hall
Nomura International Plc