Imported from previous forum
Hi,
FIX4.4
I’ve got the following use case:
client: NewOrder(X), qty=1000
client: OrderCancelReplaceRequest(Y,X), qty=900
client: OrderCancelReplaceRequest(Z,Y), qty=800
broker: ???
Q1: does client send the correct chain of requests?
Q2: if Q1 is “yes” then what are the possible responses from the server?
Thanks in advance.
The broker will not wait to see if further requests come in and process each request as it comes. Unless there are rejections or fills in between, the immediacy of Cancel/Replace requests should not matter. However, if the first Cancel/Replace request is rejected, then Y does not become a valid ClOrdID. Equally, if 1000 are filled prior to the first Cancel/Replace request (or 900 prior to the second), then the qty cannot be reduced to the desired value.
Have a look at the spec Volume 4, message scenarios C and D, starting on page 52, specifically D.2 starting on page 61. Hope you find enough answers there. Details can get quite complex.
Hi,
FIX4.4 I’ve got the following use case:
client: NewOrder(X), qty=1000 client: OrderCancelReplaceRequest(Y,X),
qty=900 client: OrderCancelReplaceRequest(Z,Y), qty=800 broker: ???Q1: does client send the correct chain of requests?
Q2: if Q1 is “yes” then what are the possible responses from the server?Thanks in advance.
Thanks for your answer.
I looked through the Vol4, scenarious C,D, however they didn’t match my scenario. C, D describe the situation when a client has received Execution-New(X) before he sends Replace.
I’d say that cases B.1.d and B.1.e are close to me case except CancelRequest should be replaced with one or several Replace requests.
Such cases are not described in FIX specs and therefore I wonder if they are allowed by the spec and what are broker’s responses.
The broker will not wait to see if further requests come in and process
each request as it comes. Unless there are rejections or fills in
between, the immediacy of Cancel/Replace requests should not matter.
However, if the first Cancel/Replace request is rejected, then Y does
not become a valid ClOrdID. Equally, if 1000 are filled prior to the
first Cancel/Replace request (or 900 prior to the second), then the qty
cannot be reduced to the desired value.Have a look at the spec Volume 4, message scenarios C and D, starting on
page 52, specifically D.2 starting on page 61. Hope you find enough
answers there. Details can get quite complex.Hi,
FIX4.4 I’ve got the following use case:
client: NewOrder(X), qty=1000 client: OrderCancelReplaceRequest(Y,X),
qty=900 client: OrderCancelReplaceRequest(Z,Y), qty=800 broker: ???Q1: does client send the correct chain of requests?
Q2: if Q1 is “yes” then what are the possible responses from the
server?Thanks in advance.
Have a look at D.2.a where two replace requests come after one another. They are both successful and the broker processes one after the other.
Sending requests prior to receiving an answer is definitely allowed in FIX. ClOrdID is the key field allowing you to do that.
The client just has to be prepared for the type of response he will get from the broker. The responses will differ if rejects or fills are involved.
Does that answer your question?
Thanks for your answer.
I looked through the Vol4, scenarious C,D, however they didn’t match my
scenario. C, D describe the situation when a client has received Execution-
New(X) before he sends Replace. I’d say that cases B.1.d and B.1.e are
close to me case except CancelRequest should be replaced with one or
several Replace requests. Such cases are not described in FIX specs and
therefore I wonder if they are allowed by the spec and what are broker’s
responses.The broker will not wait to see if further requests come in and
process each request as it comes. Unless there are rejections or fills
in between, the immediacy of Cancel/Replace requests should not
matter. However, if the first Cancel/Replace request is rejected, then
Y does not become a valid ClOrdID. Equally, if 1000 are filled prior
to the first Cancel/Replace request (or 900 prior to the second), then
the qty cannot be reduced to the desired value.Have a look at the spec Volume 4, message scenarios C and D, starting
on page 52, specifically D.2 starting on page 61. Hope you find enough
answers there. Details can get quite complex.Hi,
FIX4.4 I’ve got the following use case:
client: NewOrder(X), qty=1000 client:
OrderCancelReplaceRequest(Y,X), qty=900 client:
OrderCancelReplaceRequest(Z,Y), qty=800 broker: ???Q1: does client send the correct chain of requests?
Q2: if Q1 is “yes” then what are the possible responses from the
server?Thanks in advance.
Yes, sure, but
is sending replace requests prior to receiving ack on NewOrder allowed by FIX?
D describes only cases when replace requests are sent after ack on NewOrder had been received.
Have a look at D.2.a where two replace requests come after one another.
They are both successful and the broker processes one after the other.Sending requests prior to receiving an answer is definitely allowed in
FIX. ClOrdID is the key field allowing you to do that.The client just has to be prepared for the type of response he will
get from the broker. The responses will differ if rejects or fills
are involved.Does that answer your question?
Thanks for your answer.
I looked through the Vol4, scenarious C,D, however they didn’t match
my scenario. C, D describe the situation when a client has received
Execution- New(X) before he sends Replace. I’d say that cases B.1.d
and B.1.e are close to me case except CancelRequest should be replaced
with one or several Replace requests. Such cases are not described in
FIX specs and therefore I wonder if they are allowed by the spec and
what are broker’s responses.The broker will not wait to see if further requests come in and
process each request as it comes. Unless there are rejections or
fills in between, the immediacy of Cancel/Replace requests should
not matter. However, if the first Cancel/Replace request is
rejected, then Y does not become a valid ClOrdID. Equally, if 1000
are filled prior to the first Cancel/Replace request (or 900 prior
to the second), then the qty cannot be reduced to the desired value.Have a look at the spec Volume 4, message scenarios C and D,
starting on page 52, specifically D.2 starting on page 61. Hope you
find enough answers there. Details can get quite complex.Hi,
FIX4.4 I’ve got the following use case:
client: NewOrder(X), qty=1000 client:
OrderCancelReplaceRequest(Y,X), qty=900 client:
OrderCancelReplaceRequest(Z,Y), qty=800 broker: ???Q1: does client send the correct chain of requests?
Q2: if Q1 is “yes” then what are the possible responses from the
server?Thanks in advance.
I am aware of the fact that your scenario is not shown 100% in the scenarios. I was suggesting to abstract from that a little bit to see the concepts behind the details. It is impossible to spell out every possible scenario.
I see no reason to allow a second Cancel/Replace w/o Ack of the first one but to not allow Cancel/Replace w/o an Ack of the New.
So my answer is still yes, it is allowed. The only way to prevent it is to disallow ClOrdID and to mandate OrderID as a way to reference an order. Then you have no chance to modify the order because you do not know how to reference it prior to getting an Ack. Some exchanges have done so in the past or are still doing so. FIX is more flexible here and allows you to delete an order a nanosecond after you have sent off the request to enter it. If the entry is rejected you will get an “order not found” or sth similar so that is why your application needs to be prepared for various responses.
Yes, sure, but
is sending replace requests prior to receiving ack on NewOrder
allowed by FIX?D describes only cases when replace requests are sent after ack on
NewOrder had been received.Have a look at D.2.a where two replace requests come after one
another. They are both successful and the broker processes one after
the other.Sending requests prior to receiving an answer is definitely allowed in
FIX. ClOrdID is the key field allowing you to do that.The client just has to be prepared for the type of response he will
get from the broker. The responses will differ if rejects or fills are
involved.Does that answer your question?
Thanks for your answer.
I looked through the Vol4, scenarious C,D, however they didn’t match
my scenario. C, D describe the situation when a client has received
Execution- New(X) before he sends Replace. I’d say that cases B.1.d
and B.1.e are close to me case except CancelRequest should be
replaced with one or several Replace requests. Such cases are not
described in FIX specs and therefore I wonder if they are allowed by
the spec and what are broker’s responses.The broker will not wait to see if further requests come in and
process each request as it comes. Unless there are rejections or
fills in between, the immediacy of Cancel/Replace requests should
not matter. However, if the first Cancel/Replace request is
rejected, then Y does not become a valid ClOrdID. Equally, if 1000
are filled prior to the first Cancel/Replace request (or 900 prior
to the second), then the qty cannot be reduced to the desired
value.Have a look at the spec Volume 4, message scenarios C and D,
starting on page 52, specifically D.2 starting on page 61. Hope
you find enough answers there. Details can get quite complex.Hi,
FIX4.4 I’ve got the following use case:
client: NewOrder(X), qty=1000 client:
OrderCancelReplaceRequest(Y,X), qty=900 client:
OrderCancelReplaceRequest(Z,Y), qty=800 broker: ???Q1: does client send the correct chain of requests?
Q2: if Q1 is “yes” then what are the possible responses from the
server?Thanks in advance.
Hi there
The OrigClOrdID<41> sent by the client should match the ClOrdID<11> of the last accepted amend, or in the case of an order that has not been amended, the ClOrdID<11> of the original order. This requirement presents a dilemma for the client when they do not wait for acknowledgments. Let’s imagine a scenario whereby the broker and client process messages on a single thread and in strictly first in first out queuing (and borrowing your notation):
This is the obvious base case, which presents no issues, as the client waits for an amend ack:
→ Order X
← Ack X
→ Amend Y,X
← Ack Y
→ Amend Z,Y
← Ack Z
Now if the client doesn’t wait for an amend ack:
→ Order X
→ Amend Y,X
→ Amend Z,Y
If the broker processes the messages in order, and both the order and first amend are accepted, the second amend should also be accepted. However, there is a school of thought that suggests the client should really be sending Z,X for the second amend, as the first one has not yet been accepted, and OrigClOrdID<41> should match ‘the last accepted amend, or new order if no amends accepted’.
Personally, I would ignore the strict protocol definition and use Z,Y - especially if the following two things are true:
-
I can confirm that the broker will process the amends on a single thread, in order of arrival.
-
I have a good chance that the previous amend Y will be accepted (for example, the order originates from a strategy that doesn’t send more than a few ticks away from best bid/offer).
All I’m doing in this scenario is preempting what the correct OrigClOrdID will be at the time of processing, even if at the time of sending it is wrong.
As per point 2 though - it really does hang on amend Y,X being accepted. If it is rejected, then Z,Y will also be rejected, as the broker will expect Z,X.
I am aware of the fact that your scenario is not shown 100% in the
scenarios. I was suggesting to abstract from that a little bit to see
the concepts behind the details. It is impossible to spell out every
possible scenario.I see no reason to allow a second Cancel/Replace w/o Ack of the first
one but to not allow Cancel/Replace w/o an Ack of the New.So my answer is still yes, it is allowed. The only way to prevent it is
to disallow ClOrdID and to mandate OrderID as a way to reference an
order. Then you have no chance to modify the order because you do not
know how to reference it prior to getting an Ack. Some exchanges have
done so in the past or are still doing so. FIX is more flexible here and
allows you to delete an order a nanosecond after you have sent off the
request to enter it. If the entry is rejected you will get an “order not
found” or sth similar so that is why your application needs to be
prepared for various responses.Yes, sure, but
is sending replace requests prior to receiving ack on NewOrder
allowed by FIX?D describes only cases when replace requests are sent after ack on
NewOrder had been received.Have a look at D.2.a where two replace requests come after one
another. They are both successful and the broker processes one after
the other.Sending requests prior to receiving an answer is definitely allowed
in FIX. ClOrdID is the key field allowing you to do that.The client just has to be prepared for the type of response he will
get from the broker. The responses will differ if rejects or fills
are involved.Does that answer your question?
Thanks for your answer.
I looked through the Vol4, scenarious C,D, however they didn’t
match my scenario. C, D describe the situation when a client has
received Execution- New(X) before he sends Replace. I’d say that
cases B.1.d and B.1.e are close to me case except CancelRequest
should be replaced with one or several Replace requests. Such
cases are not described in FIX specs and therefore I wonder if
they are allowed by the spec and what are broker’s responses.The broker will not wait to see if further requests come in and
process each request as it comes. Unless there are rejections or
fills in between, the immediacy of Cancel/Replace requests
should not matter. However, if the first Cancel/Replace request
is rejected, then Y does not become a valid ClOrdID. Equally, if
1000 are filled prior to the first Cancel/Replace request (or
900 prior to the second), then the qty cannot be reduced to the
desired value.Have a look at the spec Volume 4, message scenarios C and D,
starting on page 52, specifically D.2 starting on page 61. Hope
you find enough answers there. Details can get quite complex.Hi,
FIX4.4 I’ve got the following use case:
client: NewOrder(X), qty=1000 client:
OrderCancelReplaceRequest(Y,X), qty=900 client:
OrderCancelReplaceRequest(Z,Y), qty=800 broker: ???Q1: does client send the correct chain of requests?
Q2: if Q1 is “yes” then what are the possible responses from
the server?Thanks in advance.
I have seen this scenario (amend before receiving the first ack) treated as a valid possibility in a project. The client system could do it. The implementation choice made was to reject the amend.
I am aware of the fact that your scenario is not shown 100% in the
scenarios. I was suggesting to abstract from that a little bit to see
the concepts behind the details. It is impossible to spell out every
possible scenario.I see no reason to allow a second Cancel/Replace w/o Ack of the first
one but to not allow Cancel/Replace w/o an Ack of the New.So my answer is still yes, it is allowed. The only way to prevent it is
to disallow ClOrdID and to mandate OrderID as a way to reference an
order. Then you have no chance to modify the order because you do not
know how to reference it prior to getting an Ack. Some exchanges have
done so in the past or are still doing so. FIX is more flexible here and
allows you to delete an order a nanosecond after you have sent off the
request to enter it. If the entry is rejected you will get an “order not
found” or sth similar so that is why your application needs to be
prepared for various responses.Yes, sure, but
is sending replace requests prior to receiving ack on NewOrder
allowed by FIX?D describes only cases when replace requests are sent after ack on
NewOrder had been received.Have a look at D.2.a where two replace requests come after one
another. They are both successful and the broker processes one after
the other.Sending requests prior to receiving an answer is definitely allowed
in FIX. ClOrdID is the key field allowing you to do that.The client just has to be prepared for the type of response he will
get from the broker. The responses will differ if rejects or fills
are involved.Does that answer your question?
Thanks for your answer.
I looked through the Vol4, scenarious C,D, however they didn’t
match my scenario. C, D describe the situation when a client has
received Execution- New(X) before he sends Replace. I’d say that
cases B.1.d and B.1.e are close to me case except CancelRequest
should be replaced with one or several Replace requests. Such
cases are not described in FIX specs and therefore I wonder if
they are allowed by the spec and what are broker’s responses.The broker will not wait to see if further requests come in and
process each request as it comes. Unless there are rejections or
fills in between, the immediacy of Cancel/Replace requests
should not matter. However, if the first Cancel/Replace request
is rejected, then Y does not become a valid ClOrdID. Equally, if
1000 are filled prior to the first Cancel/Replace request (or
900 prior to the second), then the qty cannot be reduced to the
desired value.Have a look at the spec Volume 4, message scenarios C and D,
starting on page 52, specifically D.2 starting on page 61. Hope
you find enough answers there. Details can get quite complex.Hi,
FIX4.4 I’ve got the following use case:
client: NewOrder(X), qty=1000 client:
OrderCancelReplaceRequest(Y,X), qty=900 client:
OrderCancelReplaceRequest(Z,Y), qty=800 broker: ???Q1: does client send the correct chain of requests?
Q2: if Q1 is “yes” then what are the possible responses from
the server?Thanks in advance.