Imported from previous forum
Hi,
May I know if this is FIX compliant to receive an expire ER(150=C|39=C) and then follow up fill ER(150=F|39=2)?
Thank you.
I would assume it to be a coincidence of the two events being very close to one another and the expiry having been sent first. The fill should definitely have come first as the order lifetime ends with an expiry (or complete fill or cancel), at least in an exchange environment.
What was the reason for the expiry? Time, date,…?
Hi,
May I know if this is FIX compliant to receive an expire ER(150=C|39=C)
and then follow up fill ER(150=F|39=2)?Thank you.
[ original email was from John Prewett - jprewett@lavatrading.com ]
I think Hanno is being very “generous & understanding”.
Being less diplomatic, I would describe this as a protocol violation.
Once you have received an ExecReport(canceled) for an order, that is the end of the order. Virtually the only permissible things after that are trade busts and corrections.
When you are told the unfilled order is closed (for whatever reason), you are at liberty to send unexecuted quantity elsewhere and it can then get filled. If you subsequently receive an execution on the previous closed order, you could find yourself in an unacceptable overfill situation.
If it is acceptable to receive a fill after being told the order is closed, how much time is acceptable between these two events? A millisecond? A second? An hour? A day?
That was a rhetorical series of questions.
In my humble opinion, the answer is that it is not acceptable.
Most exchanges/ECNs that I know of would have to accept a “Don’t know trade” message and be forced to eat this late fill.
JohnP
[ original email was from Ian Hoenisch - ihoenisch@fastesp.com ]
This is a very good point. I agree that this is a serious protocol violation, but sadly it does happen in practice. I have found that it’s not often, but it does happen.
We have filters in place to catch this kind of behavior and therefore can take immediate action.
What I found is that in reality it comes down to who is bigger. I.e. you can send a DK, but if you’re the smaller fish, guess what, you get to eat it.
So to create a 100% solution, I would say it depends on your size. The bigger you are, the less you have to worry about this.
I do see that any venue who has this problem is actively working on getting rid of it, and this should disappear.
Ian
I think Hanno is being very “generous & understanding”.
Being less diplomatic, I would describe this as a protocol violation.
Once you have received an ExecReport(canceled) for an order, that is the
end of the order. Virtually the only permissible things after that are
trade busts and corrections.When you are told the unfilled order is closed (for whatever reason),
you are at liberty to send unexecuted quantity elsewhere and it can then
get filled. If you subsequently receive an execution on the previous
closed order, you could find yourself in an unacceptable overfill
situation.If it is acceptable to receive a fill after being told the order is
closed, how much time is acceptable between these two events? A
millisecond? A second? An hour? A day? That was a rhetorical series of
questions. In my humble opinion, the answer is that it is not
acceptable.Most exchanges/ECNs that I know of would have to accept a “Don’t know
trade” message and be forced to eat this late fill.JohnP
From a sell side perspective, I would like to add my experience.
When there is congestion at the exchange, we have received the cancel response before receiving the fills for the same order. In this scenario the broker had to deal with the loss arising out of this situation.
To counter this we had introduced a delay mechanism i.e. the cancel response will wait for 10 seconds in case of mismatch. During this time if we do not receive the fills from the exchange, then the cancel response will be sent back to the client.
Shakir
This is a very good point. I agree that this is a serious protocol
violation, but sadly it does happen in practice. I have found that it’s
not often, but it does happen.We have filters in place to catch this kind of behavior and therefore
can take immediate action.What I found is that in reality it comes down to who is bigger. I.e.
you can send a DK, but if you’re the smaller fish, guess what, you get
to eat it.So to create a 100% solution, I would say it depends on your size. The
bigger you are, the less you have to worry about this.I do see that any venue who has this problem is actively working on
getting rid of it, and this should disappear.Ian
I think Hanno is being very “generous & understanding”.
Being less diplomatic, I would describe this as a protocol violation.
Once you have received an ExecReport(canceled) for an order, that is
the end of the order. Virtually the only permissible things after that
are trade busts and corrections.When you are told the unfilled order is closed (for whatever reason),
you are at liberty to send unexecuted quantity elsewhere and it can
then get filled. If you subsequently receive an execution on the
previous closed order, you could find yourself in an unacceptable
overfill situation.If it is acceptable to receive a fill after being told the order is
closed, how much time is acceptable between these two events? A
millisecond? A second? An hour? A day? That was a rhetorical series of
questions. In my humble opinion, the answer is that it is not
acceptable.Most exchanges/ECNs that I know of would have to accept a “Don’t know
trade” message and be forced to eat this late fill.JohnP
Thanks all for your opinion. In fact, that is an IOC order, the expired and fills occured within a sec.
The Sellside is argue that when I received the expired message, the 151 is not equal to 0 (150=C|39=C|151=150000)!! So i should not close the order and should expect incoming fills. When the fills come after expired, it will be 150=F|39=2|151=0|32=100000.
I could not find any explaination from FIX 4.2 protocol on this. Any comments?
From a sell side perspective, I would like to add my experience. When
there is congestion at the exchange, we have received the cancel
response before receiving the fills for the same order. In this scenario
the broker had to deal with the loss arising out of this situation. To
counter this we had introduced a delay mechanism i.e. the cancel
response will wait for 10 seconds in case of mismatch. During this time
if we do not receive the fills from the exchange, then the cancel
response will be sent back to the client.Shakir
This is a very good point. I agree that this is a serious protocol
violation, but sadly it does happen in practice. I have found that
it’s not often, but it does happen.We have filters in place to catch this kind of behavior and therefore
can take immediate action.What I found is that in reality it comes down to who is bigger. I.e.
you can send a DK, but if you’re the smaller fish, guess what, you get
to eat it.So to create a 100% solution, I would say it depends on your size. The
bigger you are, the less you have to worry about this.I do see that any venue who has this problem is actively working on
getting rid of it, and this should disappear.Ian
I think Hanno is being very “generous & understanding”.
Being less diplomatic, I would describe this as a protocol
violation.Once you have received an ExecReport(canceled) for an order, that is
the end of the order. Virtually the only permissible things after
that are trade busts and corrections.When you are told the unfilled order is closed (for whatever
reason), you are at liberty to send unexecuted quantity elsewhere
and it can then get filled. If you subsequently receive an execution
on the previous closed order, you could find yourself in an
unacceptable overfill situation.If it is acceptable to receive a fill after being told the order is
closed, how much time is acceptable between these two events? A
millisecond? A second? An hour? A day? That was a rhetorical series
of questions. In my humble opinion, the answer is that it is not
acceptable.Most exchanges/ECNs that I know of would have to accept a “Don’t
know trade” message and be forced to eat this late fill.JohnP
IOC is a crucial piece of additional information. FIX Vol 4 p.87 Scenario I.1.b applies to IOC orders and states that they are to be canceled, they do not expire. We had a discussion on this in the GEMC but decided to leave FIX as is.
LeavesQty(151) can be set to zero for OrdStatus (39) Canceled or Expired nut it is not a must. Anyway, both state values indicate the end of lifetime of the order, i.e. no further execution is possible. Thus a non-zero value in LeavesQty simply means that this was the remainder of the order that was canceled. Think of the race condition when deleting orders. You might get another partial fill just when you issue the Order Cancel Request. You then lack the explicit information about the actual quantity that was left (you can calculate it however as OrderQty-CumQty). A non-zero value of LeavesQty gives you the explicit value and maintains the standard formula OrderQty=CumQty+LeavesQty.
I am convinced that you have a case where the matching system does not ensure the proper sequence of events happening in the core engine. An order cannot expire first and then be filled. It will always be the other way around. Hence, the messages to you must reflect the proper sequence. If they do not the architecture is questionable.
Fill, Cancel, Expired are terminal states of an order, a non-zero value of LeavesQty should not indicate that further executions might follow, it should only indicate any remaining quantity that could not be executed prior to the order reaching the final state.
Regards,
Hanno.
Thanks all for your opinion. In fact, that is an IOC order, the expired
and fills occured within a sec.The Sellside is argue that when I received the expired message, the 151
is not equal to 0 (150=C|39=C|151=150000)!! So i should not close the
order and should expect incoming fills. When the fills come after
expired, it will be 150=F|39=2|151=0|32=100000.I could not find any explaination from FIX 4.2 protocol on this.
Any comments?
Ally / Hanno,
I would suggest, in the case of IOC, to send the cancel from the order initiator after an “expire time” mutually agreed between parties. In this case, a DK fill would result in a “late execution” and can be reported as exceptions in your system for negotiation at the end of day. This is the approach followed by some of the popular exchanges in the USA.
Again I agree on the previous post… If you are big enough… FIX is still not sovereign enough to dictate standards to such giants. J U can get away with anything.
Rgds,
Thaya.
IOC is a crucial piece of additional information. FIX Vol 4 p.87
Scenario I.1.b applies to IOC orders and states that they are to be
canceled, they do not expire. We had a discussion on this in the GEMC
but decided to leave FIX as is.LeavesQty(151) can be set to zero for OrdStatus (39) Canceled or Expired
nut it is not a must. Anyway, both state values indicate the end of
lifetime of the order, i.e. no further execution is possible. Thus a non-
zero value in LeavesQty simply means that this was the remainder of the
order that was canceled. Think of the race condition when deleting
orders. You might get another partial fill just when you issue the Order
Cancel Request. You then lack the explicit information about the actual
quantity that was left (you can calculate it however as OrderQty-
CumQty). A non-zero value of LeavesQty gives you the explicit value and
maintains the standard formula OrderQty=CumQty+LeavesQty.I am convinced that you have a case where the matching system does not
ensure the proper sequence of events happening in the core engine. An
order cannot expire first and then be filled. It will always be the
other way around. Hence, the messages to you must reflect the proper
sequence. If they do not the architecture is questionable.Fill, Cancel, Expired are terminal states of an order, a non-zero value
of LeavesQty should not indicate that further executions might follow,
it should only indicate any remaining quantity that could not be
executed prior to the order reaching the final state.Regards, Hanno.
Thanks all for your opinion. In fact, that is an IOC order, the
expired and fills occured within a sec.The Sellside is argue that when I received the expired message, the
151 is not equal to 0 (150=C|39=C|151=150000)!! So i should not close
the order and should expect incoming fills. When the fills come after
expired, it will be 150=F|39=2|151=0|32=100000.I could not find any explaination from FIX 4.2 protocol on this. Any
comments?
I am afraid this does not apply to exchange environments. An IOC order must be canceled by the receiving side immediately after having gone through the matching engine. The initiator cannot send a cancel request if it is an IOC order. “Immediate” should not allow a bilaterally agreed expiry time (order lifetime) greater than zero.
Which exchanges follow the approach you outline? In the in interest of harmonization I would like to know more about this.
Ally / Hanno,
I would suggest, in the case of IOC, to send the cancel from the
order initiator after an “expire time” mutually agreed between
parties. In this case, a DK fill would result in a “late execution”
and can be reported as exceptions in your system for negotiation at
the end of day. This is the approach followed by some of the popular
exchanges in the USA.Again I agree on the previous post… If you are big enough… FIX is
still not sovereign enough to dictate standards to such giants. J U can
get away with anything.Rgds, Thaya.
IOC is a crucial piece of additional information. FIX Vol 4 p.87
Scenario I.1.b applies to IOC orders and states that they are to be
canceled, they do not expire. We had a discussion on this in the GEMC
but decided to leave FIX as is.LeavesQty(151) can be set to zero for OrdStatus (39) Canceled or
Expired nut it is not a must. Anyway, both state values indicate the
end of lifetime of the order, i.e. no further execution is possible.
Thus a non- zero value in LeavesQty simply means that this was the
remainder of the order that was canceled. Think of the race condition
when deleting orders. You might get another partial fill just when you
issue the Order Cancel Request. You then lack the explicit information
about the actual quantity that was left (you can calculate it however
as OrderQty- CumQty). A non-zero value of LeavesQty gives you the
explicit value and maintains the standard formula
OrderQty=CumQty+LeavesQty.I am convinced that you have a case where the matching system does not
ensure the proper sequence of events happening in the core engine. An
order cannot expire first and then be filled. It will always be the
other way around. Hence, the messages to you must reflect the proper
sequence. If they do not the architecture is questionable.Fill, Cancel, Expired are terminal states of an order, a non-zero
value of LeavesQty should not indicate that further executions might
follow, it should only indicate any remaining quantity that could not
be executed prior to the order reaching the final state.Regards, Hanno.
Thanks all for your opinion. In fact, that is an IOC order, the
expired and fills occured within a sec.The Sellside is argue that when I received the expired message, the
151 is not equal to 0 (150=C|39=C|151=150000)!! So i should not
close the order and should expect incoming fills. When the fills
come after expired, it will be 150=F|39=2|151=0|32=100000.I could not find any explaination from FIX 4.2 protocol on this. Any
comments?
Hanno,
I agree with your point on the responsibility of either executing or canceling an IOC then and there by an exchange. Literally, thats what IOC is for. But in practice, there are instances where, in exchanges, IOC orders get “stuck” and stay without any response. The mechanism that I described, is a kind of a practical work-around for this scenario. As for order initiators like order routing systems, this implies that the injector will also be stuck in aggressive phase indefinitely.
Hence agreeing on sending a cancel (from the initiator) after a defined configurable time, is a way of notifying the exchange of skipping the stuck order and proceeding to route to other venues. The injector system can either wipe out that quantity thats stuck, or re-use it, where in the latter, there is a risk of double exposure.
The cleanest way for an exchange / order input system, is to treat the IOC with respect and cancel it if it is bound to be stuck. But in general, we see IOC orders being stuck without response.
For your info AMEX’s AMOs work the way I mentioned.
Rgds,
Thaya.
I am afraid this does not apply to exchange environments. An IOC order
must be canceled by the receiving side immediately after having gone
through the matching engine. The initiator cannot send a cancel request
if it is an IOC order. “Immediate” should not allow a bilaterally agreed
expiry time (order lifetime) greater than zero.Which exchanges follow the approach you outline? In the in interest of
harmonization I would like to know more about this.Ally / Hanno,
I would suggest, in the case of IOC, to send the cancel from the order
initiator after an “expire time” mutually agreed between parties. In
this case, a DK fill would result in a “late execution” and can be
reported as exceptions in your system for negotiation at the end of
day. This is the approach followed by some of the popular exchanges in
the USA.Again I agree on the previous post… If you are big enough… FIX is
still not sovereign enough to dictate standards to such giants. J U
can get away with anything.Rgds, Thaya.
IOC is a crucial piece of additional information. FIX Vol 4 p.87
Scenario I.1.b applies to IOC orders and states that they are to be
canceled, they do not expire. We had a discussion on this in the
GEMC but decided to leave FIX as is.LeavesQty(151) can be set to zero for OrdStatus (39) Canceled or
Expired nut it is not a must. Anyway, both state values indicate the
end of lifetime of the order, i.e. no further execution is possible.
Thus a non- zero value in LeavesQty simply means that this was the
remainder of the order that was canceled. Think of the race
condition when deleting orders. You might get another partial fill
just when you issue the Order Cancel Request. You then lack the
explicit information about the actual quantity that was left (you
can calculate it however as OrderQty- CumQty). A non-zero value of
LeavesQty gives you the explicit value and maintains the standard
formula OrderQty=CumQty+LeavesQty.I am convinced that you have a case where the matching system does
not ensure the proper sequence of events happening in the core
engine. An order cannot expire first and then be filled. It will
always be the other way around. Hence, the messages to you must
reflect the proper sequence. If they do not the architecture is
questionable.Fill, Cancel, Expired are terminal states of an order, a non-zero
value of LeavesQty should not indicate that further executions might
follow, it should only indicate any remaining quantity that could
not be executed prior to the order reaching the final state.Regards, Hanno.
Thanks all for your opinion. In fact, that is an IOC order, the
expired and fills occured within a sec.The Sellside is argue that when I received the expired message,
the 151 is not equal to 0 (150=C|39=C|151=150000)!! So i should
not close the order and should expect incoming fills. When the
fills come after expired, it will be 150=F|39=2|151=0|32=100000.I could not find any explaination from FIX 4.2 protocol on this.
Any comments?
I see you point, I would like to be strict on the term IOC as sth that does require an immediate response. This would imply that such orders cannot be routed away to another market and need to be filled at the local BBO. The AMO examples of the Amex only include limit orders, where you get a Cancel Queued message while the order is locked and trading at another market. Are you sure IOC orders are subject to away market trading?
Regards,
Hanno.
Hanno,
I agree with your point on the responsibility of either executing or
canceling an IOC then and there by an exchange. Literally, thats what
IOC is for. But in practice, there are instances where, in exchanges,
IOC orders get “stuck” and stay without any response. The mechanism that
I described, is a kind of a practical work-around for this scenario. As
for order initiators like order routing systems, this implies that the
injector will also be stuck in aggressive phase indefinitely.Hence agreeing on sending a cancel (from the initiator) after a defined
configurable time, is a way of notifying the exchange of skipping the
stuck order and proceeding to route to other venues. The injector system
can either wipe out that quantity thats stuck, or re-use it, where in
the latter, there is a risk of double exposure.The cleanest way for an exchange / order input system, is to treat the
IOC with respect and cancel it if it is bound to be stuck. But in
general, we see IOC orders being stuck without response.For your info AMEX’s AMOs work the way I mentioned.
Rgds, Thaya.
I am afraid this does not apply to exchange environments. An IOC order
must be canceled by the receiving side immediately after having gone
through the matching engine. The initiator cannot send a cancel
request if it is an IOC order. “Immediate” should not allow a
bilaterally agreed expiry time (order lifetime) greater than zero.Which exchanges follow the approach you outline? In the in interest of
harmonization I would like to know more about this.Ally / Hanno,
I would suggest, in the case of IOC, to send the cancel from the
order initiator after an “expire time” mutually agreed between
parties. In this case, a DK fill would result in a “late execution”
and can be reported as exceptions in your system for negotiation at
the end of day. This is the approach followed by some of the popular
exchanges in the USA.Again I agree on the previous post… If you are big enough… FIX is
still not sovereign enough to dictate standards to such giants. J U
can get away with anything.Rgds, Thaya.
IOC is a crucial piece of additional information. FIX Vol 4 p.87
Scenario I.1.b applies to IOC orders and states that they are to
be canceled, they do not expire. We had a discussion on this in
the GEMC but decided to leave FIX as is.LeavesQty(151) can be set to zero for OrdStatus (39) Canceled or
Expired nut it is not a must. Anyway, both state values indicate
the end of lifetime of the order, i.e. no further execution is
possible. Thus a non- zero value in LeavesQty simply means that
this was the remainder of the order that was canceled. Think of
the race condition when deleting orders. You might get another
partial fill just when you issue the Order Cancel Request. You
then lack the explicit information about the actual quantity that
was left (you can calculate it however as OrderQty- CumQty). A non-
zero value of LeavesQty gives you the explicit value and maintains
the standard formula OrderQty=CumQty+LeavesQty.I am convinced that you have a case where the matching system does
not ensure the proper sequence of events happening in the core
engine. An order cannot expire first and then be filled. It will
always be the other way around. Hence, the messages to you must
reflect the proper sequence. If they do not the architecture is
questionable.Fill, Cancel, Expired are terminal states of an order, a non-zero
value of LeavesQty should not indicate that further executions
might follow, it should only indicate any remaining quantity that
could not be executed prior to the order reaching the final state.Regards, Hanno.
Thanks all for your opinion. In fact, that is an IOC order, the
expired and fills occured within a sec.The Sellside is argue that when I received the expired message,
the 151 is not equal to 0 (150=C|39=C|151=150000)!! So i should
not close the order and should expect incoming fills. When the
fills come after expired, it will be 150=F|39=2|151=0|32=100000.I could not find any explaination from FIX 4.2 protocol on this.
Any comments?
Hi Hanno,
An input IOC to an exchange will not be away routed. But a normal input limit order (Day / GTD) can be away routed from an exchange / order router with TIF = IOC (Since the routing is based on valid market picture). For this away routing, the exchange / order router maintains an expiration timer and when its encountered, sends out a cancel, if no responses were received in-between. This is merely a practical way of relieving from the double exposure responsibility. Manual procedures at the EOD make sure that such late or DK executions are rectified.
Rgds,
Thaya.
I see you point, I would like to be strict on the term IOC as sth that
does require an immediate response. This would imply that such orders
cannot be routed away to another market and need to be filled at the
local BBO. The AMO examples of the Amex only include limit orders,
where you get a Cancel Queued message while the order is locked and
trading at another market. Are you sure IOC orders are subject to away
market trading?Regards, Hanno.
Hanno,
I agree with your point on the responsibility of either executing or
canceling an IOC then and there by an exchange. Literally, thats what
IOC is for. But in practice, there are instances where, in exchanges,
IOC orders get “stuck” and stay without any response. The mechanism
that I described, is a kind of a practical work-around for this
scenario. As for order initiators like order routing systems, this
implies that the injector will also be stuck in aggressive phase
indefinitely.Hence agreeing on sending a cancel (from the initiator) after a
defined configurable time, is a way of notifying the exchange of
skipping the stuck order and proceeding to route to other venues. The
injector system can either wipe out that quantity thats stuck, or re-
use it, where in the latter, there is a risk of double exposure.The cleanest way for an exchange / order input system, is to treat the
IOC with respect and cancel it if it is bound to be stuck. But in
general, we see IOC orders being stuck without response.For your info AMEX’s AMOs work the way I mentioned.
Rgds, Thaya.
I am afraid this does not apply to exchange environments. An IOC
order must be canceled by the receiving side immediately after
having gone through the matching engine. The initiator cannot send a
cancel request if it is an IOC order. “Immediate” should not allow a
bilaterally agreed expiry time (order lifetime) greater than zero.Which exchanges follow the approach you outline? In the in interest
of harmonization I would like to know more about this.Ally / Hanno,
I would suggest, in the case of IOC, to send the cancel from the
order initiator after an “expire time” mutually agreed between
parties. In this case, a DK fill would result in a “late
execution” and can be reported as exceptions in your system for
negotiation at the end of day. This is the approach followed by
some of the popular exchanges in the USA.Again I agree on the previous post… If you are big enough… FIX
is still not sovereign enough to dictate standards to such giants.
J U can get away with anything.Rgds, Thaya.
IOC is a crucial piece of additional information. FIX Vol 4 p.87
Scenario I.1.b applies to IOC orders and states that they are to
be canceled, they do not expire. We had a discussion on this in
the GEMC but decided to leave FIX as is.LeavesQty(151) can be set to zero for OrdStatus (39) Canceled or
Expired nut it is not a must. Anyway, both state values indicate
the end of lifetime of the order, i.e. no further execution is
possible. Thus a non- zero value in LeavesQty simply means that
this was the remainder of the order that was canceled. Think of
the race condition when deleting orders. You might get another
partial fill just when you issue the Order Cancel Request. You
then lack the explicit information about the actual quantity
that was left (you can calculate it however as OrderQty-
CumQty). A non- zero value of LeavesQty gives you the explicit
value and maintains the standard formula
OrderQty=CumQty+LeavesQty.I am convinced that you have a case where the matching system
does not ensure the proper sequence of events happening in the
core engine. An order cannot expire first and then be filled. It
will always be the other way around. Hence, the messages to you
must reflect the proper sequence. If they do not the
architecture is questionable.Fill, Cancel, Expired are terminal states of an order, a non-
zero value of LeavesQty should not indicate that further
executions might follow, it should only indicate any remaining
quantity that could not be executed prior to the order reaching
the final state.Regards, Hanno.
Thanks all for your opinion. In fact, that is an IOC order,
the expired and fills occured within a sec.The Sellside is argue that when I received the expired
message, the 151 is not equal to 0 (150=C|39=C|151=150000)!!
So i should not close the order and should expect incoming
fills. When the fills come after expired, it will be
150=F|39=2|151=0|32=100000.I could not find any explaination from FIX 4.2 protocol on
this. Any comments?