[This message was posted by Hanno Klein of Deutsche Börse Systems <[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/b4c681da - PLEASE DO NOT REPLY BY MAIL.]
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.
