Valid ClOrdID after Cancel Reject

, ,
1

Imported from previous forum

2

Hello,
I’m using FIX 4.4 and have a question about the cancel reject message. The specification says:

When rejecting a Cancel/Replace Request (or Cancel Request), the Cancel Reject message should provide the
ClOrdID which was specified on the Cancel/Replace Request (or Cancel Request) message for identification,
and the OrigClOrdId should be that of the last accepted order (except in the case of CxlRejReason = “Unknown
Order”.

But wich one is the actual ClOrdID after the failure of the replace? I would assume the OrigClOrdID, since the order hasn’t been replaced, but on the other hand, the ClOrdID send by the broker should normally be the valid one, right?

Any help is greatly appriciated,
greetings,
Harald

3

Hi,
It should be the ClOrdId supplied on the Cancel Request.
Regards, Bernt

Hello,
I’m using FIX 4.4 and have a question about the cancel reject message. The specification says:
ön the
When rejecting a Cancel/Replace Request (or Cancel Request), the Cancel Reject message should provide the
ClOrdID which was specified on the Cancel/Replace Request (or Cancel Request) message for identification,
and the OrigClOrdId should be that of the last accepted order (except in the case of CxlRejReason = “Unknown
Order”.

But wich one is the actual ClOrdID after the failure of the replace? I would assume the OrigClOrdID, since the order hasn’t been replaced, but on the other hand, the ClOrdID send by the broker should normally be the valid one, right?

Any help is greatly appriciated,
greetings,
Harald

4

But wich one is the actual ClOrdID after the failure of the replace? I would assume the OrigClOrdID, since the order hasn’t been replaced, but on the other hand, the ClOrdID send by the broker should normally be the valid one, right?

If I have understood the question correctly then the “actual ClOrdID” is the OrigClOrdID in the rejected cancel (or cancel-replace) message. This is the ClOrdID of the last accepted order (or cancel replace).
So later execution reports should contain this ClOrdID.

Hi,
It should be the ClOrdId supplied on the Cancel Request.
Regards, Bernt

Hello,
I’m using FIX 4.4 and have a question about the cancel reject message. The specification says:
ön the
When rejecting a Cancel/Replace Request (or Cancel Request), the Cancel Reject message should provide the
ClOrdID which was specified on the Cancel/Replace Request (or Cancel Request) message for identification,
and the OrigClOrdId should be that of the last accepted order (except in the case of CxlRejReason = “Unknown
Order”.

But wich one is the actual ClOrdID after the failure of the replace? I would assume the OrigClOrdID, since the order hasn’t been replaced, but on the other hand, the ClOrdID send by the broker should normally be the valid one, right?

Any help is greatly appriciated,
greetings,
Harald

5

Harald, it’s very easy if you think of ClOrdID and OrigClOrdID as identifying specific requests. If you reject a request, you reject the associated ClOrdID and go back to the ClOrdID of the last accepted request, which is still the ClOrdID of your order.

Hello,
I’m using FIX 4.4 and have a question about the cancel reject message. The specification says:

When rejecting a Cancel/Replace Request (or Cancel Request), the Cancel Reject message should provide the
ClOrdID which was specified on the Cancel/Replace Request (or Cancel Request) message for identification,
and the OrigClOrdId should be that of the last accepted order (except in the case of CxlRejReason = “Unknown
Order”.

But wich one is the actual ClOrdID after the failure of the replace? I would assume the OrigClOrdID, since the order hasn’t been replaced, but on the other hand, the ClOrdID send by the broker should normally be the valid one, right?

Any help is greatly appriciated,
greetings,
Harald

6

Volume 4 of the FIX 4.4 spec gives a clear example of how ClOrdID and OrigClOrdID are to be treated before and after a cancel replace request has been rejected.

See D.1.b of the Order State Change Matrices near page 59.