Search code examples
fix-protocol

Fix Protocol: How to handle 3-way OCO orders

I have a situation where I get 4 orders from my customer (see below). One order is an OTO (Order triggers order) and it will trigger the other three orders if it gets filled. Those three orders OCO (Order cancels order) each other. So, if one gets filled, the other two get cancelled.

CME-ES.Enter ~ B 2 @ESM15 @ 2048.25 Limit Day [OTO CME-ES.ExitL, CME-ES.ExitS, CME-ES.ExitT]
CME-ES.ExitL ~ S 2 @ESM15 @ 2040.25 Limit Day [OCO CME-ES.ExitS, CME-ES.ExitT]
CME-ES.ExitS ~ S 2 @ESM15 @ 2058.25 Stop Day [OCO CME-ES.ExitL, CME-ES.ExitT]
CME-ES.ExitT ~ S 2 @ESM15 @ 1/24/2015 3:50pm Time Day [OCO CME-ES.ExitL, CME-ES.ExitS]

Note: "CME-ES.Enter" is the ClOrdID

This system has the normal stop and limit orders to exit, but it also has a third order to exit at a specific time.

This type of three way OTO/OCO does not exist (I think) within the fix specifications. Unless there is a tag where all of these orders would cancel (or go to the market) at a certain time.

If there is no normal way of doing this... a few options seem like a custom way of handling this. I could send the orders in a list and provide OTO/OCO instructions in the Text(58) field of each order... or perhaps in the ListExecInst(69)... and essentially put the text that is between brackets in the customer orders.

1) Is there an official way to handle this?

2) Is there some other non-official, but common use way of doing this?

3) If not 1 or 2, would my way seem like a good approach.

4) Is my suggestion above reasonable... or is it a horrible twisted way of using fix?

Thanks! - Brian

Note: I am programming the acceptor and will receive these messages... but will define what is to be sent.

Solution

  • It has been four years, but may be somebody will be looking for this information. Here is what I can find:

    There is no standard way to model OTO+OCO orders submissions.

    • CQG handles similar but simpler case using Order List Request v .

    • Integral handles similar case using a sequence of New Order Single (35=D) requests where subsequent orders link to predecessor and define their contingency type.