[This message was posted by Eric Gottesman of Jefferies Execution Services <[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/9aff6c3c - PLEASE DO NOT REPLY BY MAIL.]
Vasanth, As a real-world example of the last post, the New York Stock Exchange allows cancelling orders on a different FIX connection. The NYSE enforces(requests) order uniqueness as a combination of tag 11(ClOrdID) and 115(OnBehalfOfCompID). So if you send 115=XYZ 11=ABC 1234/03022009 down session 1, then you can cancel it on session 2 with 115=XYZ 41=ABC 1234/03022009. Order entry systems must prevent sending the same tag 115/11 combination to two different sessions with NYSE. This is not "standard" FIX and not common practice, but a well known feature of NYSE gateway. Best, Eric Gottesman [email protected] > Hi Vasanth, > > The ability to delete orders (submitted on FIX connection A) using FIX > connection B is likely to be more determined by the underlying setup of > the exchanges trading applications rather than the FIX sessions or FIX > engine configuration. > > So assuming the underlying exchange trading system allows the > participant to cancel orders 'on behalf' submitted by another > connection, the question becomes, how? > > You may be able to use a Party Role (Parties block) to denote your > role and therefore 'route' your cancellation instruction to the > correct order. > > Or, the underlying static setup of the trading system may group FIX > connections under master business entities that allow cancelations > across FIX connections that are children of the same master parent > business entity. > > cheers > > > First question: No, OnBehalfOf is only for routing purposes if there > > are techncal hops in between. You are looking for a business function > > to trade on behalf. This is covered by the party role of "Entering > > Firm/Unit/Trader" (connection B)as opposed to "Executing > > Firm/Unit/Trader" (connection A). This is valid if connection B does > > not login with the same identification. Otherwise you simply have two > > logins from the same business entity and only need to make sure that > > connection B is aware of the orders activities conducted over > > connection A, for example by receiving drop copies on an ongoing > > basis. Also take a look at the FIX concept of Application Sequencing > > introduced with FIX 5. 0 SP1. > > > > Second question: Yes, some exchanges do offer a download of one's own > > orderbook, e.g. through a OrderMassStatusRequest. The alternative is > > to provide a reliable broadcast with a recovery option to re-request > > any missed messages. The first option is easier for the user but more > > burden for the exchange if many such requests come in. Especially in > > the morning it might be more advisable to offer an unsolicited > > restatement of orders via ExecutionReports instead of servicing > > OrderMassStatusRequests from the users. It is a good practice to > > restrict the scope to the open orders only, i.e. not to include > > filled, cancelled or expired orders in the restatements. > > > > Regards, Hanno. > > > > > Relatively new to FIX. I have two basic questions: > > > > > > 1. If a firm has multiple connections to the exchange, one such > > > connections (say A) fails and subsequently another connection > > > (say B) from the same firm wants to cancel any open order > > > (assuming orders are not auto-cancelled upon FIX connection > > > failure) originated from the failed connection, how should this > > > be handled - use tag 115 onbehalfof? > > > > > > 2. Is it a common practice to allow connection B to use a Order Mass > > > Status Request to retrieve the open orders from the exchange > > > order book, to be able to look up to the open positions, probably > > > request for a cancellation as in question 1? > > > > > > Thanks Vasanth [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 -~----------~----~----~----~------~----~------~--~---
