[This message was posted by Greg Wood of Credit Suisse <[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/23024ef8 - PLEASE DO NOT REPLY BY MAIL.]
Hi Hanno and Mike, In response to Mike's original question I would suggest 39=A (PendingNew) is the preferred order status for a CancelReject when a new order has not been ack'd prior to a cancel or replace request being received. Similarly for a subsequent request on an order pending cancel or replace then 39=6 or 39=E would be appropriate. As to Hanno's point regarding why respond to the 2nd request before the first, sometimes the full sequence is not in our control. As a broker/dealer we rely on various downstream systems - such as exchanges - to provide the ack to a new order. There is obviously inherent latency that can be variable due to load or other conditions such as loss of connectivity, etc, and it is common to receive subsequent requests before the ack is returned to the client, especially for fast moving markets and high frequency traders. It has been a common debate whether receivers of FIX messages should chain requests or reject if a state is still pending transition. The easiest approach is to reject if still pending (39=A, 39=E, 39=6) simply because it keeps things cleaner. In practice, buffering requests and then applying them when transitions are ack'd can actually lead to bigger errors or strains on messaging infrastructure than forcing the sender to keep submitting their request until the receiver is ready to process it, simply because we reject further upstream before doing too much processing internally. The argument has been made whether this is right or wrong, especially whether you should still buffer cancel requests when rejecting replaces on pending orders, but it comes down to weighing up the pros and cons and making a decision on which practice to choose - chain or reject. Regards, - Greg > Why would you respond to the second request prior to the first one? You > could just queue the second one to process them in order. This seems to > be the simplest solution. > > If you want to immediately reject any requests on orders that have > not reached status NEW then you could use PENDING NEW to express > this. Alternatively, you can use OrdStatus=REJECTED, > CxlRejReason=1=Unknown Order. > > The latter does not allow the submitter to modify or cancel an order > before having received a confirmation which might be less desirable. > > The former creates a non-deterministic behavior because you accept or > reject a modification based on you having sent NEW, regardless whether > the submitter has also seen NEW or not. The submitter will therefore not > see a rejection in some cases even though he has not seen the > ExecutionReport with NEW yet. > > Regards, Hanno. > > > Hi, > > > > While a new order is not yet acknowledged (i.e. not yet replied with > > NEW execution report). There comes another FIX amendment/cancellation > > request on the same order. Just wonder what OrdStatus(31) value should > > be returned in OrderCancelReject message to reject the > > amendment/cancellation request. Is it appropriate to return NEW(0)? > > > > Thanks, > > > > Mike [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.
