Hi all. Is there a standard tag that we could use to define a timeout on a per order basis? The case is day orders that would be automatically cancelled upon expiration of their timeouts unless a specific event happens. Could we use tag ExposeDuration (1629) even if TimeInForce is not GFT? Thank you.
@laurentbrenot which values of TimeInForce(59) do you want to combine with the exposure duration and what does that mean in each case? Day orders are valid for the current business day. Your example sounds more like a GFT order that should automatically be converted to a GFD order if a specific event happens. Is this event specific to the order submitter or is it an instrument-/market-wide event?
Business case is as follows: the strategy will send a bunch of orders (day TIF) linked together with a few tags (tags 66, 67 and 68). A time window is triggered upon receipt of the first order according to a duration provided in this order: all linked orders must be received within this time window. If all orders are received before expiration of this time window, they will considered valid orders and then will be further processed and submitted to trading venues. Otherwise, if for any reason some orders are not received in due time, all linked orders will be cancelled.
It looks like you might be using the NewOrderList(35=E) already for this “bunch of orders” but it appears ambiguous since you wrote “linked orders must be received within this time window” so are you using NewOrderSingle(35=D) or NewOrderList?.
That said, what you describe appears to be a kind of contingency event where all the orders would be valid if all the orders are submitted within some time period, otherwise cancel all. Who determines this timer? Is it the order submitter or receiver? This kind of submission time frame is either a TimeInForce(59) (since you said the orders are DAY orders) nor ExposureDuration(1629), in my opinion, as both of these are about the validity of that one order it is attached to. What you describe appears to me to be a new timer concept. As it is unclear what msg type you’re using and who determines this timer, I’m inclined to look at a custom value in the ContingencyType(1385) and maybe call it something like “Order submission duration or cancel” but you’ll need another field for the duration, unfortunately custom ones (e.g. ContingencyDuration + ContingencyDurationUnit if you want to model it like ExposureDuration/ExposureDurationUnit - which is what I would do) since ExposureDuration is tied to GFT in a NewOrderSingle and is within the ListOrdGrp in a NewOrderList.
The timer is determined by the submitters who will send 35=D only as they don’t want to implement 35=E. Based on your inputs, I think the best is to create two user-defined tags such as OrderDuration and OrderDurationUnit. Thanks for your help.
“OrderDuration” can be misleading label. If I didn’t know your background to this just looking at the name it would imply the validity duration of the order, rather than what you actually intend which has to do with submission of all linked orders. This semantics would be important to avoid confusion since ExposureDuration is already about validity duration of the order. Just my two cents.
@laurentbrenot, putting the tags 66,67,68 for list orders on NewOrderSingle creates a custom hybrid message between NewOrderSingle and NewOrderList. Semantically, your order duration applies to the list and not to the individual order. Using NewOrderSingle requires you to put the same duration value on all orders or to put it on only one of them to avoid inconsistencies. It sounds like the latter with the first order providing the time window.
It also does not sound like a duration of order validity. You want to ensure that all orders hit the market within a specific time frame. I am assuming that the first order does not have to wait for the other(s) to arrive before being released into the market. In terms of naming for the custom fields I would use the terms “List” and “Timer” as parts of it to avoid confusion with the validity of an individual order of the list.
I agree about 35=E but the constraint I have is that all stakeholders want to keep 35=D in the whole flow. Thank you all for your useful inputs.