Imported from previous forum
Hello,
I am having a hard time formulating the proper behaviour in a couple of CancelReplace and Order Status scenarios. I could not find any guidelines nor example of transitions in any of the FIX spec matrices so I would appreciate any of your thoughts.
Assume that replace was successfull in all cases.
Scenario 1:
New Order(X)
…
CancelReplace(Y,X)
Q: Should the client be able to issue subsequent CancelReplace(Z,X)? If so, what the heck happens to Order(Y) ? My logic dictates, that CancelReplace(Z,X) should be rejected, but with what message and with what clOrdId,origClOrdId pair?
Scenario 2:
New Order(X)
…
CancelReplace(Y,X)
CancelReplace(Z,Y)
Q: Should the client be able to issue Order Status(X) at this point? If so, what should be the response with what clOrdId,origClOrdId pair?
If not, what should be the status rejection message?
The FIX matrices have an example for a scenario similar to (2) but not quite the same. It does not show an Order Status for the original clOrdId after it had been replaced twice…
Any thoughts would be appreciated …
Cheers,
Andrew
Hello,
I am having a hard time formulating the proper behaviour in a couple of
CancelReplace and Order Status scenarios. I could not find any
guidelines nor example of transitions in any of the FIX spec matrices so
I would appreciate any of your thoughts.Assume that replace was successfull in all cases.
Scenario 1:
New Order(X)
…
CancelReplace(Y,X)Q: Should the client be able to issue subsequent CancelReplace(Z,X)? If
so, what the heck happens to Order(Y) ? My logic dictates, that
CancelReplace(Z,X) should be rejected, but with what message and with
what clOrdId,origClOrdId pair?Scenario 2:
New Order(X)
…
CancelReplace(Y,X) CancelReplace(Z,Y)R: Should the client be able to issue Order Status(X) at this point? If
so, what should be the response with what clOrdId,origClOrdId pair?
If not, what should be the status rejection message?The FIX matrices have an example for a scenario similar to (2) but not
quite the same. It does not show an Order Status for the original
clOrdId after it had been replaced twice…Any thoughts would be appreciated …
Cheers,
Andrew
Andrew,
In scenario 1, the CancelReplace(Z,X) should be rejected since the CancelReplace(Y,X) was successfully replaced. You can use a Cancel Reject (Z,X) with a Cancel Reject Reason of 1, unknown order, since there’s no value for “Cancel or Replace Accept status”. This scenario is similar to D.2.d of the 4.4 Order State Matrices.
In scenario 2, the client should not be able to issue Order Status (X) since CancelReplace(Z,Y) has already been successfully replaced. You can use MsgType=j, BusinessMessageReject with Business Reject Reason (tag 380) value of 1, unknown ID or 0 (“Other”). ClOrdId X isn’t valid anymore if you assume the replace was successful.
FIX is very flexible and I have seen brokers that would handle both scenarios and not reject it. From my experience with the newer systems, only the last ClOrdID is valid. Please check with your counter parties and see if they adhere to the specification or if they are flexible with the scenarios.
Chris Zhong
TransactTools
Hello,
I am having a hard time formulating the proper behaviour in a couple
of CancelReplace and Order Status scenarios. I could not find any
guidelines nor example of transitions in any of the FIX spec matrices
so I would appreciate any of your thoughts.Assume that replace was successfull in all cases.
Scenario 1:
New Order(X)
…
CancelReplace(Y,X)Q: Should the client be able to issue subsequent CancelReplace(Z,X)?
If so, what the heck happens to Order(Y) ? My logic dictates, that
CancelReplace(Z,X) should be rejected, but with what message and
with what clOrdId,origClOrdId pair?Scenario 2:
New Order(X)
…
CancelReplace(Y,X) CancelReplace(Z,Y)R: Should the client be able to issue Order Status(X) at this point?
If so, what should be the response with what clOrdId,origClOrdId
pair? If not, what should be the status rejection message?The FIX matrices have an example for a scenario similar to (2) but not
quite the same. It does not show an Order Status for the original
clOrdId after it had been replaced twice…Any thoughts would be appreciated …
Cheers,
Andrew
Andrew,
In scenario 1, the CancelReplace(Z,X) should be rejected since the
CancelReplace(Y,X) was successfully replaced. You can use a Cancel
Reject (Z,X) with a Cancel Reject Reason of 1, unknown order, since
there’s no value for “Cancel or Replace Accept status”. This scenario is
similar to D.2.d of the 4.4 Order State Matrices.In scenario 2, the client should not be able to issue Order Status (X)
since CancelReplace(Z,Y) has already been successfully replaced. You can
use MsgType=j, BusinessMessageReject with Business Reject Reason (tag
380) value of 1, unknown ID or 0 (“Other”). ClOrdId X isn’t valid
anymore if you assume the replace was successful.FIX is very flexible and I have seen brokers that would handle both
scenarios and not reject it. From my experience with the newer systems,
only the last ClOrdID is valid. Please check with your counter parties
and see if they adhere to the specification or if they are flexible with
the scenarios.Chris Zhong TransactTools
Chris,
Thank you very much for replying and making a good recommendation. You did confirm what I was thinking about in both scenarios.
The basic idea is that we will be maintaining at most 2 client order ids (X,Y) per an actual order at any point in time and we will not be allowing a new cancel or cancel-replace while a transition is pending.
While in transition, the client should be able to query for status using either X or Y - this is logical. However, after transition is accepted and confirmed by the sell side, we will wipe out the origClOrdId (X) in our system leaving the new clOrdId(Y) as the the only order identifier exposing the actual order to the client - consequently, they will be able to do OrderStatus (Y) but not OrderStatus(X), which we plan to reject with a business level reject, as you recommend.
For the scenario (1), any cancel(X) or cancel-replace(X) after transition is accepted and confirmed will be rejected by us because the actual order can be found only using (Y).
This is actually gelling and looking feasible to implement into a coherent and robust engine.
Thanks for your thoughts.
Andrew
[ original email was from Anshuman Das - anshuad@yahoo.com ]
> > > Hello,
I am having a hard time formulating the proper behaviour in a couple
of CancelReplace and Order Status scenarios. I could not find any
guidelines nor example of transitions in any of the FIX spec
matrices so I would appreciate any of your thoughts.Assume that replace was successfull in all cases.
Scenario 1:
New Order(X)
…
CancelReplace(Y,X)Q: Should the client be able to issue subsequent CancelReplace(Z,X)?
If so, what the heck happens to Order(Y) ? My logic dictates,
that CancelReplace(Z,X) should be rejected, but with what message
and with what clOrdId,origClOrdId pair?Scenario 2:
New Order(X)
…
CancelReplace(Y,X) CancelReplace(Z,Y)R: Should the client be able to issue Order Status(X) at this point?
If so, what should be the response with what clOrdId,origClOrdId
pair? If not, what should be the status rejection message?The FIX matrices have an example for a scenario similar to (2) but
not quite the same. It does not show an Order Status for the
original clOrdId after it had been replaced twice…Any thoughts would be appreciated …
Cheers,
Andrew
Andrew,
In scenario 1, the CancelReplace(Z,X) should be rejected since the
CancelReplace(Y,X) was successfully replaced. You can use a Cancel
Reject (Z,X) with a Cancel Reject Reason of 1, unknown order, since
there’s no value for “Cancel or Replace Accept status”. This scenario
is similar to D.2.d of the 4.4 Order State Matrices.In scenario 2, the client should not be able to issue Order Status
(X) since CancelReplace(Z,Y) has already been successfully replaced.
You can use MsgType=j, BusinessMessageReject with Business Reject
Reason (tag
380) value of 1, unknown ID or 0 (“Other”). ClOrdId X isn’t valid
anymore if you assume the replace was successful.FIX is very flexible and I have seen brokers that would handle both
scenarios and not reject it. From my experience with the newer
systems, only the last ClOrdID is valid. Please check with your
counter parties and see if they adhere to the specification or if they
are flexible with the scenarios.Chris Zhong TransactTools
Chris,
Thank you very much for replying and making a good recommendation. You
did confirm what I was thinking about in both scenarios.The basic idea is that we will be maintaining at most 2 client order ids
(X,Y) per an actual order at any point in time and we will not be
allowing a new cancel or cancel-replace while a transition is pending.
While in transition, the client should be able to query for status using
either X or Y - this is logical. However, after transition is accepted
and confirmed by the sell side, we will wipe out the origClOrdId (X) in
our system leaving the new clOrdId(Y) as the the only order identifier
exposing the actual order to the client - consequently, they will be
able to do OrderStatus (Y) but not OrderStatus(X), which we plan to
reject with a business level reject, as you recommend.For the scenario (1), any cancel(X) or cancel-replace(X) after
transition is accepted and confirmed will be rejected by us because the
actual order can be found only using (Y).This is actually gelling and looking feasible to implement into a
coherent and robust engine.Thanks for your thoughts.
Andrew
Hi,
I wish to know what happens when the client order has come in but we have not sent them an order id from our side (i.e., we have not yet accepted it) and the client then sends in a replace message. Should the replacement automatically be accepted or should it wait until the original order is accepted and then we accept the replace request.
Thanks,
AD
[ original email was from Kevin English - kevin.english@citigroup.com ]
> > > > Hello,
I am having a hard time formulating the proper behaviour in a
couple of CancelReplace and Order Status scenarios. I could not
find any guidelines nor example of transitions in any of the FIX
spec matrices so I would appreciate any of your thoughts.Assume that replace was successfull in all cases.
Scenario 1:
New Order(X)
…
CancelReplace(Y,X)Q: Should the client be able to issue subsequent
CancelReplace(Z,X)? If so, what the heck happens to Order(Y) ?
My logic dictates, that CancelReplace(Z,X) should be rejected,
but with what message and with what clOrdId,origClOrdId pair?Scenario 2:
New Order(X)
…
CancelReplace(Y,X) CancelReplace(Z,Y)R: Should the client be able to issue Order Status(X) at this
point? If so, what should be the response with what
clOrdId,origClOrdId pair? If not, what should be the status
rejection message?The FIX matrices have an example for a scenario similar to (2) but
not quite the same. It does not show an Order Status for the
original clOrdId after it had been replaced twice…Any thoughts would be appreciated …
Cheers,
Andrew
Andrew,
In scenario 1, the CancelReplace(Z,X) should be rejected since the
CancelReplace(Y,X) was successfully replaced. You can use a Cancel
Reject (Z,X) with a Cancel Reject Reason of 1, unknown order, since
there’s no value for “Cancel or Replace Accept status”. This
scenario is similar to D.2.d of the 4.4 Order State Matrices.In scenario 2, the client should not be able to issue Order Status
(X) since CancelReplace(Z,Y) has already been successfully replaced.
You can use MsgType=j, BusinessMessageReject with Business
Reject Reason (tag
380) value of 1, unknown ID or 0 (“Other”). ClOrdId X isn’t valid
anymore if you assume the replace was successful.FIX is very flexible and I have seen brokers that would handle both
scenarios and not reject it. From my experience with the newer
systems, only the last ClOrdID is valid. Please check with your
counter parties and see if they adhere to the specification or if
they are flexible with the scenarios.Chris Zhong TransactTools
Chris,
Thank you very much for replying and making a good recommendation. You
did confirm what I was thinking about in both scenarios.The basic idea is that we will be maintaining at most 2 client order
ids (X,Y) per an actual order at any point in time and we will not be
allowing a new cancel or cancel-replace while a transition is pending.
While in transition, the client should be able to query for status
using either X or Y - this is logical. However, after transition is
accepted and confirmed by the sell side, we will wipe out the
origClOrdId (X) in our system leaving the new clOrdId(Y) as the the
only order identifier exposing the actual order to the client -
consequently, they will be able to do OrderStatus (Y) but not
OrderStatus(X), which we plan to reject with a business level reject,
as you recommend.For the scenario (1), any cancel(X) or cancel-replace(X) after
transition is accepted and confirmed will be rejected by us because
the actual order can be found only using (Y).This is actually gelling and looking feasible to implement into a
coherent and robust engine.Thanks for your thoughts.
Andrew
Hi, I wish to know what happens when the client order has come in but we
have not sent them an order id from our side (i.e., we have not yet
accepted it) and the client then sends in a replace message. Should the
replacement automatically be accepted or should it wait until the
original order is accepted and then we accept the replace request.
Thanks, AD
Hi AD,
These messages must be processed in order, therefore you cannot
‘accept’ the cancel replace until the new order single has been
accepted first.
cheers,
Kevin
Hello,
I am having a hard time formulating the proper behaviour in a
couple of CancelReplace and Order Status scenarios. I could not
find any guidelines nor example of transitions in any of the FIX
spec matrices so I would appreciate any of your thoughts.Assume that replace was successfull in all cases.
Scenario 1:
New Order(X)
…
CancelReplace(Y,X)Q: Should the client be able to issue subsequent
CancelReplace(Z,X)? If so, what the heck happens to Order(Y)
? My logic dictates, that CancelReplace(Z,X) should be
rejected, but with what message and with what
clOrdId,origClOrdId pair?Scenario 2:
New Order(X)
…
CancelReplace(Y,X) CancelReplace(Z,Y)R: Should the client be able to issue Order Status(X) at this
point? If so, what should be the response with what
clOrdId,origClOrdId pair? If not, what should be the status
rejection message?The FIX matrices have an example for a scenario similar to (2)
but not quite the same. It does not show an Order Status for the
original clOrdId after it had been replaced twice…Any thoughts would be appreciated …
Cheers,
Andrew
Andrew,
In scenario 1, the CancelReplace(Z,X) should be rejected since the
CancelReplace(Y,X) was successfully replaced. You can use a Cancel
Reject (Z,X) with a Cancel Reject Reason of 1, unknown order,
since there’s no value for “Cancel or Replace Accept status”. This
scenario is similar to D.2.d of the 4.4 Order State Matrices.In scenario 2, the client should not be able to issue Order Status
(X) since CancelReplace(Z,Y) has already been successfully
replaced. You can use MsgType=j, BusinessMessageReject with
Business Reject Reason (tag
380) value of 1, unknown ID or 0 (“Other”). ClOrdId X isn’t valid
anymore if you assume the replace was successful.FIX is very flexible and I have seen brokers that would handle
both scenarios and not reject it. From my experience with the
newer systems, only the last ClOrdID is valid. Please check with
your counter parties and see if they adhere to the specification
or if they are flexible with the scenarios.Chris Zhong TransactTools
Chris,
Thank you very much for replying and making a good recommendation.
You did confirm what I was thinking about in both scenarios.The basic idea is that we will be maintaining at most 2 client order
ids (X,Y) per an actual order at any point in time and we will not
be allowing a new cancel or cancel-replace while a transition is
pending. While in transition, the client should be able to query for
status using either X or Y - this is logical. However, after
transition is accepted and confirmed by the sell side, we will wipe
out the origClOrdId (X) in our system leaving the new clOrdId(Y) as
the the only order identifier exposing the actual order to the
client - consequently, they will be able to do OrderStatus (Y) but
not OrderStatus(X), which we plan to reject with a business level
reject, as you recommend.For the scenario (1), any cancel(X) or cancel-replace(X) after
transition is accepted and confirmed will be rejected by us because
the actual order can be found only using (Y).This is actually gelling and looking feasible to implement into a
coherent and robust engine.Thanks for your thoughts.
Andrew
Hi, I wish to know what happens when the client order has come in but
we have not sent them an order id from our side (i.e., we have not yet
accepted it) and the client then sends in a replace message. Should
the replacement automatically be accepted or should it wait until the
original order is accepted and then we accept the replace request.
Thanks, ADHi AD, These messages must be processed in order, therefore you cannot
‘accept’ the cancel replace until the new order single has been accepted
first.
Some extra thoughts:
The “Pending New” and “Pending Replace” would fit good here. If the sell side has no order id, it could at least confirm the receipt by a “Pending New.” Then it could also confirm a Replace by a “Pending Replace.” These extra states make the situation a bit clearer.
Cheers, Jörg
[ original email was from Anshuman Das - anshuman.das@hk.abnamro.com ]
> > > > > > Hello,
I am having a hard time formulating the proper behaviour in a
couple of CancelReplace and Order Status scenarios. I could
not find any guidelines nor example of transitions in any of
the FIX spec matrices so I would appreciate any of your
thoughts.Assume that replace was successfull in all cases.
Scenario 1:
New Order(X)
…
CancelReplace(Y,X)Q: Should the client be able to issue subsequent
CancelReplace(Z,X)? If so, what the heck happens to
Order(Y) ? My logic dictates, that CancelReplace(Z,X)
should be rejected, but with what message and with what
clOrdId,origClOrdId pair?Scenario 2:
New Order(X)
…
CancelReplace(Y,X) CancelReplace(Z,Y)R: Should the client be able to issue Order Status(X) at this
point? If so, what should be the response with what
clOrdId,origClOrdId pair? If not, what should be the status
rejection message?The FIX matrices have an example for a scenario similar to (2)
but not quite the same. It does not show an Order Status for
the original clOrdId after it had been replaced twice…Any thoughts would be appreciated …
Cheers,
Andrew
Andrew,
In scenario 1, the CancelReplace(Z,X) should be rejected since
the CancelReplace(Y,X) was successfully replaced. You can use a
Cancel Reject (Z,X) with a Cancel Reject Reason of 1, unknown
order, since there’s no value for “Cancel or Replace Accept
status”. This scenario is similar to D.2.d of the 4.4 Order
State Matrices.In scenario 2, the client should not be able to issue Order
Status
(X) since CancelReplace(Z,Y) has already been successfully
replaced. You can use MsgType=j, BusinessMessageReject with
Business Reject Reason (tag
380) value of 1, unknown ID or 0 (“Other”). ClOrdId X isn’t
valid anymore if you assume the replace was successful.FIX is very flexible and I have seen brokers that would handle
both scenarios and not reject it. From my experience with the
newer systems, only the last ClOrdID is valid. Please check with
your counter parties and see if they adhere to the specification
or if they are flexible with the scenarios.Chris Zhong TransactTools
Chris,
Thank you very much for replying and making a good recommendation.
You did confirm what I was thinking about in both scenarios.The basic idea is that we will be maintaining at most 2 client
order ids (X,Y) per an actual order at any point in time and we
will not be allowing a new cancel or cancel-replace while a
transition is pending. While in transition, the client should be
able to query for status using either X or Y - this is logical.
However, after transition is accepted and confirmed by the sell
side, we will wipe out the origClOrdId (X) in our system leaving
the new clOrdId(Y) as the the only order identifier exposing the
actual order to the client - consequently, they will be able to do
OrderStatus (Y) but not OrderStatus(X), which we plan to reject
with a business level reject, as you recommend.For the scenario (1), any cancel(X) or cancel-replace(X) after
transition is accepted and confirmed will be rejected by us
because the actual order can be found only using (Y).This is actually gelling and looking feasible to implement into a
coherent and robust engine.Thanks for your thoughts.
Andrew
Hi, I wish to know what happens when the client order has come in
but we have not sent them an order id from our side (i.e., we have
not yet accepted it) and the client then sends in a replace message.
Should the replacement automatically be accepted or should it wait
until the original order is accepted and then we accept the replace
request. Thanks, ADHi AD, These messages must be processed in order, therefore you cannot
‘accept’ the cancel replace until the new order single has been
accepted first.Some extra thoughts:
The “Pending New” and “Pending Replace” would fit good here. If the sell
side has no order id, it could at least confirm the receipt by a
“Pending New.” Then it could also confirm a Replace by a “Pending
Replace.” These extra states make the situation a bit clearer.Cheers, Jörg
Thank you. 
AD