NewOrderSingle with ExecInst (18) = 5 (Held)

, ,
1

Imported from previous forum

2

We have a requirement to accept an order that needs to be recorded in our system, but is not to be executed immediately - it will need to be fully or partially executed at a subsequent time, in response to another message. It seems that NewOrderSingle with ExecInst (18) = 5 (Held) would be appropriate for the initial order.

Would anyone happen to know what would be an appropriate message that we could specify that we would like to receive at a later stage that, basically, says - “now execute such-and-such order in full or partially!”?

Thanks.

3

EffectiveTime (168) or TradingSessionID (336) may be used to state when an order becomes effective.

ExecInst=Held has a different meaning. Traditionally, it is an instruction to a broker to use discretion to hold an order to try to work it for a better price.

4

What if, from the broker perspective, the broker took ExecInst=Held as an instruction to hold the order, but then required that an additional instruction was issued by the other party to release the order, fully or partially (rather than making its own decision)? What would that second instruction be?

5

The opposite ExecInst of Held is NotHeld (1). That is, get whatever price the market will bear. These instructions only make sense for high-touch orders, not electronic execution.

An alternative would be cancel/replace with TimeInForce = Immediate Or Cancel (IOC).

6

Thanks Donald. I am curious though - is it acceptable to send two NewOrderSingles for the same trade? Basically, the broker receives a NewOrderSingle with ExecInst=Held and OrderQty=1M, then some time later it receives another NewOrderSingle with ExecInst=NotHeld (which it would take to mean “release now”), the same ClOrdID (cancel/replace is not an option here), and OrderQty=1M.

Is there a way to indicate that this NewOrderSingle is a duplicate of a previous one? Or just the fact that ClordID is a duplicate of a ClOrdID that was received some time before an indication enough?

7

ClOrdID must be unique, so a second order with the same ID would be rejected as a duplicate.

I think what you are suggesting is contingent order instructions. You send two orders in a NewOrderList with instructions to either execute one or the other, but not both.

See http://fixwiki.org/fixwiki/ContingencyType/1_OneCancelsTheOther

8

Hi George,

We use ExecInst = Suspend (S) and ExecInst = Work (2).

Why the replace request is not an option? If I understand your need, the workflow should be:

  • the first party sends a single order ClOrdID=AAA and ExecInst=S;
  • the first party receives an acknowledgment;
  • the second party receives the acknowledgment (unsolicited - drop-copy);
  • the second party sends a replace request ClOrdID=BBB | OrigClOrdID=AAA | ExecInst=2;
  • both parties receive the acknowledgment of the replacement.

Xavier.

9

Hi George,
The second message [to activate the order] should be an OrderCancelReplaceRequest[35=G].

You may follow Don’s proposal or alternative consider using the TriggeringInstructions

Specifically, on the original NewOrderSingle[35=d] attach: TriggerType(1100) = On Order Entry or order modification entry(5)

When the time to trigger the order arrives, send an OrderCancelReplaceRequest[35=G] having TriggerType(1100) = 5 and TriggerAction(1101) = Activate(1)

I hope that this helps,
Yuval