Imported from previous forum
[ original email was from Vasanth Acharya - vasanth@hkstar.com ]
Relatively new to FIX. I have two basic questions:
-
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?
-
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
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:
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?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
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:
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?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
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
eric_gottesman@hotmail.com
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:
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?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