Cancel/Replace and in-flight modifications

, ,
1

Imported from previous forum

2

[ original email was from Bernt Sandén - bernt.sanden@om.com ]
Hi,

In an exchange environment order modifications can be done from FIX or via a proprietary protocol. The same member can have one session for FIX and another session for the proprietary protocol.

The following problem can arise (We use FIX 4.2):

  1. An order is entered via FIX, Price=55 and OrdQty=100
  2. The order is changed via the proprietary protocol to 56.
  3. An Execution Report drop copy is sent to the FIX client to notify the price change from the proprietary protocol.
  4. While the Execution Report is in-flight an order cancel/replace request is sent from the FIX session to modify the volume to 110. The FIX client use the same value for all fields as in the original order except for the volume, that is Price=55 and OrdQty=110.

The intention here was to only change the volume, but as the state of the order changed prior to the order cancel/replace and these changes passed each other on the line the price will be changed from 56 to 55 and the OrdQty will be changed to 110. This was definitely not what the FIX client expected to happen.

We use FIX 4.2 so we cannot use tag 586 OrigOrdModTime to protect us from in flight modifications.

I would prefer if the FIX client explictly can specify which fields to modify. This could be achieved by only sending those fields that are to be changed and not send every field as in the original order. In this case only send OrdQty=110 and skip the price tag.

The scenario above is likely to happen in the exchange world so I would like to hear of any possible solution for this problem.

In our propriatery protocol the API-client can specify exactly which fields to modify.

3

Hi Bernt,

In an exchange environment order modifications can be done from FIX or
via a proprietary protocol. The same member can have one session for
FIX and another session for the proprietary protocol.

The following problem can arise (We use FIX 4.2):

  1. An order is entered via FIX, Price=55 and OrdQty=100
  2. The order is changed via the proprietary protocol to 56.
  3. An Execution Report drop copy is sent to the FIX client to notify
    the price change from the proprietary protocol.

Which OrdStatus/ExecType do you use in the drop-copy?

  1. While the Execution Report is in-flight an order cancel/replace
    request is sent from the FIX session to modify the volume to 110.
    The FIX client use the same value for all fields as in the original
    order except for the volume, that is Price=55 and OrdQty=110.

The intention here was to only change the volume, but as the state of
the order changed prior to the order cancel/replace and these changes
passed each other on the line the price will be changed from 56 to 55
and the OrdQty will be changed to 110. This was definitely not what
the FIX client expected to happen.

Indeed. But the chaining of ClOrdID should prevent this error:

NewOrderSingle(ClOrdID_A)
OrderCancelReplaceRequest(ClOrdID_B,ClOrdID_A)
OrderCancelReplaceRequest(ClOrdID_C,ClOrdID_B)
…

E.g., in your scenario, over the proprietary protocol to equivalent of

OrderCancelReplaceRequest(ClOrdID_C1,ClOrdID_B)

has been sent. The FIX side does not get the ExecReport with the new ClOrdID, so it also sents something like

OrderCancelReplaceRequest(ClOrdID_C2,ClOrdID_B)

This should be rejected since the ClOrdID_B has already replaced by ClOrdID_C1. The FIX message to be sent is OrderCancelReject, I am not sure about CxlRejReason:

0 = Too late to cancel
3 = Order already in Pending Cancel or Pending Replace status

In this way, the FIX client can be sure to use the newest order state and there is no need to specify the fields to change.

IMHO, the keypoint is that the proprietary protocol takes part in the chaining somehow.

Cheers, Jörg

We use FIX 4.2 so we cannot use tag 586 OrigOrdModTime to protect us
from in flight modifications.

I would prefer if the FIX client explictly can specify which fields to
modify. This could be achieved by only sending those fields that are to
be changed and not send every field as in the original order. In this
case only send OrdQty=110 and skip the price tag.

The scenario above is likely to happen in the exchange world so I would
like to hear of any possible solution for this problem.

In our propriatery protocol the API-client can specify exactly which
fields to modify.

4

[ original email was from Bernt Sandén - bernt.sanden@om.com ]
> Hi Bernt,

In an exchange environment order modifications can be done from FIX or
via a proprietary protocol. The same member can have one session for
FIX and another session for the proprietary protocol.

The following problem can arise (We use FIX 4.2):

  1. An order is entered via FIX, Price=55 and OrdQty=100
  2. The order is changed via the proprietary protocol to 56.
  3. An Execution Report drop copy is sent to the FIX client to notify
    the price change from the proprietary protocol.

Which OrdStatus/ExecType do you use in the drop-copy?
We use OrdStatus=New ExecType=Replaced

  1. While the Execution Report is in-flight an order cancel/replace
    request is sent from the FIX session to modify the volume to 110.
    The FIX client use the same value for all fields as in the original
    order except for the volume, that is Price=55 and OrdQty=110.

The intention here was to only change the volume, but as the state of
the order changed prior to the order cancel/replace and these changes
passed each other on the line the price will be changed from 56 to 55
and the OrdQty will be changed to 110. This was definitely not what
the FIX client expected to happen.

Indeed. But the chaining of ClOrdID should prevent this error:

NewOrderSingle(ClOrdID_A) OrderCancelReplaceRequest(ClOrdID_B,ClOrdID_A)
OrderCancelReplaceRequest(ClOrdID_C,ClOrdID_B) …

E.g., in your scenario, over the proprietary protocol to equivalent of

OrderCancelReplaceRequest(ClOrdID_C1,ClOrdID_B)

has been sent. The FIX side does not get the ExecReport with the new
ClOrdID, so it also sents something like

OrderCancelReplaceRequest(ClOrdID_C2,ClOrdID_B)

This should be rejected since the ClOrdID_B has already replaced by
ClOrdID_C1. The FIX message to be sent is OrderCancelReject, I am not
sure about CxlRejReason:

= Too late to cancel 3 = Order already in Pending Cancel or Pending
Replace status

In this way, the FIX client can be sure to use the newest order state
and there is no need to specify the fields to change.

IMHO, the keypoint is that the proprietary protocol takes part in the
chaining somehow.

Cheers, Jörg

We use FIX 4.2 so we cannot use tag 586 OrigOrdModTime to protect us
from in flight modifications.

I would prefer if the FIX client explictly can specify which fields to
modify. This could be achieved by only sending those fields that are
to be changed and not send every field as in the original order. In
this case only send OrdQty=110 and skip the price tag.

The scenario above is likely to happen in the exchange world so I
would like to hear of any possible solution for this problem.

In our propriatery protocol the API-client can specify exactly which
fields to modify.

Well the proprietary protocol does not take part in the chaining so the update from the propriatery protocol will look like an unsolicited cancel/replace from market operations (Scenario D20 in the FIX 4,2 spec).

So it would look like:

  1. New Order Single (ClientOrdid_A) “Initial order from FIX client”
  2. Execution Report (ClientOrdid_A, ExecType=New, OrdStatus=New) “ER of initial order”
  3. Execution Report (ClientOrdId_A, ExecType=Replaced, OrdStatus=New) “ER of replace from propriatery protocol”
  4. Cancel/Replace (OrigClOrdid_A, ClientOrdid_B) Update from FIX client
5

[…]

  1. An Execution Report drop copy is sent to the FIX client to
    notify the price change from the proprietary protocol.

Which OrdStatus/ExecType do you use in the drop-copy?
We use OrdStatus=New ExecType=Replaced

According to scenario D20, FIX 4.2, you are referring to below this should be ExecType=Restated since this is unsolicited.

We are using Restated in our system, but I was not completely sure whether this correct. Thanks for the pointer :slight_smile:

  1. While the Execution Report is in-flight an order cancel/replace
    request is sent from the FIX session to modify the volume to 110.
    The FIX client use the same value for all fields as in the
    original order except for the volume, that is Price=55 and
    OrdQty=110.

The intention here was to only change the volume, but as the state
of the order changed prior to the order cancel/replace and these
changes passed each other on the line the price will be changed from
56 to 55 and the OrdQty will be changed to 110. This was definitely
not what the FIX client expected to happen.

Indeed. But the chaining of ClOrdID should prevent this error:

NewOrderSingle(ClOrdID_A)
OrderCancelReplaceRequest(ClOrdID_B,ClOrdID_A)
OrderCancelReplaceRequest(ClOrdID_C,ClOrdID_B) …

E.g., in your scenario, over the proprietary protocol to equivalent of

OrderCancelReplaceRequest(ClOrdID_C1,ClOrdID_B)

has been sent. The FIX side does not get the ExecReport with the new
ClOrdID, so it also sents something like

OrderCancelReplaceRequest(ClOrdID_C2,ClOrdID_B)

This should be rejected since the ClOrdID_B has already replaced by
ClOrdID_C1. The FIX message to be sent is OrderCancelReject, I am not
sure about CxlRejReason:

= Too late to cancel 3 = Order already in Pending Cancel or Pending
Replace status

In this way, the FIX client can be sure to use the newest order state
and there is no need to specify the fields to change.

IMHO, the keypoint is that the proprietary protocol takes part in the
chaining somehow.

Cheers, Jörg

We use FIX 4.2 so we cannot use tag 586 OrigOrdModTime to protect us
from in flight modifications.

I would prefer if the FIX client explictly can specify which fields
to modify. This could be achieved by only sending those fields that
are to be changed and not send every field as in the original order.
In this case only send OrdQty=110 and skip the price tag.

The scenario above is likely to happen in the exchange world so I
would like to hear of any possible solution for this problem.

In our propriatery protocol the API-client can specify exactly which
fields to modify.

Well the proprietary protocol does not take part in the chaining so
the update from the propriatery protocol will look like an
unsolicited cancel/replace from market operations (Scenario D20 in
the FIX 4,2 spec).

So it would look like:

  1. New Order Single (ClientOrdid_A) “Initial order from FIX client”
  2. Execution Report (ClientOrdid_A, ExecType=New, OrdStatus=New) “ER of
    initial order”
  3. Execution Report (ClientOrdId_A, ExecType=Replaced, OrdStatus=New)
    “ER of replace from propriatery protocol”
  4. Cancel/Replace (OrigClOrdid_A, ClientOrdid_B) Update from FIX client

Is it an option for you to change/extend the proprietary protocol on the server side? This may be easier than changing the FIX spec.

Cheers, Jörg

6

[ original email was from Bernt Sandén - bernt.sanden@om.com ]
> […]

  1. An Execution Report drop copy is sent to the FIX client to
    notify the price change from the proprietary protocol.

Which OrdStatus/ExecType do you use in the drop-copy?
We use OrdStatus=New ExecType=Replaced

According to scenario D20, FIX 4.2, you are referring to below this
should be ExecType=Restated since this is unsolicited.

We are using Restated in our system, but I was not completely sure
whether this correct. Thanks for the pointer :slight_smile:
Sorry I was wrong, we use restated here.

  1. While the Execution Report is in-flight an order cancel/replace
    request is sent from the FIX session to modify the volume to
    110. The FIX client use the same value for all fields as in the
    original order except for the volume, that is Price=55 and
    OrdQty=110.

The intention here was to only change the volume, but as the state
of the order changed prior to the order cancel/replace and these
changes passed each other on the line the price will be changed
from 56 to 55 and the OrdQty will be changed to 110. This was
definitely not what the FIX client expected to happen.

Indeed. But the chaining of ClOrdID should prevent this error:

NewOrderSingle(ClOrdID_A)
OrderCancelReplaceRequest(ClOrdID_B,ClOrdID_A)
OrderCancelReplaceRequest(ClOrdID_C,ClOrdID_B) …

E.g., in your scenario, over the proprietary protocol to equivalent
of

OrderCancelReplaceRequest(ClOrdID_C1,ClOrdID_B)

has been sent. The FIX side does not get the ExecReport with the new
ClOrdID, so it also sents something like

OrderCancelReplaceRequest(ClOrdID_C2,ClOrdID_B)

This should be rejected since the ClOrdID_B has already replaced by
ClOrdID_C1. The FIX message to be sent is OrderCancelReject, I am
not sure about CxlRejReason:

= Too late to cancel 3 = Order already in Pending Cancel or Pending
Replace status

In this way, the FIX client can be sure to use the newest order
state and there is no need to specify the fields to change.

IMHO, the keypoint is that the proprietary protocol takes part in
the chaining somehow.

Cheers, Jörg

We use FIX 4.2 so we cannot use tag 586 OrigOrdModTime to protect
us from in flight modifications.

I would prefer if the FIX client explictly can specify which
fields to modify. This could be achieved by only sending those
fields that are to be changed and not send every field as in the
original order. In this case only send OrdQty=110 and skip the
price tag.

The scenario above is likely to happen in the exchange world so I
would like to hear of any possible solution for this problem.

In our propriatery protocol the API-client can specify exactly
which fields to modify.

Well the proprietary protocol does not take part in the chaining so
the update from the propriatery protocol will look like an
unsolicited cancel/replace from market operations (Scenario D20 in
the FIX 4,2 spec).

So it would look like:

  1. New Order Single (ClientOrdid_A) “Initial order from FIX client”
  2. Execution Report (ClientOrdid_A, ExecType=New, OrdStatus=New) “ER
    of initial order”
  3. Execution Report (ClientOrdId_A, ExecType=Replaced, OrdStatus=New)
    “ER of replace from propriatery protocol”
  4. Cancel/Replace (OrigClOrdid_A, ClientOrdid_B) Update from FIX
    client

Is it an option for you to change/extend the proprietary protocol on the
server side? This may be easier than changing the FIX spec.

Cheers, Jörg

Well, the proprietary protocol is used by a number of participants and it might have great impact to change it. Thanks anyway for good comments.

Best Regards, Bernt