Imported from previous forum
Need to know how to handle the following
ORD1 BUY 30 AAPL @ 10 - ordQty=30 cumQty=0 leaves=30 ordStatus=new(0)
Fill 20 - ordQty=30 cumQty=20 leaves=10 ordStatus=part(1)
REP1 replaces ORD1 reducing ordQty to 10 (ordQty=cumQty)
FIX doc 4.2 states - ‘Requests to replace the OrderQty to a level less than the CumQty will be interpreted by the broker as requests to stop executing the order’
If change to ordQty is > cumQty then ordStatus=part(1)
I see nothing about reducing ordQty to = cumQty
Is the order cancelled or filled and what are the values of ordStatus, lastShares,…
In the scenerio above would the REP1
Hi David,
You can make Order Qty = Cum Qty for normal orders where the leaves qty is not locked by any other means.
You can also attempt to replace, where Order Qty is < Cum Qty. This is legal due to race conditions imposed as a result of the transmission delay. (Execution in transit, when you decided to replace with a decrease)In this case, the exchange will force the replace to cum qty and not below.
In both the above cases, Order status is “Filled” (2) Since it takes precedence over “Replaced”. Last shares will be 0 and Exec type is “Replaced” (5).
Hope this cleared your question.
Rgds,
Thaya.
Need to know how to handle the following
ORD1 BUY 30 AAPL @ 10 - ordQty=30 cumQty=0 leaves=30 ordStatus=new(0)
Fill 20 - ordQty=30 cumQty=20 leaves=10 ordStatus=part(1)REP1 replaces ORD1 reducing ordQty to 10 (ordQty=cumQty)
FIX doc 4.2 states - ‘Requests to replace the OrderQty to a level less
than the CumQty will be interpreted by the broker as requests to stop
executing the order’If change to ordQty is > cumQty then ordStatus=part(1)
I see nothing about reducing ordQty to = cumQty Is the order cancelled
or filled and what are the values of ordStatus, lastShares,… In the
scenerio above would the REP1
[ original email was from John Prewett - jprewett@lavatrading.com ]
Deviating from the subject somewhat, I must admit that I don’t particularly like the way the FIX standard stipulates that you manage a cxl/replace request where OrderQty is reduced to less than (or equal to) the already executed quantity.
FIX stipulates, as Sri correctly mentioned in the last post, that you issue an ExecReport with ExecType=replaced; OrdStatus=filled; OrderQty=CumQty; LeavesQty=0. For examples of the standard, please see FIX.5.0 SP1 Volume 4 example c.3.b and c.3.c.
I don’t like the concept of altering the OrderQty on an ExecReport and I believe many simplistic OMS engines wouldn’t even be looking for this to change and might get angry if you return an OrderQty value that wasn’t what they submitted.
I prefer handling the issue in a non-standard way that has a much higher probability of keeping even the simplest of OMS in sync with the correct order state. Please notice that this method works just fine with all versions of FIX.
I send out two messages:
- Unsolicited cancel of the original order.
- CancelReject for the cxl/replace request.
This should guarantee that the OMS handles the situation correctly and the order ends up in the correct state.
The only downsides are:
A. Not obeying the FIX standard. I therefore strongly disapprove of myself.
B. The OMS may alert users upon receipt of an unsolicited cancel.
Comments?
JohnP
Hi all,
Practically I do agree with your suggested practice John. Even in your case, its completely legal and should be expected by OMSs. Even if the exchange tried to cancel (Unsolicited), there can be a cancel replace in transit (already sent out by the OMS). In that case, the sequence of messages would be exactly what you have stated.
Hence from a more practical point of view, rather than two entities (OMS and Exchange) deciding the quantity to replace, its more clean to leave the authority of taking the remedial action to the OMS and send an unsolicited cancel and a cancel replace reject. Perhaps John, Cancel reject reason could be made to communicate the cause of the cancellation , which, in this case will be the attempt to reduce below CumQty.
Rgds,
Thaya.
Deviating from the subject somewhat, I must admit that I don’t
particularly like the way the FIX standard stipulates that you manage a
cxl/replace request where OrderQty is reduced to less than (or equal to)
the already executed quantity.FIX stipulates, as Sri correctly mentioned in the last post, that you
issue an ExecReport with ExecType=replaced; OrdStatus=filled;
OrderQty=CumQty; LeavesQty=0. For examples of the standard, please see
FIX.5.0 SP1 Volume 4 example c.3.b and c.3.c.I don’t like the concept of altering the OrderQty on an ExecReport and I
believe many simplistic OMS engines wouldn’t even be looking for this to
change and might get angry if you return an OrderQty value that wasn’t
what they submitted.I prefer handling the issue in a non-standard way that has a much higher
probability of keeping even the simplest of OMS in sync with the correct
order state. Please notice that this method works just fine with all
versions of FIX.I send out two messages:
- Unsolicited cancel of the original order.
- CancelReject for the cxl/replace request.
This should guarantee that the OMS handles the situation correctly and
the order ends up in the correct state. The only downsides are:
A. Not obeying the FIX standard. I therefore strongly disapprove
of myself.
B. The OMS may alert users upon receipt of an unsolicited cancel.Comments?
JohnP
John,
I have a couple of comments to your suggestion. Your model could work if one sees the Order Cancel/Replace request as two requests within a single message. In the given case, the cancel would be successful (an ExecutionReport confirms that) and the replace would be unsuccessful (an Order Cancel Reject confirms this part).
The link between the two is the ClOrdID of the Order Cancel/Replace Request. it would need to be used in both responses and the OMS would need to be prepared to get more than one response for a singel request. In general, this should not be a problem as multiple executions following from a New Order Single or Order Cancel Replace can result in multiple Execution Reports. The difference obviously is that there are two different messages types being returned for a single request.
The message flow would need to change to allow the following scenarios for an Order Cancel/Replace request:
- Request cannot be executed at all → send Order Cancel Reject
- Request can be executed completely → send Execution Report
- Cancel can be executed but not the replace without violating OrdQty=CumQty+LeavesQty → send Execution Report confirming the cancel followed by Order Cancel Reject rejecting the replacement
I do not know if there had been discussions at the time and why the third scenario is not part of the standard. One argument might be that it increases the number of response messages which is something at least exchanges are never fond of.
The alternative I prefer is to omit the Order Cancel Reject message as it does not add new information. The ER confirming the cancel can carry the total as well as the executed quantity and is allowed to violate OrdQty=CumQty+LeavesQty due to the following. For OrdStatus “Canceled” takes precedence over “Partially Filled” (as opposed to “Filled” which has precedence over “Canceled”), i.e. you only need to change ExecType from Replaced to Canceled to express that the replace request has been changed to a cancel request. LeavesQty can be set to zero as an exception to the rule above due to the values of OrdStatus and ExecType both being “Canceled”.
The ClOrdID ties the response to the request. The OMS would need to cope with a response to a replace request that does not have ExecType=“Replaced” but ExecType=“Canceled”. The upside of this variant is that OrdQty is not changed to a value never sent and the response is equal to the one for a cancel request, i.e. it is no longer an unsolicited cancel. This way it stays closer to the current FIX concepts I believe.
Interesting discussion, unfortunately about some of the fundamentals of FIX concepts which makes it quite hard to change. That does not mean it cannot be changed.
Regards,
Hanno.
Deviating from the subject somewhat, I must admit that I don’t
particularly like the way the FIX standard stipulates that you manage a
cxl/replace request where OrderQty is reduced to less than (or equal to)
the already executed quantity.FIX stipulates, as Sri correctly mentioned in the last post, that you
issue an ExecReport with ExecType=replaced; OrdStatus=filled;
OrderQty=CumQty; LeavesQty=0. For examples of the standard, please see
FIX.5.0 SP1 Volume 4 example c.3.b and c.3.c.I don’t like the concept of altering the OrderQty on an ExecReport and I
believe many simplistic OMS engines wouldn’t even be looking for this to
change and might get angry if you return an OrderQty value that wasn’t
what they submitted.I prefer handling the issue in a non-standard way that has a much higher
probability of keeping even the simplest of OMS in sync with the correct
order state. Please notice that this method works just fine with all
versions of FIX.I send out two messages:
- Unsolicited cancel of the original order.
- CancelReject for the cxl/replace request.
This should guarantee that the OMS handles the situation correctly and
the order ends up in the correct state. The only downsides are:
A. Not obeying the FIX standard. I therefore strongly disapprove
of myself.
B. The OMS may alert users upon receipt of an unsolicited cancel.Comments?
JohnP
In all of your solutions should the replace request be handled the same whether the order is
(1) 1st partially filled and execution report sent then replace request to reduce qty received (do not pass)
or
(2) partial passes replace request.
Most examples in Appendix D refer to in-flight handling only.
It should not matter as the order book situation (onto which the replace request is applied) is the same in both cases.
In the first case the replace request to reduce qty below CumQty is made even though the current CumQty is known to be higher than my desired total quantity. I would attribute that to bad programming, i.e. not to check the remaining quantity prior to issuing a replace request.
Only the second case is of interest, i.e. the order book situation has changed but I do not yet have knowledge about it. I still have the previous CumQty and decide to reduce the total quantity to a value ABOVE CumQty (otherwise I would use a cancel request). The in-flight condition makes it possible for me to make a “mistake” as the partial fill passes my replace request.
In all of your solutions should the replace request be handled the same
whether the order is
(1) 1st partially filled and execution report sent then replace request
to reduce qty received (do not pass) or
(2) partial passes replace request.Most examples in Appendix D refer to in-flight handling only.