[This message was posted by Dave Law of Susquehanna <[email protected]> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/daab6514 - PLEASE DO NOT REPLY BY MAIL.]
Hi there The OrigClOrdID<41> sent by the client should match the ClOrdID<11> of the last accepted amend, or in the case of an order that has not been amended, the ClOrdID<11> of the original order. This requirement presents a dilemma for the client when they do not wait for acknowledgments. Let's imagine a scenario whereby the broker and client process messages on a single thread and in strictly first in first out queuing (and borrowing your notation): This is the obvious base case, which presents no issues, as the client waits for an amend ack: -> Order X <- Ack X -> Amend Y,X <- Ack Y -> Amend Z,Y <- Ack Z Now if the client doesn't wait for an amend ack: -> Order X -> Amend Y,X -> Amend Z,Y If the broker processes the messages in order, and both the order and first amend are accepted, the second amend should also be accepted. However, there is a school of thought that suggests the client should really be sending Z,X for the second amend, as the first one has not yet been accepted, and OrigClOrdID<41> should match 'the last accepted amend, or new order if no amends accepted'. Personally, I would ignore the strict protocol definition and use Z,Y - especially if the following two things are true: 1. I can confirm that the broker will process the amends on a single thread, in order of arrival. 2. I have a good chance that the previous amend Y will be accepted (for example, the order originates from a strategy that doesn't send more than a few ticks away from best bid/offer). All I'm doing in this scenario is preempting what the correct OrigClOrdID will be at the time of *processing*, even if at the time of *sending* it is wrong. As per point 2 though - it really does hang on amend Y,X being accepted. If it is rejected, then Z,Y will also be rejected, as the broker will expect Z,X. > I am aware of the fact that your scenario is not shown 100% in the > scenarios. I was suggesting to abstract from that a little bit to see > the concepts behind the details. It is impossible to spell out every > possible scenario. > > I see no reason to allow a second Cancel/Replace w/o Ack of the first > one but to not allow Cancel/Replace w/o an Ack of the New. > > So my answer is still yes, it is allowed. The only way to prevent it is > to disallow ClOrdID and to mandate OrderID as a way to reference an > order. Then you have no chance to modify the order because you do not > know how to reference it prior to getting an Ack. Some exchanges have > done so in the past or are still doing so. FIX is more flexible here and > allows you to delete an order a nanosecond after you have sent off the > request to enter it. If the entry is rejected you will get an "order not > found" or sth similar so that is why your application needs to be > prepared for various responses. > > > Yes, sure, but > > > > is sending replace requests prior to receiving ack on NewOrder > > allowed by FIX? > > > > D describes only cases when replace requests are sent after ack on > > NewOrder had been received. > > > > > Have a look at D.2.a where two replace requests come after one > > > another. They are both successful and the broker processes one after > > > the other. > > > > > > Sending requests prior to receiving an answer is definitely allowed > > > in FIX. ClOrdID is the key field allowing you to do that. > > > > > > The client just has to be prepared for the type of response he will > > > get from the broker. The responses will differ if rejects or fills > > > are involved. > > > > > > Does that answer your question? > > > > > > > Thanks for your answer. > > > > > > > > I looked through the Vol4, scenarious C,D, however they didn't > > > > match my scenario. C, D describe the situation when a client has > > > > received Execution- New(X) before he sends Replace. I'd say that > > > > cases B.1.d and B.1.e are close to me case except CancelRequest > > > > should be replaced with one or several Replace requests. Such > > > > cases are not described in FIX specs and therefore I wonder if > > > > they are allowed by the spec and what are broker's responses. > > > > > > > > > The broker will not wait to see if further requests come in and > > > > > process each request as it comes. Unless there are rejections or > > > > > fills in between, the immediacy of Cancel/Replace requests > > > > > should not matter. However, if the first Cancel/Replace request > > > > > is rejected, then Y does not become a valid ClOrdID. Equally, if > > > > > 1000 are filled prior to the first Cancel/Replace request (or > > > > > 900 prior to the second), then the qty cannot be reduced to the > > > > > desired value. > > > > > > > > > > Have a look at the spec Volume 4, message scenarios C and D, > > > > > starting on page 52, specifically D.2 starting on page 61. Hope > > > > > you find enough answers there. Details can get quite complex. > > > > > > > > > > > Hi, > > > > > > > > > > > > FIX4.4 I've got the following use case: > > > > > > > > > > > > client: NewOrder(X), qty=1000 client: > > > > > > OrderCancelReplaceRequest(Y,X), qty=900 client: > > > > > > OrderCancelReplaceRequest(Z,Y), qty=800 broker: ?????? > > > > > > > > > > > > Q1: does client send the correct chain of requests? > > > > > > Q2: if Q1 is "yes" then what are the possible responses from > > > > > > the server? > > > > > > > > > > > > Thanks in advance. [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
