what is the best practice to implement OCO orders?

Imported from previous forum

[ original email was from Nick Evgeniev - nick@devexperts.com ]
what is the best practice to implement OCO (one cancel other) orders with fix? I’ve scanned the docs but haven’t found direct support for such orders (though they are fairly common in forex world). Am I missed something? (I think so)

[ original email was from dave gibbs - gibbsd@igindex.co.uk ]
> what is the best practice to implement OCO (one cancel other) orders

with fix? I’ve scanned the docs but haven’t found direct support for
such orders (though they are fairly common in forex world). Am I missed
something? (I think so)

If I understand your question, is this an “Order Cancel Replace Request” message ? About which btw I am also searching for an answer :slight_smile:

[ original email was from Dan McCarthy - djmccarthy@statestreet.com ]
> what is the best practice to implement OCO (one cancel other) orders

with fix? I’ve scanned the docs but haven’t found direct support for
such orders (though they are fairly common in forex world). Am I
missed something? (I think so)
Try using tag 583 - ClOrdLinkID. This would allow you to link one order to another. You might also need a custom tag that specifies the nature of this link. (i.e. “OCO”) Something like ClOrdLinkType as a custom tag for this purpose.

[ original email was from Nick Evgeniev - nick@devexperts.com ]
> > what is the best practice to implement OCO (one cancel other) orders

with fix? I’ve scanned the docs but haven’t found direct support for
such orders (though they are fairly common in forex world). Am I
missed something? (I think so)

If I understand your question, is this an “Order Cancel Replace Request”
message ? About which btw I am also searching for an answer :slight_smile:

Not exactly. :slight_smile: With OCO orders you issue two orders (usually stop and limit) one to take the profit and one two stop losses. They are mutaly exclusive orders i.e. if one get filled the other must be canceled automatically… So I’m looking for common practice to implement such usecase with FIX.

Hence solutiion suggested by Dan McCarthy is much more close to what I’m looking for, though it lacks of atomicity. I.e. I have to issue such orders separately (one-by-one)… On other side it might not to be a problem at all since these orders are two different entities anyway and has to be processed separatelly by execution engine.