Re: Market on close orders pre-assignment
Mahesh Kumaraguru <>
6 Aug 2010 3:12PM ET
Hanno,
Pre-assignment of matched market close orders may need a new order status instead of order status=New because they have been pre-assigned and so in a sense are future executed, its neither New in terms of being fully cancelable nor is it Part-Filled or Filled because that "will" occur in the future. So the order submitter cannot cancel the pre-assigned locked quantity but has the freedom to cancel the unlocked quantity.
OrdStatus=Partially-filled / Filled cannot be used because the order is still not actually executed. Also when partially-filled / filled is used, price is required and market close price is not known before the market has actually closed.
Using OrdStatus=New and LockedQty>0 to mean pre-assignment could work, but a cleaner solution I see is an introduction of a new order status and corresponding order state change matrices.
Assuming a new order status enum is assigned for preassigned, in ExecReports when OrdStatus=Pre-assigned LastQty would become required and LastPx would become optional.
Also I recommend that when OrdStatus=Pre-Assigned, ExecType 150=I Order Status & ExecTransType=0 New be used. And have LeavesQty = OrderQty - CumQty so that order submitter knows what quantity can be cancelled.
Regards,
K. Mahesh
> I am very, very cautious with new values for OrdStatus as this could severely impact existing applications. This translates to leaving OrdStatus = "New" with an additional field LockedQty having a non-zero value and showing that:
>
> a) the order has not matched yet (in a regulatory sense)
> b) part (or all) of the order quantity has been pre-assigned is (currently) not available for matching
>
> This allows to model Carlos' scenario but also many others where part or all of the order is temporarily not considered for matching or not accessible to the submitter. LockedQty is always equal to or less than LeavesQty. Orders could be locked and released and partially match multiple times during the trading day. In the more general case, OrdStatus could hence also be "Partially Filled" when locking occurs but would not change to this status due to locking.
>
> > Hanno,
> >
> > What order status would you reccomend for a "pre-assignment locked" fill ? Would we need a new order status or would OrderStatus=PartiallyFilled / Filled suffice for this because at market close these preassigned / locked orders would anyway be partfilled / filled ?
> >
> > Regards,
> > K. Mahesh
> >
> > > Carlos,
> > >
> > > sounds good, a few more comments and issues to consider:
> > >
> > > - You did not say which ExecType value you would want to use. You would need to send a price if sent as a fill (FIX 4.2 ExecType 1 or 2). Maybe it is better to send it as a restatement (ExecType D) and populate the lock fields to indicate the pre-assignment. The lock fields can be removed again at the end of the day when confirming the trade (unless you have multiple pre-assignments, i.e. your locked qty only gets reduced until it is finally zero)
> > > - Apart from the technical issue (price needed for ExecType conveying a fill), there might be a business reason to not send a trade until it is actually done at the end of the day. What if the market is halted for some reason and "on close" orders are removed?
> > > - Filled orders are considered to be in a terminal state (at least by exchanges) and fall out of the pool of active orders. You might not be able to inquire the order anymore (in your case the sell order for 500). Keeping the order state "New" avoids this problem.
> > > - Modifications of "on close" orders (if permitted) need to take the locked qty into account and be rejected if the new qty falls below the locked qty (in your example, changing 1000 to less than 500)
> > > - If you DO send out the pre-assignment as a trade: you described FIX 4.2 where ExecTransType is still valid. As of FIX 4.3 this field is deprecated and it would be just ExecType = G = Trade Correct instead.
> > > - I will add another value "Pre-Assignment Lock" to the intended new standard field LockType (subject to committee discussion and approval)
> > >
> > > Regards,
> > > Hanno.
> > >
> > > > Hanno,
> > > >
> > > > Thank you so much for your response! it is indeed strange that you can't modify the order despite being just a pre-allocation.
> > > >
> > > > Based on your suggestions, I feel the following behavior could be a clean FIX implementation:
> > > >
> > > > 1. Two orders, one for buy 1000 @ market close and one for sell 500 @ market close are received
> > > > 2. the buy & sell are matched and each party is informed that 500 shares are 'pre-assigned' to the other party. An ExecutionReport is sent with no price but ExecId=E1 and LockedQty[7770] and LockedInStatus[9487] to indicate that is a pre-assignment.
> > > > 3. the buyer can only cancel now up to 500 shares. The seller cannot cancel anything.
> > > > 4. At the end of the day, the pre-assignments turn into real matches and the buyer and seller get an execution report where ExecTransType[20]=Correction, the correct Price is sent and RefExecId=A1
> > > >
> > > > This way a FIX compliant OMS could process the order correctly, even if it does not take in account the pre-allocation tags.
> > > >
> > > > Warm regards
> > > >
> > > > -C
> > > >
