Imported from previous forum
[ original email was from Shay Gordon - ]
We propose an application-level reject of order status requests for unknown orders. This would mean a new OrdStatus enum to indicate "unknown order". Comments?
[ original email was from Newton White - ]
> We propose an application-level reject of order status requests for unknown orders. This would mean a new OrdStatus enum to indicate "unknown order". Comments?
What do broker implementations actually do when an institution requests order status for an unknown order? Do they make no response, send an administrative level Reject message, or something else?
The proposal quoted above is quite attractive. Making no response is emotionally unsatisfying. Providing an administrative level "Reject" would seem to require either that the administrative level code know how to decide whether an order is known or that the application level code know the MsgSeqNum for an Order Status Request and be permitted to send an administrative level reject.
However, the proposal does raise some side issues. If this proposal were adopted, then how would one fill in the required fields (and certain interesing optional fields) in the Execution Report? Consider:
Tag 37, OrderID: This is normally assigned by the broker. It is optional in the status report request. Should the broker assign a new order number to the unknown order? If the institution provided Tag 37 in the Order Status Request,
should the broker parrot back that information? (Presumably not, since the OrderID provided by the institution might match the OrderID for a real order.)
Tag 11, ClOrdID: This is not required in an Execution Report. It is, however, required in an Order Status Request. Should the broker be required to provide this field with the information provided by the institution in the Order Status Request? (This might be the only way that the institution could figure out what was happening since the OrderID provided by the broker in the Execution Report is not guaranteed to match any OrderID known to the institution.)
Tag 17, ExecID: select in the normal way. This is required in the Order Status Report and not permitted in the Order Status Request.
Tag 20, ExecTranType: Status
Tag 39, OrdStatus: Unknown Order (presumably, "D")
Tag 55, Symbol: parrot back the value that is required to be included in the request, even if it is invalid
Tag 54, Side: parrot back the value from the request
Tag 38, OrderQty: How about 0? This field is required in the Execution Report. The request is prohibited from including this information. The broker denies that the order exists.
Tag 14, CumQty: How about 0? This field is required in the Execution Report. The request is prohibited from including this information. The broker denies that the order exists.
Tag 6, AvgPx: How about 0? This field is required in the Execution Report. The request is prohibited from including this information. The broker denies that the order exists.
Also, should the broker do anything special if the institution submits a Don’t Know Trade message in response to an Execution Report with OrdStatus = Unknown Order? (Which seems likely to happen, particularly if the broker assigns a new OrderID for the unknown order.)
[ original email was from Scott Atwell - ]
Our thoughts (as an Institution) re: Newton White’s posting…
>>Tag 37, OrderID: This is normally assigned by the broker. It is optional in the status report request. Should the broker assign a new order number to the unknown order? If the institution provided Tag 37 in the Order Status Request,
should the broker parrot back that information? (Presumably not, since the OrderID provided by the institution might match the OrderID for a real order.)
The field should be specified in the Execution Report response and should be the same value provided for Tag 37 in the Order Status Reqeust. If it was not provided in the Order Status Request, it should be a default, invalid value
like "UNKNOWN".
>>Tag 11, ClOrdID: This is not required in an Execution Report. It is, however, required in an Order Status Request. Should the broker be required to provide this field with the information provided by the institution in the Order Status Request? (This might be the only way that the institution could figure out what was happening since the OrderID provided by the broker in the Execution Report is not guaranteed to match any OrderID known to the institution.)
It should definitely be the same ClOrdID specified in the Order Status Request.
>>Tag 17, ExecID: select in the normal way. This is required in the Order Status Report and not permitted in the Order Status Request.
I think this could be 0. Same issues/rules would apply if use "Calculated" or "Cancelled", etc at an order level with the ExecutionRpt.
>>Tag 20, ExecTranType: Status
Fine.
>>Tag 39, OrdStatus: Unknown Order (presumably, "D")
Fine.
>>Tag 55, Symbol: parrot back the value that is required to be included in the request, even if it is invalid
Yes.
>>Tag 54, Side: parrot back the value from the request
Yes.
>>Tag 38, OrderQty: How about 0? This field is required in the Execution Report. The request is prohibited from including this information. The broker denies that the order exists.
Yes. Specify as 0.
>>Tag 14, CumQty: How about 0? This field is required in the Execution Report. The request is prohibited from including this information. The broker denies that the order exists.
Yes. Specify as 0. This is the same way it works on a "New".
>>Tag 6, AvgPx: How about 0? This field is required in the Execution Report. The request is prohibited from including this information. The broker denies that the order exists.
Yes. Specify as 0. This is the same way it works on a "New".
>>Also, should the broker do anything special if the institution submits a Don’t Know Trade message in response to an Execution Report with OrdStatus = Unknown Order? (Which seems likely to happen, particularly if the broker assigns a new OrderID for the unknown order.)
I don’t think an Insititution should DK this since they initiated the sequence but would likely generate an error/alert internaly to the fact this scenario has occurred. Besides, the Institution is more likely to deal with ClOrdID than OrderID.
[ original email was from Azriel Horowitz - azriel@mash.com ]
> We propose an application-level reject of order status requests for unknown orders. This would mean a new OrdStatus enum to indicate "unknown order". Comments?
>
Could someone tell me under the current FIX protocol what to respond to a status request when the order is not found.
[ original email was from Mark Hinman - mhinman@easetech.com ]
Currently there is no way to respond to a received Order Modify Request which has no matching order. This is also true for “Order Cancel Request” and “Order Modify Request”. Currently the Institition has the “Don’t Know” message to allow for application level rejects of unexpected execution reports. The appropriate way to extend the protocol would be to add a “Unknown Order” message to the protocol that could be used in response to Order Status/Modify/Cancel request messages. This message only requires ClOrdID and maybe a couple of parrot fields (i.e. Symbol etc.).
Attempting to squease the unknown order into the "Execution Reports" message would be mistake.
For clarity on the circumstances were this may happen during normal activities. Orders do not have a clearly defined scope, so most system istitute a horizon policy where after a certain number of days the orders are deleted. Many system only support day orders and therefore if you were to ask about an order for yesterday, the other side would not know about it.
> > We propose an application-level reject of order status requests for unknown orders. This would mean a new OrdStatus enum to indicate "unknown order". Comments?
> >
>
> Could someone tell me under the current FIX protocol what to respond to a status request when the order is not found.
>
[ original email was from Charles Paclat - paclat@latrade.com ]
> Currently there is no way to respond to a received Order Modify Request which has no matching order. This is also true for “Order Cancel Request” and “Order Modify Request”. Currently the Institition has the “Don’t Know” message to allow for application level rejects of unexpected execution reports. The appropriate way to extend the protocol would be to add a “Unknown Order” message to the protocol that could be used in response to Order Status/Modify/Cancel request messages. This message only requires ClOrdID and maybe a couple of parrot fields (i.e. Symbol etc.).
>
> Attempting to squease the unknown order into the “Execution Reports” message would be mistake.
>
> For clarity on the circumstances were this may happen during normal activities. Orders do not have a clearly defined scope, so most system istitute a horizon policy where after a certain number of days the orders are deleted. Many system only support day orders and therefore if you were to ask about an order for yesterday, the other side would not know about it.
>
>
> > > We propose an application-level reject of order status requests for unknown orders. This would mean a new OrdStatus enum to indicate “unknown order”. Comments?
> > >
> >
> > Could someone tell me under the current FIX protocol what to respond to a status request when the order is not found.
> >
>
In the the FIX 4.1 Protocol Specification the OrdRejReason(103) was expanded to include a reason of 5=Unknown Order