Imported from previous forum
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
I’ve found that firms sending orders often feel very strongly about the following issue: what to do if trading halts for a stock or the whole market, or if the system goes down. Those routing retail / agency order flow generally want the orders to stay in the market regardless of halts or system failures, unless their customer sends them a cancel. Those using proprietary trading models generally take the opposite view; they want the orders killed if a trading halt happens, or a system failure interrupts trading.
This information can be communicated out of band by having the sell-side set defaults on the FIX session. However in the case where a firm is sending multiple kinds of business over one FIX session (i.e. program trading and agency order flow), the proper course of action might need to be determined on an order by order basis.
What follows are two functionally identical alternatives that differ in syntax. I have no preference regarding the specific one chosen. Also note that implementation of these would be entirely optional.
Alternative A:
Add 4 ExecInst Values
Reinstate on Trading Halt:
If trading in this instrument is halted, reinstate this order when/if trading resumes, subject to time in force limitations.
Cancel on Trading Halt:
If trading in this instrument is halted, cancel this order and do not reinstate it when/if trading resumes.
Reinstate on System Failure:
If a system failure interrupts trading or order routing, attempt to reinstate this order, subject to time in force limitations. Note that depending on the type and severity of the failure, this might not be possible.
Cancel on System Failure:
If a system failure interrupts trading or order routing, attempt to cancel this order. Note that depending on the type and severity of the failure, this might not be possible.
Alternative B:
Add 2 new fields to New Order Single, ExecRpt, Order Cancel/Replace, the List order messages, and the new proposed Combination order messages:
ReinstateOnTradingHalt
Bool
Y = If trading in this instrument is halted, reinstate this order when/if trading resumes, subject to time in force limitations.
N = If trading in this instrument is halted, cancel this order and do not reinstate it when/if trading resumes.
ReinstateOnSystemFailure
Bool
Y = If a system failure interrupts trading or order routing, attempt to reinstate this order, subject to time in force limitations.
N = If a system failure interrupts trading or order routing, attempt to cancel this order.
Note that depending on the type and severity of the failure, this might not be possible.
Thoughts?
Ryan said:
> Alternative A:
> Add 4 ExecInst Values
>
> Alternative B:
> Add 2 new fields to <relevant> order messages:
>
> Thoughts?
Two thoughts and a personal opinion.
Firstly in alternative B since they’re optional fields (you don’t say this but you do say that implementation is optional), you’ll also have to specify the default values won’t you?
Secondly, there’s a similar issue with alternative A once you write it into the spec. What’s the meaning of not sending either value? Don’t care?
I suppose you could leave defaults as a ‘business question to be decided bilaterally’, but I think the world would be a better and easier place if there were a standard default. I believe exchanges are generally looking for guidance, and if one needed a different default, they have the power to do so.
I should say that I think that including some mechanism is a good idea. My personal preference is for option A. The ExecInst field already covers a multitude of possibilities and I don’t see these as being fundamentally different somehow. So introducing two new fields seems like overkill.
Oops, that’s at least two opinions. Sorry!
Cheers, Dave
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> Firstly in alternative B since they’re optional fields (you don’t say this but you do say that implementation is optional), you’ll also have to specify the default values won’t you?
I believe a lot of fields in FIX effectively default to "broker option" or otherwise have no default specified.
> Secondly, there’s a similar issue with alternative A once you write it into the spec. What’s the meaning of not sending either value? Don’t care?
No value means that the sell side’s default will be used. However, nothing says that the sell side cannot set the default after consulting out of band with the buy-side.
> I suppose you could leave defaults as a ‘business question to be decided bilaterally’, but I think the world would be a better and easier place if there were a standard default. I believe exchanges are generally looking for guidance, and if one needed a different default, they have the power to do so.
I disagree that a default should be specified. FIX already has a very large user base. Presumably, every trading system, ECN, exchange, etc. already needs some kind of default for these two scenarios, and in many cases I would guess that it is not configurable. Specifying a default in the spec would likely anger a lot of people and force them to require these fields or ExecInst values.
Thanks for the comments.
From the two alternatives, I prefer A.
You don’t introduce a new field. And you don’t limit yourself to the two general cases: “Trading Halted” and “System Failure”.
I mean, you may have possibly more than one kind of a halt (one stock only, whole market; cf. HaltReason) or a failure, or more generally - any state in which the sendert would like seleectively to have his order cancelled. If you find such a case in the future (maybe when trading other markets than US), with Alternative A you’d add an enumeration to handle it; with Alternative B you’d have to add another new field.
There are other options. Such as:
Create ONE new field, of type MultipleValueString, call it something like "CancelOnException", and have enumeration values corresponding to halt and failure, like in alternative A.
What you are trying to solve seems to be a problem which implies time. I mean, I may want to cancel an order if a failure/halt takes longer than, say, a minute, but for shorter halts I may prefer to keep it! Then, as you noted, the sender specification (cancel or reinstate) depends normally on whether the order is agency or not. You will know whether it is an agency order from the CustomerOrFirm field (204) [even if, for some reason, the field has beed described in the specs as "for options"]. Then, you would need a way to say, e.g. "cancel all my firm (not customer) orders on failures longer than 1 minute". How to do that exactly is another story.
(original msg)
> I’ve found that firms sending orders often feel very strongly about the following issue: what to do if trading halts for a stock or the whole market, or if the system goes down. Those routing retail / agency order flow generally want the orders to stay in the market regardless of halts or system failures, unless their customer sends them a cancel. Those using proprietary trading models generally take the opposite view; they want the orders killed if a trading halt happens, or a system failure interrupts trading.
>
> This information can be communicated out of band by having the sell-side set defaults on the FIX session. However in the case where a firm is sending multiple kinds of business over one FIX session (i.e. program trading and agency order flow), the proper course of action might need to be determined on an order by order basis.
>
> What follows are two functionally identical alternatives that differ in syntax. I have no preference regarding the specific one chosen. Also note that implementation of these would be entirely optional.
>
>
> Alternative A:
>
>
> Add 4 ExecInst Values
>
> Reinstate on Trading Halt:
>
> If trading in this instrument is halted, reinstate this order when/if trading resumes, subject to time in force limitations.
>
> Cancel on Trading Halt:
>
> If trading in this instrument is halted, cancel this order and do not reinstate it when/if trading resumes.
>
> Reinstate on System Failure:
>
> If a system failure interrupts trading or order routing, attempt to reinstate this order, subject to time in force limitations. Note that depending on the type and severity of the failure, this might not be possible.
>
> Cancel on System Failure:
>
> If a system failure interrupts trading or order routing, attempt to cancel this order. Note that depending on the type and severity of the failure, this might not be possible.
>
>
> Alternative B:
>
>
> Add 2 new fields to New Order Single, ExecRpt, Order Cancel/Replace, the List order messages, and the new proposed Combination order messages:
>
> ReinstateOnTradingHalt
> Bool
> Y = If trading in this instrument is halted, reinstate this order when/if trading resumes, subject to time in force limitations.
> N = If trading in this instrument is halted, cancel this order and do not reinstate it when/if trading resumes.
>
> ReinstateOnSystemFailure
> Bool
> Y = If a system failure interrupts trading or order routing, attempt to reinstate this order, subject to time in force limitations.
> N = If a system failure interrupts trading or order routing, attempt to cancel this order.
> Note that depending on the type and severity of the failure, this might not be possible.
>
>
> Thoughts?
>
>