Imported from previous forum
[ original email was from Witold Sames - wsames@bloomberg.net ]
Quick and easy - we were thinking of supporting suspension of order(s) via a FIX connection. A client could set his orders to OrdStatus ‘suspended’ or ‘unsuspended’, maybe even with a single message for ALL orders. Just a plain and simple tool to ‘undisplay’ and make unaccessible this client’s orders for various different reasons.
Does anyone have suggestions or ideas, or even better, already support this via FIX? I am not so sure that ‘39=9’ (OrdStatus Suspended) means the same thing as in the case of an ECN…
[ original email was from Vitaliy Kantor - ]
At least by design 39=9 should mean same suspension for ECN as for others, i.e. don’t execute it. As you know there is no bulk operations in the protocol now. So you can suspend(or release later) one order in one message.
It was proposed at ECN work group meeting(see minutes) to include bulk operations in the protocol. This suggestion will be considered by the Technical Committee for next version of the protocol.
Vitaliy Kantor
Morgan Stanley
> Quick and easy - we were thinking of supporting suspension of order(s) via a FIX connection. A client could set his orders to OrdStatus ‘suspended’ or ‘unsuspended’, maybe even with a single message for ALL orders. Just a plain and simple tool to ‘undisplay’ and make unaccessible this client’s orders for various different reasons.
>
> Does anyone have suggestions or ideas, or even better, already support this via FIX? I am not so sure that ‘39=9’ (OrdStatus Suspended) means the same thing as in the case of an ECN…
>
>
[ original email was from Jim Michuda - ]
> At least by design 39=9 should mean same suspension for ECN as for others, i.e. don’t execute it. As you know there is no bulk operations in the protocol now. So you can suspend(or release later) one order in one message.
>
> It was proposed at ECN work group meeting(see minutes) to include bulk operations in the protocol. This suggestion will be considered by the Technical Committee for next version of the protocol.
>
> Vitaliy Kantor
> Morgan Stanley
> > Quick and easy - we were thinking of supporting suspension of order(s) via a FIX connection. A client could set his orders to OrdStatus ‘suspended’ or ‘unsuspended’, maybe even with a single message for ALL orders. Just a plain and simple tool to ‘undisplay’ and make unaccessible this client’s orders for various different reasons.
> >
> > Does anyone have suggestions or ideas, or even better, already support this via FIX? I am not so sure that ‘39=9’ (OrdStatus Suspended) means the same thing as in the case of an ECN…
> >
> >
>
[ original email was from Jim Michuda - ]
Once an order has been suspended, how do you "unsuspend" (or more appropriately, activate) that very same order?
> At least by design 39=9 should mean same suspension for ECN as for others, i.e. don’t execute it. As you know there is no bulk operations in the protocol now. So you can suspend(or release later) one order in one message.
>
> It was proposed at ECN work group meeting(see minutes) to include bulk operations in the protocol. This suggestion will be considered by the Technical Committee for next version of the protocol.
>
> Vitaliy Kantor
> Morgan Stanley
> > Quick and easy - we were thinking of supporting suspension of order(s) via a FIX connection. A client could set his orders to OrdStatus ‘suspended’ or ‘unsuspended’, maybe even with a single message for ALL orders. Just a plain and simple tool to ‘undisplay’ and make unaccessible this client’s orders for various different reasons.
> >
> > Does anyone have suggestions or ideas, or even better, already support this via FIX? I am not so sure that ‘39=9’ (OrdStatus Suspended) means the same thing as in the case of an ECN…
> >
> >
>
[ original email was from Witold Sames - wsames@bloomberg.net ]
That’s what I wanted to open up for discussion - might even be necessary to ‘invent’ a message type that can do that. I would hate to see CancelReplace be misused for this…
Witold Sames
wsames@bloomberg.net
> Once an order has been suspended, how do you “unsuspend” (or more appropriately, activate) that very same order?
>
> > At least by design 39=9 should mean same suspension for ECN as for others, i.e. don’t execute it. As you know there is no bulk operations in the protocol now. So you can suspend(or release later) one order in one message.
> >
> > It was proposed at ECN work group meeting(see minutes) to include bulk operations in the protocol. This suggestion will be considered by the Technical Committee for next version of the protocol.
> >
> > Vitaliy Kantor
> > Morgan Stanley
> > > Quick and easy - we were thinking of supporting suspension of order(s) via a FIX connection. A client could set his orders to OrdStatus ‘suspended’ or ‘unsuspended’, maybe even with a single message for ALL orders. Just a plain and simple tool to ‘undisplay’ and make unaccessible this client’s orders for various different reasons.
> > >
> > > Does anyone have suggestions or ideas, or even better, already support this via FIX? I am not so sure that ‘39=9’ (OrdStatus Suspended) means the same thing as in the case of an ECN…
> > >
> > >
> >
>
[ original email was from Vitaliy Kantor - ]
Technically you send CancelReplace w/o suspend in ExecInst and can also make other changes if you will.
> That’s what I wanted to open up for discussion - might even be necessary to ‘invent’ a message type that can do that. I would hate to see CancelReplace be misused for this…
I don’t consider this usage of CancelReplace for (un)suspending single order to be so distasteful as you imply. I’d think that special message for affecting order state in some special way is overkill and just increase complexity of the protocol.
However I agree that we should consider special messages for bulk operations including (un)suspend for all or subsets of outstanding orders. Benefits due to better delivery time are quite obvious.
Vitaliy Kantor
Morgan Stanley
>
> Witold Sames
> wsames@bloomberg.net
>
> > Once an order has been suspended, how do you “unsuspend” (or more appropriately, activate) that very same order?
> >
> > > At least by design 39=9 should mean same suspension for ECN as for others, i.e. don’t execute it. As you know there is no bulk operations in the protocol now. So you can suspend(or release later) one order in one message.
> > >
> > > It was proposed at ECN work group meeting(see minutes) to include bulk operations in the protocol. This suggestion will be considered by the Technical Committee for next version of the protocol.
> > >
> > > Vitaliy Kantor
> > > Morgan Stanley
> > > > Quick and easy - we were thinking of supporting suspension of order(s) via a FIX connection. A client could set his orders to OrdStatus ‘suspended’ or ‘unsuspended’, maybe even with a single message for ALL orders. Just a plain and simple tool to ‘undisplay’ and make unaccessible this client’s orders for various different reasons.
> > > >
> > > > Does anyone have suggestions or ideas, or even better, already support this via FIX? I am not so sure that ‘39=9’ (OrdStatus Suspended) means the same thing as in the case of an ECN…
> > > >
> > > >
> > >
> >
>
> Quick and easy - we were thinking of supporting suspension of order(s) via a FIX connection. A client could set his orders to OrdStatus ‘suspended’ or ‘unsuspended’, maybe even with a single message for ALL orders. Just a plain and simple tool to ‘undisplay’ and make unaccessible this client’s orders for various different reasons.
>
> Does anyone have suggestions or ideas, or even better, already support this via FIX? I am not so sure that ‘39=9’ (OrdStatus Suspended) means the same thing as in the case of an ECN…
>
> Suspend orders message should allow firms to suspend orders for the entire firm, a security or specific user or group of users.
[ original email was from John Armstrong - johna@ms.com ]
> > Does anyone have suggestions or ideas, or even better, already support this via FIX? I am not so sure that ‘39=9’ (OrdStatus Suspended) means the same thing as in the case of an ECN…
It’s currently supported through the Suspend
order instruction. You would send this on a
cancel/replace. To reactivate, you would send
another cancel/replace w/o the suspend instruction.
An execution with OrdStatus == Suspended means the
order has been suspended(as you suggest).
> >
> > Suspend orders message should allow firms to suspend orders for the entire firm, a security or specific user or group of users.
There is currently no support for this in the spec
although things like suspension and cancel for a
SenderCompID would be useful and has been discussed in the past for inclusion in a future rev.
>
[ original email was from James Michuda - jmichuda@optimark-tech.com ]
I know we’ve talked about this before, but wouldn’t it be better to add another OrdStatus (say, Unsuspend) so that anyone explicitly wanting to reactivate an order would need to specify the instruction? I think it’s potentially dangerous to implement a method where the absence of one thing implies another (i.e. reactivating an order by sending a cancel/replace w/o the suspend instruction).
> > > Does anyone have suggestions or ideas, or even better, already support this via FIX? I am not so sure that ‘39=9’ (OrdStatus Suspended) means the same thing as in the case of an ECN…
>
> It’s currently supported through the Suspend
> order instruction. You would send this on a
> cancel/replace. To reactivate, you would send
> another cancel/replace w/o the suspend instruction.
>
> An execution with OrdStatus == Suspended means the
> order has been suspended(as you suggest).
>
> > >
> > > Suspend orders message should allow firms to suspend orders for the entire firm, a security or specific user or group of users.
>
> There is currently no support for this in the spec
> although things like suspension and cancel for a
> SenderCompID would be useful and has been discussed in the past for inclusion in a future rev.
>
> >
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> I know we’ve talked about this before, but wouldn’t it be better to add another OrdStatus (say, Unsuspend) so that anyone explicitly wanting to reactivate an order would need to specify the instruction? I think it’s potentially dangerous to implement a method where the absence of one thing implies another (i.e. reactivating an order by sending a cancel/replace w/o the suspend instruction).
The client never specifies the OrdStatus field. OrdStatus is something the Exchange/ECN/broker sets in an Execution message.
Are you sure you don’t mean adding an Unsuspend ExecInst for the customer to specify?
Each of the ExecInst values is generally a boolean. An order is All or None or it isn’t. It is Not Held or it isn’t, Similarly, it is Suspended or it isn’t. I see no reason to create an Unsuspend ExecInst unless we create an Un-All or None, an Un-Not Held, etc.
[ original email was from Charles Paclat - paclat@latrade.com ]
> > I know we’ve talked about this before, but wouldn’t it be better to add another OrdStatus (say, Unsuspend) so that anyone explicitly wanting to reactivate an order would need to specify the instruction? I think it’s potentially dangerous to implement a method where the absence of one thing implies another (i.e. reactivating an order by sending a cancel/replace w/o the suspend instruction).
>
> The client never specifies the OrdStatus field. OrdStatus is something the Exchange/ECN/broker sets in an Execution message.
>
> Are you sure you don’t mean adding an Unsuspend ExecInst for the customer to specify?
>
> Each of the ExecInst values is generally a boolean. An order is All or None or it isn’t. It is Not Held or it isn’t, Similarly, it is Suspended or it isn’t. I see no reason to create an Unsuspend ExecInst unless we create an Un-All or None, an Un-Not Held, etc.
>
>
While I agree with this last statement in principal it seems to me that “Suspend” as an ExecInst is a bit out of place. In general the ExecInst(s) stand on their own and it seems odd that a request to change the State of an order should live there. A more natural solution would be to allow the sending of a new OrdStatus in the Cancel/Replace message.
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> > Each of the ExecInst values is generally a boolean. An order is All or None or it isn’t. It is Not Held or it isn’t, Similarly, it is Suspended or it isn’t. I see no reason to create an Unsuspend ExecInst unless we create an Un-All or None, an Un-Not Held, etc.
> >
> >
> While I agree with this last statement in principal it seems to me that “Suspend” as an ExecInst is a bit out of place. In general the ExecInst(s) stand on their own and it seems odd that a request to change the State of an order should live there. A more natural solution would be to allow the sending of a new OrdStatus in the Cancel/Replace message.
I agree with you that Suspend is unusual as an ExecInst, and the idea of doing a Cancel/Replace to suspend an order seems somewhat strange. Now if I call it a Modification instead of a Cancel/Replace (since that’s what it is more like) then it makes a little more sense. But it still has the disadvantage of requiring a unique ClOrdID to create the order, another for suspending the order, and another to un-suspend the order.
But OrdStatus is a field that only appears in the Execution message. It is a field that the sell-side uses to inform the buy-side of the order’s state; the buy-side never directly sets it elsewhere. It would be very confusing to add it to the Cancel/Replace message solely for this purpose, more than leaving things as they are.
I think the most straightforward thing would be to create two new messages - OrderSuspendRequest and ListSuspendRequest. Of course this may not be desirable because it eats up two MsgType letters, which are growing scarce.
[ original email was from John Armstrong - johna@ms.com ]
> I agree with you that Suspend is unusual as an > ExecInst, and the idea of doing a Cancel/Replace > to suspend an order seems somewhat strange. Now > if I call it a Modification instead of a > Cancel/Replace (since that’s what it is more > like) then it makes a little more sense. But it > still has the disadvantage of requiring a unique > ClOrdID to create the order, another for > suspending the order, and another to un-suspend > the order.
We’ve discussed the idea of having certain changes
that change ClOrdID and certain ones that don’t.
Unfortunately, one can’t apply a one-size fits all rule that satisfies the existing rules in all markets.
Although, a Suspend instruction is a bit odd, it frees the requestor from not having to worry
about what this means on the exchange. If a broker
provides this as added value say to SIAC, it will
result in a cancel followed by a new(unsuspend).
Adding an Unsuspend instruction makes sense and
it also allows you to change order attributes at the same time. If you suspend an order for some time, you are likely to want to change the price when you reactivate it since the market will most likely have moved.
>
[ original email was from James Michuda - jmichuda@optimark-tech.com ]
> > I know we’ve talked about this before, but wouldn’t it be better to add another OrdStatus (say, Unsuspend) so that anyone explicitly wanting to reactivate an order would need to specify the instruction? I think it’s potentially dangerous to implement a method where the absence of one thing implies another (i.e. reactivating an order by sending a cancel/replace w/o the suspend instruction).
>
> The client never specifies the OrdStatus field. OrdStatus is something the Exchange/ECN/broker sets in an Execution message.
>
> Are you sure you don’t mean adding an Unsuspend ExecInst for the customer to specify?
>
Yes, this is what I meant. I cut and pasted without checking for accuracy. Sorry.
> Each of the ExecInst values is generally a boolean. An order is All or None or it isn’t. It is Not Held or it isn’t, Similarly, it is Suspended or it isn’t. I see no reason to create an Unsuspend ExecInst unless we create an Un-All or None, an Un-Not Held, etc.
>
>
[ original email was from James Michuda - jmichuda@optimark-tech.com ]
> > I know we’ve talked about this before, but wouldn’t it be better to add another OrdStatus (say, Unsuspend) so that anyone explicitly wanting to reactivate an order would need to specify the instruction? I think it’s potentially dangerous to implement a method where the absence of one thing implies another (i.e. reactivating an order by sending a cancel/replace w/o the suspend instruction).
>
> The client never specifies the OrdStatus field. OrdStatus is something the Exchange/ECN/broker sets in an Execution message.
>
> Are you sure you don’t mean adding an Unsuspend ExecInst for the customer to specify?
>
> Each of the ExecInst values is generally a boolean. An order is All or None or it isn’t. It is Not Held or it isn’t, Similarly, it is Suspended or it isn’t. I see no reason to create an Unsuspend ExecInst unless we create an Un-All or None, an Un-Not Held, etc.
>
>
Actually, you picked an unusual example. There is an ExecInst "Held" and an ExecInst "Not Held". There is also a "No cross" and a "OK to cross". The precedent has already been set.
[ original email was from Shay Gordon - gordon@instinet.com ]
Another possible solution is to provide a new
boolean field, Suspend, in the New Order and
Order Cancel[/Replace] messages. The OrdStatus
in the response from the executor would indicate
whether or not the order was suspended, either
on entry or after modification. The only slight
problem I have with this proposal is the usual
are of semantics: we are modifying the order,
not canceling or replacing it.
I also agree that support for bulk suspend/
unsuspend operations might be desirable.