[This message was posted by Aaron Pryce of [email protected] <[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/bfa42f2c - PLEASE DO NOT REPLY BY MAIL.]
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 -~----------~----~----~----~------~----~------~--~---
