CumQty decreases between REPLACE and PARTIAL_FILL

, ,
1

Imported from previous forum

2

Hi,

We have seen an interesting behavior on CME recently: the tag CumQty decreased between execution reports with REPLACE and PARTIAL_FILL.

CME support clarified that it is an intentional deviation from FIX spec, which might actually be very helpful for buy sides that would like to know the latest order state as soon as possible in the chain of order updates.

Scenario:

  • order 17@A is accepted
  • client issues replace request with the new price B
  • venue replies with ExecType=REPLACE OrdStatus=REPLACED LeavesQty=0 CumQty=17 price=B
  • venue replies with ExecType=PARTIAL_FILL OrdStatus=PARTIALLY_FILLED LeavesQty=15 CumQty=2 LastQty=2 price=B (note, CumQty decreased, LeavesQty went from 0 to 15)
  • … another partial fill
  • venue replies with ExecType=FILL OrdStatus=FILLED LeavesQty=0 CumQty=17 LastQty=10 price=B

I am just curious if this is indeed a FIX deviation or something that may happen at other venues as well, that is, quite common practice?

What is your experience?

Thanks in advance,
Igor

3

Igor, are you sure that LastQty is 10 and not 15 in your final bullet (ExecType=FILL)? The numbers do not seem to add up.

The requirement to send current order status information as early as possible is certainly common. The problem is to align transaction models of a core exchange matching system and FIX. Sending out multiple ExecutionReport with intermediate states that never really existed for the matcher might lead to order modification or deletion requests that are useless.

With FIX 5.0 SP1, an alternate message flow was described for exchange environments (see Volume 7). The replace request that leads to one or more immediate executions would only result in a single ExecutionReport that shows the latest LeavesQty and CumQty values. the component reports the individual executions and the replacement is not mentioned explicitly. However, the user knows that his replacement request was not rejected and can infer that the price must have successfully changed from A to B.

Regards,
Hanno.

Hi,

We have seen an interesting behavior on CME recently: the tag CumQty
decreased between execution reports with REPLACE and PARTIAL_FILL.

CME support clarified that it is an intentional deviation from FIX
spec, which might actually be very helpful for buy sides that would
like to know the latest order state as soon as possible in the chain of
order updates.

Scenario:

  • order 17@A is accepted
  • client issues replace request with the new price B
  • venue replies with ExecType=REPLACE OrdStatus=REPLACED LeavesQty=0
    CumQty=17 price=B
  • venue replies with ExecType=PARTIAL_FILL OrdStatus=PARTIALLY_FILLED
    LeavesQty=15 CumQty=2 LastQty=2 price=B (note, CumQty decreased,
    LeavesQty went from 0 to 15)
  • … another partial fill
  • venue replies with ExecType=FILL OrdStatus=FILLED LeavesQty=0
    CumQty=17 LastQty=10 price=B

I am just curious if this is indeed a FIX deviation or something that
may happen at other venues as well, that is, quite common practice?

What is your experience?

Thanks in advance, Igor

4

Thanks for prompt reply!

There was another partial fill with LastQty=5 which values I didn’t mention, sorry.

Otherwise it should sum up?

Yes, I am aware of at least some FIX optimizations where only one execution report is sent back instead of two-three-etc messages with REPLACE & FILLS.

But this seems different to me. Here you receive same number of execution reports but just the very first message specifies the latest order state first, then PARTIALFILLs and FILL re-iterate volumes one more time. Sort of flash back, to ensure you populate trades.

The volumes that are changing back – this is what confuses me most of all.

Igor, are you sure that LastQty is 10 and not 15 in your final bullet
(ExecType=FILL)? The numbers do not seem to add up.

The requirement to send current order status information as early as
possible is certainly common. The problem is to align transaction models
of a core exchange matching system and FIX. Sending out multiple
ExecutionReport with intermediate states that never really existed for
the matcher might lead to order modification or deletion requests that
are useless.

With FIX 5.0 SP1, an alternate message flow was described for exchange
environments (see Volume 7). The replace request that leads to one or
more immediate executions would only result in a single ExecutionReport
that shows the latest LeavesQty and CumQty values. the component
reports the individual executions and the replacement is not
mentioned explicitly. However, the user knows that his replacement
request was not rejected and can infer that the price must have
successfully changed from A to B.

Regards, Hanno.

5

I hope that the CME RoE explain the message flow and qty field contents. If LeavesQty on the REPLACE is >0 then it becomes really tricky to know which of the ExecutionReports thereafter you can ignore or not in terms of CumQty/LeavesQty information. Maybe it is only done for LeavesQty=0, i.e. when the order reaches end of life. That seems to be fairly straightforward and tells you right away that no more changes are applicable to the order.

Or is there maybe some kind of match ID that tells you which messages belong the same matching engine transaction, the first of which already carries the final order qty information? It seems complicated but would assume that it is deterministic in one way or another.

Thanks for prompt reply!

There was another partial fill with LastQty=5 which values I didn’t
mention, sorry.

Otherwise it should sum up?

Yes, I am aware of at least some FIX optimizations where only one
execution report is sent back instead of two-three-etc messages with
REPLACE & FILLS.

But this seems different to me. Here you receive same number of
execution reports but just the very first message specifies the latest
order state first, then PARTIALFILLs and FILL re-iterate volumes one
more time. Sort of flash back, to ensure you populate trades.

The volumes that are changing back – this is what confuses me
most of all.

6

I believe it’s only done for LeavesQty=0, that is, when replace request races with complete fill of an order.

Otherwise it would be too much complex, I agree.

Anyhow I have still now idea how common this behavior is, of if there is indeed a tendency to report the latest order status first asap, and send involved trades after.

Many thanks for your opinion!

I hope that the CME RoE explain the message flow and qty field contents.
If LeavesQty on the REPLACE is >0 then it becomes really tricky to know
which of the ExecutionReports thereafter you can ignore or not in terms
of CumQty/LeavesQty information. Maybe it is only done for LeavesQty=0,
i.e. when the order reaches end of life. That seems to be fairly
straightforward and tells you right away that no more changes are
applicable to the order.

Or is there maybe some kind of match ID that tells you which messages
belong the same matching engine transaction, the first of which already
carries the final order qty information? It seems complicated but would
assume that it is deterministic in one way or another.