Imported from previous forum
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
It seems fair to require that ClOrdID be unique for all orders for the day as well as live orders carrying over from previous days.
What should be done if a broker sends an order that has the same ClOrdID as a previous order for that firm, but the message is not flagged PossResend? I don’t feel that I should process it as a new order. I can log it as an error, but how then should I respond? I see two alternatives:
Ignore the message.
Send an Execution - Reject, with the same ClOrdID, but with a unique OrderID. This runs the risk of the broker making a match based on ClOrdID and thinking the first order was rejected.
Neither look very attractive. Which is the lesser of the two evils, or is there anything I’m overlooking?
Ryan Pierce
Townsend Analytics Ltd.
[ original email was from Anthony Gallard - anthony.gallard@hsbcib.com ]
> It seems fair to require that ClOrdID be unique for all orders for the day as well as live orders carrying over from previous days.
>
> What should be done if a broker sends an order that has the same ClOrdID as a previous order for that firm, but the message is not flagged PossResend? I don’t feel that I should process it as a new order. I can log it as an error, but how then should I respond? I see two alternatives:
>
> Ignore the message.
>
> Send an Execution - Reject, with the same ClOrdID, but with a unique OrderID. This runs the risk of the broker making a match based on ClOrdID and thinking the first order was rejected.
>
> Neither look very attractive. Which is the lesser of the two evils, or is there anything I’m overlooking?
>
> Ryan Pierce
> Townsend Analytics Ltd.
>
Hi Ryan,
As the implementation of the various trading systems sat behind the FIX layer differs wildly from one institution to another we deal with this problem in the following way.
When we receive new order message we append the date to the ClOrdId to make it unique, this process is applied to all subsequent recieved messages (Amendments, Cancellations, etc…). On the outward bound message flow we strip the date off (So this. We decided to use this way because so many of our clients re-used their ClOrdId’s over the following days.
I hope this helps.
Ant
Hi Ryan,
You can Send a SessionRejection Message( Msg Type = 3) back to the customer saying that Message with Duplicate ClOrdID received. This is what we are doing in our FixEngine. In the Text field of SessionRejection message, you can say clearly the reason for which your System rejecting the Client message.
I hope this helps.
Kannan B ( bkannan@ften.com )
Ften Inc.
> > It seems fair to require that ClOrdID be unique for all orders for the day as well as live orders carrying over from previous days.
> >
> > What should be done if a broker sends an order that has the same ClOrdID as a previous order for that firm, but the message is not flagged PossResend? I don’t feel that I should process it as a new order. I can log it as an error, but how then should I respond? I see two alternatives:
> >
> > Ignore the message.
> >
> > Send an Execution - Reject, with the same ClOrdID, but with a unique OrderID. This runs the risk of the broker making a match based on ClOrdID and thinking the first order was rejected.
> >
> > Neither look very attractive. Which is the lesser of the two evils, or is there anything I’m overlooking?
> >
> > Ryan Pierce
> > Townsend Analytics Ltd.
> >
>
> Hi Ryan,
>
> As the implementation of the various trading systems sat behind the FIX layer differs wildly from one institution to another we deal with this problem in the following way.
>
> When we receive new order message we append the date to the ClOrdId to make it unique, this process is applied to all subsequent recieved messages (Amendments, Cancellations, etc…). On the outward bound message flow we strip the date off (So this. We decided to use this way because so many of our clients re-used their ClOrdId’s over the following days.
>
> I hope this helps.
>
> Ant
>
>
>
I would avoid a session level reject.
Suggest execution report rejecting the order with OrdRejReason of 0 "Broker option" or 6 "Duplicate Order" and Text of "Duplicate ClOrdID"
> Hi Ryan,
>
> You can Send a SessionRejection Message( Msg Type = 3) back to the customer saying that Message with Duplicate ClOrdID received. This is what we are doing in our FixEngine. In the Text field of SessionRejection message, you can say clearly the reason for which your System rejecting the Client message.
>
> I hope this helps.
>
> Kannan B ( bkannan@ften.com )
> Ften Inc.
>
> > > It seems fair to require that ClOrdID be unique for all orders for the day as well as live orders carrying over from previous days.
> > >
> > > What should be done if a broker sends an order that has the same ClOrdID as a previous order for that firm, but the message is not flagged PossResend? I don’t feel that I should process it as a new order. I can log it as an error, but how then should I respond? I see two alternatives:
> > >
> > > Ignore the message.
> > >
> > > Send an Execution - Reject, with the same ClOrdID, but with a unique OrderID. This runs the risk of the broker making a match based on ClOrdID and thinking the first order was rejected.
> > >
> > > Neither look very attractive. Which is the lesser of the two evils, or is there anything I’m overlooking?
> > >
> > > Ryan Pierce
> > > Townsend Analytics Ltd.
> > >
> >
> > Hi Ryan,
> >
> > As the implementation of the various trading systems sat behind the FIX layer differs wildly from one institution to another we deal with this problem in the following way.
> >
> > When we receive new order message we append the date to the ClOrdId to make it unique, this process is applied to all subsequent recieved messages (Amendments, Cancellations, etc…). On the outward bound message flow we strip the date off (So this. We decided to use this way because so many of our clients re-used their ClOrdId’s over the following days.
> >
> > I hope this helps.
> >
> > Ant
> >
> >
> >
>
[ original email was from Marinos Pappas - marinos.pappas@gs.com ]
Most OMSs would interpret this message as a rejection of the original order, which would cause inconstistency (order would be rejected at the client’s side but still live at the broker).
We send a Status Execution Report, which tells the client that we have this order and its state is as specified in this message.
> I would avoid a session level reject.
>
> Suggest execution report rejecting the order with OrdRejReason of 0 “Broker option” or 6 “Duplicate Order” and Text of “Duplicate ClOrdID”
>
> > Hi Ryan,
> >
> > You can Send a SessionRejection Message( Msg Type = 3) back to the customer saying that Message with Duplicate ClOrdID received. This is what we are doing in our FixEngine. In the Text field of SessionRejection message, you can say clearly the reason for which your System rejecting the Client message.
> >
> > I hope this helps.
> >
> > Kannan B ( bkannan@ften.com )
> > Ften Inc.
> >
> > > > It seems fair to require that ClOrdID be unique for all orders for the day as well as live orders carrying over from previous days.
> > > >
> > > > What should be done if a broker sends an order that has the same ClOrdID as a previous order for that firm, but the message is not flagged PossResend? I don’t feel that I should process it as a new order. I can log it as an error, but how then should I respond? I see two alternatives:
> > > >
> > > > Ignore the message.
> > > >
> > > > Send an Execution - Reject, with the same ClOrdID, but with a unique OrderID. This runs the risk of the broker making a match based on ClOrdID and thinking the first order was rejected.
> > > >
> > > > Neither look very attractive. Which is the lesser of the two evils, or is there anything I’m overlooking?
> > > >
> > > > Ryan Pierce
> > > > Townsend Analytics Ltd.
> > > >
> > >
> > > Hi Ryan,
> > >
> > > As the implementation of the various trading systems sat behind the FIX layer differs wildly from one institution to another we deal with this problem in the following way.
> > >
> > > When we receive new order message we append the date to the ClOrdId to make it unique, this process is applied to all subsequent recieved messages (Amendments, Cancellations, etc…). On the outward bound message flow we strip the date off (So this. We decided to use this way because so many of our clients re-used their ClOrdId’s over the following days.
> > >
> > > I hope this helps.
> > >
> > > Ant
> > >
> > >
> > >
> >
>
Clearly duplicate ClOrdID without PossResend flag by itself indicates serious inconsistency, which normally requires manual intervention (the orders may be completely different in client and broker systems). Many (most) OMS simply ignore session Reject as well as Business Message Reject. Often those don’t even reach OMS as they may be handled at the FIX engine/gateway level. Now the question is what would be preferable from the support and error escalation point of view. Often ER Rejected is more likely to bring users attention. In fact this is required by the FIX spec, for example please see Appendix D, case D22 in the FIX 4.2 spec.
> Most OMSs would interpret this message as a rejection of the original order, which would cause inconstistency (order would be rejected at the client’s side but still live at the broker).
>
> We send a Status Execution Report, which tells the client that we have this order and its state is as specified in this message.
>
> > I would avoid a session level reject.
> >
> > Suggest execution report rejecting the order with OrdRejReason of 0 “Broker option” or 6 “Duplicate Order” and Text of “Duplicate ClOrdID”
> >
> > > Hi Ryan,
> > >
> > > You can Send a SessionRejection Message( Msg Type = 3) back to the customer saying that Message with Duplicate ClOrdID received. This is what we are doing in our FixEngine. In the Text field of SessionRejection message, you can say clearly the reason for which your System rejecting the Client message.
> > >
> > > I hope this helps.
> > >
> > > Kannan B ( bkannan@ften.com )
> > > Ften Inc.
> > >
> > > > > It seems fair to require that ClOrdID be unique for all orders for the day as well as live orders carrying over from previous days.
> > > > >
> > > > > What should be done if a broker sends an order that has the same ClOrdID as a previous order for that firm, but the message is not flagged PossResend? I don’t feel that I should process it as a new order. I can log it as an error, but how then should I respond? I see two alternatives:
> > > > >
> > > > > Ignore the message.
> > > > >
> > > > > Send an Execution - Reject, with the same ClOrdID, but with a unique OrderID. This runs the risk of the broker making a match based on ClOrdID and thinking the first order was rejected.
> > > > >
> > > > > Neither look very attractive. Which is the lesser of the two evils, or is there anything I’m overlooking?
> > > > >
> > > > > Ryan Pierce
> > > > > Townsend Analytics Ltd.
> > > > >
> > > >
> > > > Hi Ryan,
> > > >
> > > > As the implementation of the various trading systems sat behind the FIX layer differs wildly from one institution to another we deal with this problem in the following way.
> > > >
> > > > When we receive new order message we append the date to the ClOrdId to make it unique, this process is applied to all subsequent recieved messages (Amendments, Cancellations, etc…). On the outward bound message flow we strip the date off (So this. We decided to use this way because so many of our clients re-used their ClOrdId’s over the following days.
> > > >
> > > > I hope this helps.
> > > >
> > > > Ant
> > > >
> > > >
> > > >
> > >
> >
>