Imported from previous forum
[ original email was from Michael Tsafas - Michael_Tsafas@prusec.com ]
When accepting a Cancel, should I use the ClOrdID field (11=) from the original ID of the Order, or from the Cancel or Cancel/Replace request?
EX: Original order 11=12345
Cancel order 11=12346
Acceptance of cancel by Broker: (UROUT)
Should 11=12345 OR 11=12346 ???
The documentation hints that it should be 12346, at least in the TLTC message.
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> When accepting a Cancel, should I use the ClOrdID field (11=) from the original ID of the Order, or from the Cancel or Cancel/Replace request?
>
> EX: Original order 11=12345
> Cancel order 11=12346
> Acceptance of cancel by Broker: (UROUT)
> Should 11=12345 OR 11=12346 ???
>
> The documentation hints that it should be 12346, at least in the TLTC message.
>
Since this was posted to the 4.0 Session group, I assume you are talking about FIX 4.0.
The state diagram at the end of the FIX 4.0 spec is very useful in figuring out what should happen.
You are correct that the Cancel has a new ClOrdID. But I think you are confusing a cancel acknowledgement with a UR OUT.
Assuming that the order still has open shares, and no other circumstances prevent the cancel request, the other side will respond with an Execution messafe with ClOrdID=12346 and OrdStatus=New. This is a cancel acknowledgement that means the other side has properly received the cancel and is working on it. This does NOT mean the order is out.
The FIX equivalent of a UR OUT is an Execution with ClOrdID=12345 with OrdStatus=Cancelled.
In the case of a Too Late To Cancel, a Cancel Reject is sent with ClOrdID=12346.
[ original email was from Vitaliy Kantor - kantorv@ms.com ]
> When accepting a Cancel, should I use the ClOrdID field (11=) from the original ID of the Order, or from the Cancel or Cancel/Replace request?
>
> EX: Original order 11=12345
> Cancel order 11=12346
> Acceptance of cancel by Broker: (UROUT)
> Should 11=12345 OR 11=12346 ???
The answer is 11=12346;41=12345
ClOrdID holds Cancel ID;
OrigClOrdID holds ID of Cancelled Order
>
> The documentation hints that it should be 12346, at least in the TLTC message.
You’re absolutely right for TLTC and other cancel rejects that are handled same way as UROUTs.
11=12346;41=12345
Vitaliy
>
[ original email was from Raman Kannan - asset@acm.org ]
I read with interest three messages available
in this archive ending with a final comment
by
> Vitaliy
>
regarding ClOrdID for CANCEL REJECT.
I have the following questions regarding
CANCEL and follow on responses
FIRM A AND FIRM B are involved
A 2 B – BUY ORIG_CL_ORD_ID 1000 IBM MKT
B 2 A – ACK NEW_ORDER_ID NEW_EXEC_ID BUY 1000 IBM MKT
B BUYS 500
B PLACES ANOTHER 200 on ORDER
DOES NOT SEND ANY MESSAGE 2 A (ASSUME A is OK with this business model)
A 2 B – CANCEL NEW_CANCEL_ID, ORIG_CL_ORD_ID BUY 1000 IBM MKT
B 2 A – ACK_CANCEL NEW_CANCEL_ID ORIG_CL_ORD_ID
B FINDS THAT 200 HAS BEEN EXECUTED
What messages should B send A at this point?
CANCEL ACCEPTED
(what details are to be provided?)
PARTIAL FILL (for the 700)
In these Execution Reports which OrderID is to be
used. Is it the same OrderID assigned for the
Order when the ACK was sent?
Also, should the ExecRefId be unique across
Orders in Execution Reports?
Because the OrderId would be unique for
different orders and it does not matter if
the ExecRefId are same across ExecutionReports
pertaining to different Orders.
This leads to a business question,
What is the intended purpose of the ExecRefId
and OrderId?
Any clarification is much appreciated
(FIX 4.0 semantics, please)
–
RK