Imported from previous forum
The system we are developing has the default behavior of cancelling all open orders on abnormal disconnect (any disconnection that is not preceded by a logout message). There is some talk that it would be a useful feature to allow clients to specify on a per order basis what behavior they would like on abnormal disconnect.
I have two questions. First, can anyone think why this would be a terrible idea (allowing users to specify if an order persists or is cancelled on abnormal disconnect)? And second, is there any field in the NewOrderSingle message that might be pressed into service to accomplish this goal, or would we have to use a non-standard, user defined field?
Thanks!
Robert, from my experience this is typically implemented on the session level, rather than per order.
The system we are developing has the default behavior of cancelling all
open orders on abnormal disconnect (any disconnection that is not
preceded by a logout message). There is some talk that it would be a
useful feature to allow clients to specify on a per order basis what
behavior they would like on abnormal disconnect.I have two questions. First, can anyone think why this would be a
terrible idea (allowing users to specify if an order persists or is
cancelled on abnormal disconnect)? And second, is there any field in the
NewOrderSingle message that might be pressed into service to accomplish
this goal, or would we have to use a non-standard, user defined field?Thanks!
[ original email was from John Prewett - jprewett@lavatrading.com ]
Hi Dmitry,
I agree that this is often implemented (upon bilateral agreement) for all open orders on a session.
There are however advantages for being able to specify this on an individual order. You probably don’t want these type of orders to be canceled, even if your FIX session disconnects:
- Market on close orders
- Market on open orders
- Certain types of long-running algorithmic orders
- GTC orders
- Stop loss orders
So it is a handy feature to allow the specification of your “cancel-upon-disconnect” setting on an individual order. Without this capability you will need 2 sessions: one for orders you want to be canceled and the other for orders you don’t want to be canceled.
I notice that tag 18 (ExecInst) has several useful values in this respect:
K = cancel upon trading halt (added with FIX.4.3)
Q = cancel upon system failure (added with FIX.4.3)
o = cancel upon connection loss (added with FIX.5.0SP1)
So there is a standard way of indicating this (18=o).
Thanks
JohnP
Robert, from my experience this is typically implemented on the session
level, rather than per order.The system we are developing has the default behavior of cancelling
all open orders on abnormal disconnect (any disconnection that is not
preceded by a logout message). There is some talk that it would be a
useful feature to allow clients to specify on a per order basis what
behavior they would like on abnormal disconnect.I have two questions. First, can anyone think why this would be a
terrible idea (allowing users to specify if an order persists or is
cancelled on abnormal disconnect)? And second, is there any field in
the NewOrderSingle message that might be pressed into service to
accomplish this goal, or would we have to use a non-standard, user
defined field?Thanks!
That’s what I was looking for. I must have overlooked it in the spec. Thanks John!
Hi Dmitry,
I agree that this is often implemented (upon bilateral agreement) for
all open orders on a session.There are however advantages for being able to specify this on an
individual order. You probably don’t want these type of orders to be
canceled, even if your FIX session disconnects:
- Market on close orders
- Market on open orders
- Certain types of long-running algorithmic orders
- GTC orders
- Stop loss orders
So it is a handy feature to allow the specification of your “cancel-upon-
disconnect” setting on an individual order. Without this capability you
will need 2 sessions: one for orders you want to be canceled and the
other for orders you don’t want to be canceled.I notice that tag 18 (ExecInst) has several useful values in this
respect: K = cancel upon trading halt (added with FIX.4.3) Q = cancel
upon system failure (added with FIX.4.3) o = cancel upon connection loss
(added with FIX.5.0SP1)So there is a standard way of indicating this (18=o).
Thanks
JohnP
Robert, from my experience this is typically implemented on the
session level, rather than per order.The system we are developing has the default behavior of cancelling
all open orders on abnormal disconnect (any disconnection that is
not preceded by a logout message). There is some talk that it would
be a useful feature to allow clients to specify on a per order basis
what behavior they would like on abnormal disconnect.I have two questions. First, can anyone think why this would be a
terrible idea (allowing users to specify if an order persists or is
cancelled on abnormal disconnect)? And second, is there any field in
the NewOrderSingle message that might be pressed into service to
accomplish this goal, or would we have to use a non-standard, user
defined field?Thanks!
ExecInst is the right place on the order level. I wanted to add that we plan to submit a proposal for the session level along the same lines, i.e. SessionInst as opposed to ExecInst. The idea is to have the ability to express an event (connection loss, trading halt, system failure) a type (cancellation or suspension) and a scope (orders (all or only non-persistent orders), quotes).
Bilateral agreement then governs which of the abilities is actually being offered.
Regards,
Hanno.
That’s what I was looking for. I must have overlooked it in the spec.
Thanks John!Hi Dmitry,
I agree that this is often implemented (upon bilateral agreement) for
all open orders on a session.There are however advantages for being able to specify this on an
individual order. You probably don’t want these type of orders to be
canceled, even if your FIX session disconnects:
- Market on close orders
- Market on open orders
- Certain types of long-running algorithmic orders
- GTC orders
- Stop loss orders
So it is a handy feature to allow the specification of your “cancel-upon-
disconnect” setting on an individual order. Without this capability
you will need 2 sessions: one for orders you want to be canceled and
the other for orders you don’t want to be canceled.I notice that tag 18 (ExecInst) has several useful values in this
respect: K = cancel upon trading halt (added with FIX.4.3) Q = cancel
upon system failure (added with FIX.4.3) o = cancel upon connection
loss (added with FIX.5.0SP1)So there is a standard way of indicating this (18=o).
Thanks
JohnP
Robert, from my experience this is typically implemented on the
session level, rather than per order.The system we are developing has the default behavior of
cancelling all open orders on abnormal disconnect (any
disconnection that is not preceded by a logout message). There is
some talk that it would be a useful feature to allow clients to
specify on a per order basis what behavior they would like on
abnormal disconnect.I have two questions. First, can anyone think why this would be a
terrible idea (allowing users to specify if an order persists or
is cancelled on abnormal disconnect)? And second, is there any
field in the NewOrderSingle message that might be pressed into
service to accomplish this goal, or would we have to use a non-
standard, user defined field?Thanks!