ClOrdID and Cancel Reject problem

, ,
1

Imported from previous forum

2

[ original email was from Andrew Lister - andrew.lister@sig.com ]
Hello

I have a situation where a message sequence is losing the original order and believe the problem lies in the ClOrdID and OrigClOrdId tags after an Order Cancel Reject is received. I am initiating the order sequence and what I am seeing is the following (please view with fixed width font!)

    MsgType    Status    ClOrdId OrigClOrdID

1 SEND: New Order 422.0
2 RECV: Exec Rpt New 422.0
3 SEND: Can Rpl 422.1 422.0
4 RECV: Exec Rpt Pending 422.1 422.0
5 RECV: Exec Rpt Replaced 422.1 422.0
6 SEND: Can Rpl 422.2 422.1
7 RECV: Can Rej Rejected 422.1 422.2 (rejected by broker)
8 SEND: Can Rep 422.3 422.2
9 RECV: Can Rej Rejected 422.2 423.3 (due to order unacked)

… from here the original order is lost and cannot be cancelled, replaced, etc.

In my view, the problem starts at 7 because the ClOrdID returned is incorrect (reversed with tag 41?) but the counterparty is telling me that the error occurs at 8 because tag 41 references a rejected correction.

Without knowing exactly what happens behind the scenes, I’d say that tag 41 of message 8 uses the value returned in message 7.

Can anyone provide some insight as to where they think things start to fall apart?

Thanks

Andrew

3

[ original email was from Niall McCallion - nmccallion@espeed.co.uk ]
Andrew,

I suggest the reply is wrong at 7. It should reject ClOrdId 422.2 and have origClOrdId of 422.1. Like so:

7 RECV: Can Rej Rejected 422.2 422.1 (rejected by broker)

Message 8 then becomes:

8 SEND: Can Rep 422.3 422.1
9 RECV: Can Rej Rejected 422.3 422.1 (due to order unacked)

This follows the same paradigm exhibited in the preceding replace acceptance and results in 422.1, the accepted replace being the active ClOrdId. A further ExecutionReport would be:

10 RECV:Exec Rpt DFD 422.1 empty

Niall McCallion
Senior Analyst Programmer
Cantor Fitzgerald
Equities Technology
nmccallion@cantor.com

Hello

I have a situation where a message sequence is losing the original
order and believe the problem lies in the ClOrdID and OrigClOrdId tags
after an Order Cancel Reject is received. I am initiating the order
sequence and what I am seeing is the following (please view with fixed
width font!)

    MsgType Status ClOrdId OrigClOrdID 1 SEND: New Order 422.0 2
    RECV: Exec Rpt New 422.0 3 SEND: Can Rpl 422.1 422.0 4 RECV:
    Exec Rpt Pending 422.1 422.0 5 RECV: Exec Rpt Replaced 422.1
    422.0 6 SEND: Can Rpl 422.2 422.1 7 RECV: Can Rej Rejected 422.1
    422.2 (rejected by broker) 8 SEND: Can Rep 422.3 422.2 9 RECV:
    Can Rej Rejected 422.2 423.3 (due to order unacked)

… from here the original order is lost and cannot be cancelled,
replaced, etc.

In my view, the problem starts at 7 because the ClOrdID returned is
incorrect (reversed with tag 41?) but the counterparty is telling me
that the error occurs at 8 because tag 41 references a rejected
correction.

Without knowing exactly what happens behind the scenes, I’d say that tag
41 of message 8 uses the value returned in message 7.

Can anyone provide some insight as to where they think things start to
fall apart?

Thanks

Andrew

4

I concur with Niall that step 7 is wrong and that you should have sent 422.3 422.1 in step 8.

Take a look at Volume 4 of the FIX 4.4 specification, scenario D.1.c on page 60. It shows in step 7 that (Y,X) is to be returned to reject the replace request (Y,X) in step 4. The new replace request in step 9 then uses (Z,X), i.e. Y must not be used anymore. The comment in step 9 explains that OrigClOrdID needs to be X, i.e. the last, non-rejected ClOrdID.

Regards,
Hanno.

Andrew,

I suggest the reply is wrong at 7. It should reject ClOrdId 422.2 and
have origClOrdId of 422.1. Like so:

7 RECV: Can Rej Rejected 422.2 422.1 (rejected by broker)

Message 8 then becomes:

8 SEND: Can Rep 422.3 422.1 9 RECV: Can Rej Rejected 422.3 422.1 (due to
order unacked)

This follows the same paradigm exhibited in the preceding replace
acceptance and results in 422.1, the accepted replace being the active
ClOrdId. A further ExecutionReport would be:

10 RECV:Exec Rpt DFD 422.1 empty

Niall McCallion Senior Analyst Programmer Cantor Fitzgerald Equities
Technology nmccallion@cantor.com

Hello

I have a situation where a message sequence is losing the original
order and believe the problem lies in the ClOrdID and OrigClOrdId tags
after an Order Cancel Reject is received. I am initiating the order
sequence and what I am seeing is the following (please view with fixed
width font!)

    MsgType Status ClOrdId OrigClOrdID 1 SEND: New Order 422.0 2
    RECV: Exec Rpt New 422.0 3 SEND: Can Rpl 422.1 422.0 4 RECV:
    Exec Rpt Pending 422.1 422.0 5 RECV: Exec Rpt Replaced 422.1
    422. 6 SEND: Can Rpl 422.2 422.1 7 RECV: Can Rej Rejected
         422.1
    422.2 (rejected by broker) 8 SEND: Can Rep 422.3 422.2 9 RECV:
        Can Rej Rejected 422.2 423.3 (due to order unacked)

… from here the original order is lost and cannot be cancelled,
replaced, etc.

In my view, the problem starts at 7 because the ClOrdID returned is
incorrect (reversed with tag 41?) but the counterparty is telling me
that the error occurs at 8 because tag 41 references a rejected
correction.

Without knowing exactly what happens behind the scenes, I’d say that
tag 41 of message 8 uses the value returned in message 7.

Can anyone provide some insight as to where they think things start to
fall apart?

Thanks

Andrew