Imported from previous forum
I hope someone can tell me what the correct response is to a NewOrderSingle message with a duplicate ClOrdID at the application level…
If a NewOrderSingle with ClOrdID is submitted with ClOrdID=A, then while it is active, another NewOrderSingle, also with ClOrdID=A comes in, order state change matrix D22 shows that the response is to be an ExecutionReport with ClOrdID=A, ExecType=Rejected, and OrdRejReason=DuplicateOrder. Note that this rejection shows the fill information for the "original" order.
Does this imply that the "original" order with ClOrdID=A is now "dead" (and should be cancelled behind the scenes)? Can the "original" order carry on executing, with the tacit assumption that ExecutionReport rejections with OrdRejReason=DuplicateOrder do not mean that the actual originally submitted order has been rejected?
Is there a common practice wrt this situation?
Thanks much.
I would expect the "original" order to continue to be live and carry on executing.
> I hope someone can tell me what the correct response is to a NewOrderSingle message with a duplicate ClOrdID at the application level…
>
> If a NewOrderSingle with ClOrdID is submitted with ClOrdID=A, then while it is active, another NewOrderSingle, also with ClOrdID=A comes in, order state change matrix D22 shows that the response is to be an ExecutionReport with ClOrdID=A, ExecType=Rejected, and OrdRejReason=DuplicateOrder. Note that this rejection shows the fill information for the "original" order.
>
> Does this imply that the "original" order with ClOrdID=A is now "dead" (and should be cancelled behind the scenes)? Can the "original" order carry on executing, with the tacit assumption that ExecutionReport rejections with OrdRejReason=DuplicateOrder do not mean that the actual originally submitted order has been rejected?
>
> Is there a common practice wrt this situation?
>
> Thanks much.
>
> I would expect the "original" order to continue to be live and carry on executing.
>
> > I hope someone can tell me what the correct response is to a NewOrderSingle message with a duplicate ClOrdID at the application level…
> >
> > If a NewOrderSingle with ClOrdID is submitted with ClOrdID=A, then while it is active, another NewOrderSingle, also with ClOrdID=A comes in, order state change matrix D22 shows that the response is to be an ExecutionReport with ClOrdID=A, ExecType=Rejected, and OrdRejReason=DuplicateOrder. Note that this rejection shows the fill information for the "original" order.
> >
> > Does this imply that the "original" order with ClOrdID=A is now "dead" (and should be cancelled behind the scenes)? Can the "original" order carry on executing, with the tacit assumption that ExecutionReport rejections with OrdRejReason=DuplicateOrder do not mean that the actual originally submitted order has been rejected?
> >
> > Is there a common practice wrt this situation?
> >
> > Thanks much.
> >
>
The ‘original’ order is still live - note that in D22 Line 5 the OrdStatus is Partially Filled with CunQty = 1000 & LeavesQty = 9000 meaning that 1000 has been filled and there is 9000 still available to be executed on the order