Imported from previous forum
I’m implementing automatic testing suites for our FIX solution and have questions regarding the FIX 4.2 scenarios D11 and D12 (C3b,C3c in FIX 4.4).
D11 - why isn’t a pending replace sent out? The sales person should still have the possibility to reject the request, or? For me it makes no sense that the order is automatically replaced just beacuse cum qty and requested OrderQty is the same.
D12 - To me this one should me automatically rejected (not accepted!). The client asks for OrderQty of 7000 which is impossible to give because the cum qty is higher (8000). I could probably accept sending a pending replace and then rejecting it.
Another note, scenario D8 makes it possible to increase the OrderQty of a filled order. This is very useful for some of our clients. However, it poses a new question. When is the order “dead”? For how long should the client be allowed to modify up the OrderQty? Up to Expiry of the order? If we allow that, shouldn’t we send a ExecutionReport with OrdStatus=“Expired” when it expires? Sending “expired” for a “filled” order sounds wrong… but how should the client otherwise know that the order is “really dead”?
Philippe Ramkvist-Henry
Front Capital Systems
SunGard Trading Systems
[ original email was from Michael Katkin - michael.katkin@transacttools.net ]
Philippe,
The scenario in D11 lacks a pending replace because the change request can be immediately accepted by your trading system. The pending replace is not omitted because of the nature of the change request. The underlying goal of this scenario is to speed up the request processing by omitting the superfluous pending replace message.
The scenario in D12 shows how you can honor the client’s request even if completely fulfilling it is impossible. The spec suggests that you cancel the remaining leaves in the order in this case. If you were to reject it, then the client could be filled the remaining 2,000 shares before he could send another request. From the client’s perspective, this may seem unfair because he/she wanted to change the order before they received the first fill.
For your questions regarding D8. Some of our customers indicate that an order is dead by sending a Done for Day message. Unfortunately, at least one sellside we know of will continue sending execution corrections and busts after having sent a done for day message. In my opinion, an order is not really dead until it has settled, because until then, it may be allocated, busted, or corrected. Conveying settlement information to clients is beyond the scope of the FIX 4.2 specification.
I’m implementing automatic testing suites for our FIX solution and
have questions regarding the FIX 4.2 scenarios D11 and D12 (C3b,C3c
in FIX 4.4).D11 - why isn’t a pending replace sent out? The sales person should
still have the possibility to reject the request, or? For me it makes no
sense that the order is automatically replaced just beacuse cum qty and
requested OrderQty is the same.D12 - To me this one should me automatically rejected (not accepted!).
The client asks for OrderQty of 7000 which is impossible to give because
the cum qty is higher (8000). I could probably accept sending a pending
replace and then rejecting it.Another note, scenario D8 makes it possible to increase the OrderQty of
a filled order. This is very useful for some of our clients. However, it
poses a new question. When is the order “dead”? For how long should the
client be allowed to modify up the OrderQty? Up to Expiry of the order?
If we allow that, shouldn’t we send a ExecutionReport with
OrdStatus=“Expired” when it expires? Sending “expired” for a “filled”
order sounds wrong… but how should the client otherwise know that the
order is “really dead”?Philippe Ramkvist-Henry Front Capital Systems SunGard Trading Systems
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
For the most part, I agree with what was said.
The D11 and D12 cases are ones where the user’s change request essentially becomes a cancel because the requested new OrderQty is <= the CumQty.
FIX doesn’t really dictate business practice. In both of these scenarios, should a firm decide to reject the change, I would consider the firm FIX compliant. However, doing so isn’t an optimal business practice because it exposes the order to unwanted execution more than is necessary.
While D11 lacks a pending replace, I interpret that as meaning the pending replace is unnecessary if the change can be accepted immediately, but I see no problem in sending a pending replace if the change cannot be accepted immediately. For example, if the broker has some or all of the order live at an exchange or ECN, the broker might simultaneously send a cancel to the ECN/exchange and a pending replace to the client to acknowledge that the change was received. Once the ECN/exchange gives an out, the broker then sends a replaced message to the client.
D8 is another example of FIX allowing but not mandating a business practice. It is possible in FIX for the buy-side to take a filled order, change it to make it live again, and have the sell-side continue working it. It is my understanding that this is more likely when humans are working the order and communicating by telephone; a broker might indicate that more shares are available, the buy-side might re-open that ticket, and the order would retain the same ticket ID. But in systems where orders are executed electronically, this isn’t anywhere near as common. In these systems, once an order is filled the buy-side usually can’t change it; their only option is to enter a new order. So even though the spec allows changing a filled order, I’d guess that the majority of FIX systems don’t implement it and would reject the attempt.
Thank you for your very quick an informative answers!
The reason that I’m focused on the “pending” messages is that the system I’m integrating with is an “Institutional Sales” system. In this case it means that there will be a actual person that accepts/rejects requests. Since there might take time for the salesperson to do this I would like to always (when possible) send pending messages back.
I understand your comments on case D11/D12. The buy side’s intentions are fulfilled to the extent it’s possible. I respect that. But as a programmer I’ve worked with other protocols alot (mostly exchange integrations) and my gut feeling tells me that it’s wrong to accept a request that is sent based on “old data”. This is especially obvious in D12. If buy side had known about the partial fill there would be no reason for sending a request that doesn’t match the latest data. Beacuse the protocol does not have a “timestamp” on the order it’s impossible for the sell side to know if buy side is acting on the latest data. But in the case of D12 is quite obvious that it isn’t.
My implementation will probably reject D12 and send pending on D11. The future will tell if buy side can handle this.
Thanks for all the help. I’ll be back with IOI and Allocation questions soon…
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> The reason that I’m focused on the “pending” messages is that the system
I’m integrating with is an “Institutional Sales” system. In this case it
means that there will be a actual person that accepts/rejects requests.
Since there might take time for the salesperson to do this I would like
to always (when possible) send pending messages back.
This sounds like an ideal use of the Pending messages. The customer needs to know immediately that the change has been seen. It’s not a guarantee that the change will be accepted; if that sales trader has already filled the customer’s order, the customer is too late to change it.
I understand your comments on case D11/D12. The buy side’s intentions
are fulfilled to the extent it’s possible. I respect that. But as a
programmer I’ve worked with other protocols alot (mostly exchange
integrations) and my gut feeling tells me that it’s wrong to accept a
request that is sent based on “old data”. This is especially obvious in
D12. If buy side had known about the partial fill there would be no
reason for sending a request that doesn’t match the latest data. Beacuse
the protocol does not have a “timestamp” on the order it’s impossible
for the sell side to know if buy side is acting on the latest data. But
in the case of D12 is quite obvious that it isn’t.
I can understand that point. Obviously the client is acting on old data. In a zero latency world, the client would send a cancel, not a change that reduces the OrderQty to <= the CumQty.
However, I do feel from a business standpoint that any instruction to reduce quantity can reasonably be interpreted as an instruction to attempt to cancel the order if the reduced quantity is less than or equal to the traded quantity. If I want to buy 1000 shares and later change my mind, and I tell my broker that I only want 500 shares, but 600 have at that instant traded, I want out of that order now. I don’t want to be told that the change is rejected and risk the rest of the order trading before I can send in a cancel.
My implementation will probably reject D12 and send pending on D11. The
future will tell if buy side can handle this.
The FIX spec isn’t trying to force you to accept those change messages. From a purely technical standpoint, I don’t see why the buy-side should have a problem with them should you reject them. Now, whether the buy-side would be happy from a business standpoint is another matter outside the scope of the FIX protocol.
Also, I’d like to warn that the D11 and D12 cases can be problematic for the buy-side. They are receiving a Replaced message, which normally indicates that the order is still live, but in this case it indicates the order is now completed. In some error situations, the buy-side might still think the order is live after D11 or D12. These are scenarios I would suggest that trading partners add to their integration tests.
In a zero latency world, the client would send a cancel, not a change
that reduces the OrderQty to <= the CumQty.However, I do feel from a business standpoint that any instruction to
reduce quantity can reasonably be interpreted as an instruction to
attempt to cancel the order if the reduced quantity is less than or
equal to the traded quantity. If I want to buy 1000 shares and later
change my mind, and I tell my broker that I only want 500 shares, but
600 have at that instant traded, I want out of that order now. I don’t
want to be told that the change is rejected and risk the rest of the
order trading before I can send in a cancel.My implementation will probably reject D12 and send pending on D11.
The future will tell if buy side can handle this.
====================================================================
Does this mean that various FIX implementations of Modify Order could be different? Is this TRUE?
WRT the example above, EchangeA might reject the modify request, and ExchangeB might “interpret” the modify request and cancel the original order.
Which method is more common?
[ original email was from Kevin English - kevin.english@citigroup.com ]
> D11 - why isn’t a pending replace sent out? The sales person should
still have the possibility to reject the request, or? For me it makes no
sense that the order is automatically replaced just beacuse cum qty and
requested OrderQty is the same.
a. The protocol does not require that ‘Pending’ messages are
sent in response to incoming order requests. These are optional
messages. There is nothing in this scenario that dictates a
‘pending replace’ could not be sent.
Additionally, buy-side companies often ask that they are not sent
especially if bandwidth is at a premium.
I believe that the ‘pending messages’ shown in the scenarios
are to help with demonstrating the precedance rules that
govern the ExecType and OrdStatus attributes.
b. The buy-side wishes to amend the order qty from 10000 to 7000;
At the same time the sell-side executes 7000 leaving a remainder
3000;
Imagine if the sell-side were to reject the cancel-replace
request, and then were to execute the remainder of the order
before the buy-side had came back in with a cancel request …
c. There is nothing in the scenarios that indicate that sell-side or
buy-side messages are generated automatically or manually. Either
is fine.
D12 - To me this one should me automatically rejected (not accepted!).
The client asks for OrderQty of 7000 which is impossible to give because
the cum qty is higher (8000). I could probably accept sending a pending
replace and then rejecting it.
a. again we know the buy-side wishes to reduce order qty i.e. decrease
market exposure - if sell-side rejects the request, there
is a chance the order will be filled even further. If sell-side
were to reject (with or without a pending message) the buy-side
would be entitle to be aggrieved.
Another note, scenario D8 makes it possible to increase the OrderQty of
a filled order. This is very useful for some of our clients. However, it
poses a new question. When is the order “dead”? For how long should the
client be allowed to modify up the OrderQty? Up to Expiry of the order?
If we allow that, shouldn’t we send a ExecutionReport with
OrdStatus=“Expired” when it expires? Sending “expired” for a “filled”
order sounds wrong… but how should the client otherwise know that the
order is “really dead”?
a. This is a very good question and should defintiely be addressed
in the Rules of Engagement drawn up between the buy-side and the sell-side. I believe the buy-side should be able to amend (qty up or down
etc) or cancel an order while the Order is not ‘Expired’ or ‘Cancelled’.
In FIX 4.2 ‘Expired’ is given the same precedance as ‘Cancelled’.
We know that cancelled orders cannot be amended therefore I believe this
is an attempt by the Protcol to impose the same rules on ‘Expired’ orders.
b. With regards to your last point, when sending an ExecutionReport indicating expiry (in FIX 4.2) TWO attributes work in tandem to convey the message - execType=‘Expired’ but the OrdStatus=‘Filled’; ‘Filled’
has a higher precedance.
Excerpt from 4.2 documentation
"Each execution report contains three fields which are used to communicate both the current state of the order as understood by the broker and the purpose of the message: OrdStatus, ExecType and ExecTransType.
In an execution report the OrdStatus is used to convey the current state of the order. If an order simultaneously exists in more than one order state, the value with highest precedence is the value that is reported in the OrdStatus field. The order statuses are as follows (in highest to lowest precedence): …
The ExecType is used to identify the purpose of the execution report message. "
The last sentence is key.
hope this helps,
Kevin