Cancel/replace request sent whilst execution is being reported – the requested order qty is below cum qty

, ,
1

Imported from previous forum

2

[ original email was from Nam Palicha - npalicha@yahoo.com ]
Hi,

I would like to know what would be the appropriate flow for the given scenario if we are implementing Fix 4.0

ClOrdID = 101
Qty = 1000

  1. Order accepted (Execution sent accepting the order)
    OrderID = 1
    ClOrdID = 101

  2. Partial fill sent for 800
    OrderID = 1
    ClOrdID = 101
    CumQty = 800

The partial execution crosses with the cancel replace request to decrease the Order Qty below the cum qty.

  1. Cancel Replace Request
    ClOrdID = 102
    OrigClOrdID = 101
    Order Qty = 700

What can be the acceptable reponses to this.
We current reject the cancel replace request since the order has already been filled more than the qty request and then do an unsolicited cancel ( Order Qty = cum Qty0

Looking at the Fix 4.2 errata appendix D, case D12
an execution report is sent filling the order with the Cum Qty

So in this case it would be

ClOrdID = 102
OrigClOrdID = 101
CumQty = 800
OrdStatus = Filled

Is this a valid response even in Fix 4.0, although tag 41 is not sent on 4.0 execution reports.

I will also appreaciate if someone can direct me to the link where i can download 4.0 specifications and have similar Order flow matrices as that on 4.2

3

IMHO:
Normally, I would reject the CancelReplace and leave the order open and partially filled. The order sender is expected to take further action (like cancel the order) when (s)he gets my CancelReplaceReject.
I think you are protecting order-sender by cancelling the order unsolicitedly because that’s what order-sender intended by reducing Qty, reduce exposure/risk. I don’t think this is standard FIX behaviour but should be implemented if aggreed upon by both parties.

other ideas?

Hi,

I would like to know what would be the appropriate flow for the given
scenario if we are implementing Fix 4.0

ClOrdID = 101 Qty = 1000

  1. Order accepted (Execution sent accepting the order) OrderID = 1
    ClOrdID = 101

  2. Partial fill sent for 800 OrderID = 1 ClOrdID = 101 CumQty = 800

The partial execution crosses with the cancel replace request to
decrease the Order Qty below the cum qty.

  1. Cancel Replace Request ClOrdID = 102 OrigClOrdID = 101 Order Qty =
    700

What can be the acceptable reponses to this. We current reject the
cancel replace request since the order has already been filled more than
the qty request and then do an unsolicited cancel ( Order Qty = cum Qty0

Looking at the Fix 4.2 errata appendix D, case D12 an execution report
is sent filling the order with the Cum Qty

So in this case it would be

ClOrdID = 102 OrigClOrdID = 101 CumQty = 800 OrdStatus = Filled

Is this a valid response even in Fix 4.0, although tag 41 is not sent on
4.0 execution reports.

I will also appreaciate if someone can direct me to the link where i
can download 4.0 specifications and have similar Order flow matrices as
that on 4.2

4

[ original email was from Nam Palicha - npalicha@yahoo.com ]
I agree that the cancel replace request should be rejected. That is what we are implementing currently. My suggestion to do an unsolicited cancel was just a better way of implementing case D12 described in the Fix 4.2 documentation

However my question was more like is the 2nd case that i explained as in D12 described in the Fix 4.2 document acceptable to most buy sides implementing 4.0? I think that this may be the case in 4.2, but cannot be implemented in 4.0

IMHO: Normally, I would reject the CancelReplace and leave the order
open and partially filled. The order sender is expected to take further
action (like cancel the order) when (s)he gets my CancelReplaceReject. I
think you are protecting order-sender by cancelling the order
unsolicitedly because that’s what order-sender intended by reducing Qty,
reduce exposure/risk. I don’t think this is standard FIX behaviour but
should be implemented if aggreed upon by both parties.

other ideas?

Hi,

I would like to know what would be the appropriate flow for the given
scenario if we are implementing Fix 4.0

ClOrdID = 101 Qty = 1000

  1. Order accepted (Execution sent accepting the order) OrderID = 1
    ClOrdID = 101

  2. Partial fill sent for 800 OrderID = 1 ClOrdID = 101 CumQty = 800

The partial execution crosses with the cancel replace request to
decrease the Order Qty below the cum qty.

  1. Cancel Replace Request ClOrdID = 102 OrigClOrdID = 101 Order Qty
    = 700

What can be the acceptable reponses to this. We current reject the
cancel replace request since the order has already been filled more
than the qty request and then do an unsolicited cancel ( Order Qty =
cum Qty0

Looking at the Fix 4.2 errata appendix D, case D12 an execution report
is sent filling the order with the Cum Qty

So in this case it would be

ClOrdID = 102 OrigClOrdID = 101 CumQty = 800 OrdStatus = Filled

Is this a valid response even in Fix 4.0, although tag 41 is
not sent on
4. execution reports.

I will also appreaciate if someone can direct me to the link where i
can download 4.0 specifications and have similar Order flow matrices
as that on 4.2

5

I think it is a good idea to implement D12 of FIX4.2 into FIX4.0. In general newer versions of FIX were intended to remove ambiguities and make protocol straightforward.
Again, systems not FIX4.2-literate might object to this but I think business would like to assimilate this feature.

I agree that the cancel replace request should be rejected. That is what
we are implementing currently. My suggestion to do an unsolicited cancel
was just a better way of implementing case D12 described in the Fix 4.2
documentation

However my question was more like is the 2nd case that i explained as in
D12 described in the Fix 4.2 document acceptable to most buy sides
implementing 4.0? I think that this may be the case in 4.2, but cannot
be implemented in 4.0

IMHO: Normally, I would reject the CancelReplace and leave the order
open and partially filled. The order sender is expected to take
further action (like cancel the order) when (s)he gets my
CancelReplaceReject. I think you are protecting order-sender by
cancelling the order unsolicitedly because that’s what order-sender
intended by reducing Qty, reduce exposure/risk. I don’t think this is
standard FIX behaviour but should be implemented if aggreed upon by
both parties.

other ideas?

Hi,

I would like to know what would be the appropriate flow for the
given scenario if we are implementing Fix 4.0

ClOrdID = 101 Qty = 1000

  1. Order accepted (Execution sent accepting the order) OrderID = 1
    ClOrdID = 101

  2. Partial fill sent for 800 OrderID = 1 ClOrdID = 101 CumQty = 800

The partial execution crosses with the cancel replace request to
decrease the Order Qty below the cum qty.

  1. Cancel Replace Request ClOrdID = 102 OrigClOrdID = 101 Order Qty
    = 700

What can be the acceptable reponses to this. We current reject the
cancel replace request since the order has already been filled more
than the qty request and then do an unsolicited cancel ( Order Qty =
cum Qty0

Looking at the Fix 4.2 errata appendix D, case D12 an execution
report is sent filling the order with the Cum Qty

So in this case it would be

ClOrdID = 102 OrigClOrdID = 101 CumQty = 800 OrdStatus = Filled

Is this a valid response even in Fix 4.0, although tag 41 is not
sent on
4. execution reports.

I will also appreaciate if someone can direct me to the link where i
can download 4.0 specifications and have similar Order flow matrices
as that on 4.2

6

[ original email was from Ryan Pierce - rpierce@taltrade.com ]

Looking at the Fix 4.2 errata appendix D, case D12 an execution report
is sent filling the order with the Cum Qty

So in this case it would be

ClOrdID = 102 OrigClOrdID = 101 CumQty = 800 OrdStatus = Filled

Is this a valid response even in Fix 4.0, although tag 41 is not sent on
4.0 execution reports.

As has been said, rejecting the cancel and leaving the order open until further action by the client is always an option.

My understanding of D12 is that following the partial fill, the change itself is accepted, which effectively fills the order. (The user either gets the entire order volume filled in the D11 case where CumQty == Requested Quantity, or appears to get over-filled where CumQty > Requested Quantity.)

This translates fairly well into FIX 4.1. However, FIX 4.0 doesn’t have the ability to chain together two ClOrdIDs on Exec Reports, nor does it differentiate between the action being taken (ExecType) and the state of the order (OrdStatus). There’s no clean way to say that an order has been changed and is filled.

I believe in my own implementation, depending on circumstances I might send the following in 4.0 mode:

ClOrdID=102
OrdStatus=Replaced
CumQty=800
OrderQty=800

I don’t send OrigClOrdID in this case since it doesn’t appear in the ExecReports, so I have no expectation of firms being able to base business decisions on its presence.

And it’s up to the counterparty to figure out that this means the order is now filled or over-filled and nothing more is going to trade on it. The user asked to change the order to 700 shares, I’ve now accepted the change and 800 were filled, so it would seem that this means nothing more is coming.

I don’t claim this is necessarily FIX compliant, nor is it the only way; it’s just what I believe I chose to implement in light of ambiguity with the 4.0 spec. With 4.1 and higher I can send:

ClOrdID=102
OrigClOrdID=101
CumQty=800
OrderQty=800
LeavesQty=0
ExecType=Replaced
OrdStatus=Filled

which is compliant with FIX 4.2 Appendix D-14.

I will also appreaciate if someone can direct me to the link where i
can download 4.0 specifications and have similar Order flow matrices as
that on 4.2

This doesn’t exist, nor do I think it could exist, at least in any widely accepted standardized form. The 4.0 spec itself has only four state change matrices, and a lot of firms don’t even follow them. (According to the location of the asterisk in the cancel case, one should say that the cancel’s ClOrdID is New; I’ve found many firms prefer to say the original order’s ClOrdID is Pending Cancel.)

FIX 4.0 has its strengths and limitations. It was the first version to have what I consider the modern FIX session layer. It was the first version to be Y2K compliant. And it was available when FIX adoption in the US equities markets really took off. But it was quite ambiguous in its handling of cancels and changes. FIX 4.1 is the first version that I consider has modern order state semantics.