< Previous Next >
Should we allow to echo back ContingencyType  in execution reports?
Natan Kugel / BGC Partners <>
23 Jun 2010 11:21AM ET
Should we allow to echo back ContingencyType  in execution reports? This would add clarity to the message flow when orders get executed, cancelled etc.
Currently. List Status message carries the field, however using it past the step of accepting the list or when processing list cancel creates redundancy and may lead to inconsistencies. The most reliable and precise way of reporting order state / trades has been through execution reports for individual orders.
Here is more information, where it may help - a List can be sent using more than one fragment - more than one New Order List message. The contingency type, strictly speaking, specified in the new order list message applies to orders forming the message - the fragment. Depending on implementation, if differences of fragments in the list are allowed or not, a fragment may be rejected. However, everything that is accepted by the executing side will be reported using execution reports - the lowest denominator.
In addition, in cancel replace, presence of ListID  historically has been used for verification purposes. Interpretation of this, can be moved forward to allow modifications to orders unretated to list to join the list.
A List Fragment control component can be created consisting ListID , ContingencyType  and addition information related to the the fragment of a list. This component may be part of the execution reports / cancel replace requests.
Please let me know. I will volunteer to do the leg work for next step.