Imported from previous forum
[ original email was from John Armstrong - johna@ms.com ]
The following issue related to Pending Cancel/Repl
reports has been raised which I think needs
clarification. If a Cancel/Replace request to
reduce/increase OrderQty, any messages sent
to the customer while this request is in a
Pending Cancel state should have the order details
(quantity, price, instructions, etc) reflect
optimistically that the pending request will be
accepted.
The current examples in App D of the FIX4.1 spec
reflect a the actual current attributes of the
order being Replaced.
This was an oversight on my part when writing
these examples and I propose the next version
should reflect optimistically, until and if
the request is rejected.
For example, in "Partially Filled Order followed
by Replace Request to Decrease Order Quantity" in
App. D of the Fix4.1 spec, the Pending Cancel
message sent at time 5 should have OrderQty=8000
(not 10K) and Leaves continue to be <OrderQty - CumQty>.
John Armstrong
[ original email was from Yevgeniy Tovshteyn - yevgeniy@javtech.com ]
My personal oppinion - it will cause a lot of confusions.
-
Execution Reports must reflect the CURRENT state of the order.
-
Cancel/Replaces DO often get rejected.
The actual line from buy side to the exchange might be long and consist of many brokers. None of them can guarantee the executon. If it fails, all of them will have to adjust back their order status
These are just some of the reasons
> The following issue related to Pending Cancel/Repl
> reports has been raised which I think needs
> clarification. If a Cancel/Replace request to
> reduce/increase OrderQty, any messages sent
> to the customer while this request is in a
> Pending Cancel state should have the order details
> (quantity, price, instructions, etc) reflect
> optimistically that the pending request will be
> accepted.
>
> The current examples in App D of the FIX4.1 spec
> reflect a the actual current attributes of the
> order being Replaced.
>
> This was an oversight on my part when writing
> these examples and I propose the next version
> should reflect optimistically, until and if
> the request is rejected.
>
> For example, in "Partially Filled Order followed
> by Replace Request to Decrease Order Quantity" in
> App. D of the Fix4.1 spec, the Pending Cancel
> message sent at time 5 should have OrderQty=8000
> (not 10K) and Leaves continue to be <OrderQty - CumQty>.
>
>
> John Armstrong
>
Since the ExecutionReports must specify the ClOrdID and then my opinion is that the order parameter information (i.e. OrderQty) should match that belonging to the ClOrdID in that message. If the customer increases qty on the order via a Cancel/Replace Request (and specifying a new ClOrdID) then ExecutionReports which come back referring to the new ClOrdID should reflect the new order parameters vs. the old. The buyside is going to have to account for the prior and future state of the order as it transitions anyway. This is just my opinion.
> My personal oppinion - it will cause a lot of confusions.
>
> 1. Execution Reports must reflect the CURRENT state of the order.
>
> 2. Cancel/Replaces DO often get rejected.
>
> The actual line from buy side to the exchange might be long and consist of many brokers. None of them can guarantee the executon. If it fails, all of them will have to adjust back their order status
>
> These are just some of the reasons
>
>
> > The following issue related to Pending Cancel/Repl
> > reports has been raised which I think needs
> > clarification. If a Cancel/Replace request to
> > reduce/increase OrderQty, any messages sent
> > to the customer while this request is in a
> > Pending Cancel state should have the order details
> > (quantity, price, instructions, etc) reflect
> > optimistically that the pending request will be
> > accepted.
> >
> > The current examples in App D of the FIX4.1 spec
> > reflect a the actual current attributes of the
> > order being Replaced.
> >
> > This was an oversight on my part when writing
> > these examples and I propose the next version
> > should reflect optimistically, until and if
> > the request is rejected.
> >
> > For example, in "Partially Filled Order followed
> > by Replace Request to Decrease Order Quantity" in
> > App. D of the Fix4.1 spec, the Pending Cancel
> > message sent at time 5 should have OrderQty=8000
> > (not 10K) and Leaves continue to be <OrderQty - CumQty>.
> >
> >
> > John Armstrong
> >
>
I agree with this last comment.
Reports sent to the buyside while the order is in a cancel pending or cancel/replace pending condition are "usually" on the ORIGINAL ORDER (late reports, etc.). If the sellside can send reports on the NEW ORDER, then they must have accepted the change and probably should send that acceptance before sending the report on that new order.
Another issue exists here: if the sellside has "a few more shares" on a cancel/replace pending order and sends the report on that cancel/replace pending order, then sends a "change successful", the order quantity, leaves quantity and other fields MAY NOT match what the buyside is expecting. This is because there were (or worse, will be) reports that the buyside was not aware of when they sent the order. Interrogating the WHOLE inbound message solves this "problem" for the buyside.
Cancels and cancel/replace requests MAY BE REJECTED or may be only PARTIALLY satisfied! I see no reason to be "optimistic" or "irrationally exuberant".
> My personal oppinion - it will cause a lot of confusions.
>
> 1. Execution Reports must reflect the CURRENT state of the order.
>
> 2. Cancel/Replaces DO often get rejected.
>
> The actual line from buy side to the exchange might be long and consist of many brokers. None of them can guarantee the executon. If it fails, all of them will have to adjust back their order status
>
> These are just some of the reasons
>
>
> > The following issue related to Pending Cancel/Repl
> > reports has been raised which I think needs
> > clarification. If a Cancel/Replace request to
> > reduce/increase OrderQty, any messages sent
> > to the customer while this request is in a
> > Pending Cancel state should have the order details
> > (quantity, price, instructions, etc) reflect
> > optimistically that the pending request will be
> > accepted.
> >
> > The current examples in App D of the FIX4.1 spec
> > reflect a the actual current attributes of the
> > order being Replaced.
> >
> > This was an oversight on my part when writing
> > these examples and I propose the next version
> > should reflect optimistically, until and if
> > the request is rejected.
> >
> > For example, in "Partially Filled Order followed
> > by Replace Request to Decrease Order Quantity" in
> > App. D of the Fix4.1 spec, the Pending Cancel
> > message sent at time 5 should have OrderQty=8000
> > (not 10K) and Leaves continue to be <OrderQty - CumQty>.
> >
> >
> > John Armstrong
> >
>
it is my opinion that any executions sent back while an order is in ‘pending’ state should be reported against the original order - until the replacement is accepted it should not be considered active…
the replacement order is pending until explicitly accepted at which time the original order should be updated to replaced - what happens if the c/r is ultimately rejected - we now have fills against a rejected order!
(however, care should be taken as the replaced
order could still have reports coming - which will update the cumQty and AvgPx of both the orig and replacement - but the effect on the replacement will not be seen until a report on the replacement is generated!)
> I agree with this last comment.