Imported from previous forum
[ original email was from Marcondes Farias - mfarias@bmf.com.br ]
Hi there!
we really need some help in dealing with Trader Identification through FIX. Let me describe our scenarios:
SCENARIO 1) Simple Trader Identification
- A trader stablishes a FIX session with our Exchange
- The trader sends an New Order Single (D) message.
- Our system must identify who is the trader (Trader Identification - “JOHN_DOE001”) that send the message, for business purposes (authorization, what are the limits for this trader, what kind of securities is he able to trade etc) NOT, a repeat, NOT the origination station or session level identification (SenderCompID - “MACHINE01”).
SCENARIO 2) A Trader sending an order on "business " behaulf of another trader.
- The market supervision is contacted by a trader by phone, asking for an order to be put on the market.
- The market supervision sends a New Order Single (D) to the trading engine, there the trader identification (see scenario above) must the the supervision one (let´s say, “SUPERVISOR01”), and indicating that this order was send on “business” behaulf of another trader (“JOHN_DOE001”).
We did not find an “straight” way to do this through FIX. Opinions vary from using SenderSubID to using Parties component block, but no “winner” choice has been elected. Could some one gives us some guideline here please?
We really appreciate the help
[ original email was from Francesc Prats - fprats@meff.com ]
1) For the trader identification: We use, in MEFF, the tag 50 (SenderSubID) to identify who the trader is (in the messages sent from the client application to the Exchange). Another possibility could be the use of the Parties Block (PartyRole = 11 and/or 13).
- Market Supervisor: We use the Parties Block to identify the supervisor (PartyRole = 1 and/or 12). To identify the firm/trader acted on behalf (JOHN_DOE001 in your example) you can also use the same Parties explained in the previous scenario (PartyRole = 11 and/or 13).
Hope this helps…
Hi there!
we really need some help in dealing with Trader Identification through
FIX. Let me describe our scenarios:SCENARIO 1) Simple Trader Identification
- A trader stablishes a FIX session with our Exchange
- The trader sends an New Order Single (D) message.
- Our system must identify who is the trader (Trader Identification -
“JOHN_DOE001”) that send the message, for business purposes
(authorization, what are the limits for this trader, what kind of
securities is he able to trade etc) NOT, a repeat, NOT the
origination station or session level identification (SenderCompID -
“MACHINE01”).SCENARIO 2) A Trader sending an order on "business " behaulf of
another trader.
- The market supervision is contacted by a trader by phone, asking for
an order to be put on the market.- The market supervision sends a New Order Single (D) to the trading
engine, there the trader identification (see scenario above) must the
the supervision one (let´s say, “SUPERVISOR01”), and indicating that
this order was send on “business” behaulf of another trader
(“JOHN_DOE001”).We did not find an “straight” way to do this through FIX. Opinions vary
from using SenderSubID to using Parties component block, but no
“winner” choice has been elected. Could some one gives us some
guideline here please?We really appreciate the help
[ original email was from Dennis Wiatzka - dennis.wiatzka@omxgroup.com ]
> Hi there!
we really need some help in dealing with Trader Identification through
FIX. Let me describe our scenarios:SCENARIO 1) Simple Trader Identification
- A trader stablishes a FIX session with our Exchange
- The trader sends an New Order Single (D) message.
- Our system must identify who is the trader (Trader Identification -
“JOHN_DOE001”) that send the message, for business purposes
(authorization, what are the limits for this trader, what kind of
securities is he able to trade etc) NOT, a repeat, NOT the
origination station or session level identification (SenderCompID -
“MACHINE01”).SCENARIO 2) A Trader sending an order on "business " behaulf of
another trader.
- The market supervision is contacted by a trader by phone, asking for
an order to be put on the market.- The market supervision sends a New Order Single (D) to the trading
engine, there the trader identification (see scenario above) must the
the supervision one (let´s say, “SUPERVISOR01”), and indicating that
this order was send on “business” behaulf of another trader
(“JOHN_DOE001”).We did not find an “straight” way to do this through FIX. Opinions vary
from using SenderSubID to using Parties component block, but no
“winner” choice has been elected. Could some one gives us some
guideline here please?We really appreciate the help
We never determined a protocol specific solution to this problem. Instead we dealt with it ad hoc.
For our Horizon trading system implementations around the world we use the SenderSubId for trader codes.
We used OnBehalfOf for our first FIX interface implementation but then we discovered that the remote order management systems (OMS) are always taking care of validating the “trade as” so we never actually need the OnBehalfOf information.
Instead the OMS validates and tracks the “trade as” and then sends the order with the SenderSub populated with the trader Id of the trader who owns the order, not the trader who submitted it. When the trading system issues the execution report, the OMS takes care of sending the execution report back to the trader who submitted it.
It is likely that the OMS uses the OnBehalfOf fields internally.
[ original email was from Rikard Hedberg - rikard.hedberg@omxgroup.com ]
This is certainly an area where best practices would be welcome. I hope the Exchanges / ECN’s WG will be able to contribute.
Obviously many implementations would use the SubID tags to identify an individual (even if sessíons are on the CompID level). At the same time the Parties block can also host such data. With the introduction of the Parties component block, it has become possible to use the Standard Header for routing purposes only and the Parties block for business level related actors. But where is the dividing line? Do you authenticate actors (probably a session level activity, use the SubID) or only check their privileges in the business layer (use the Parties block)? But what if you need to do both?
And just to complicate thing even more, I have a third scenario:
- A supervisor at the broker firm updates an order that is owned by a broker and sends the transaction to the marketplace via a service provider. You could use:
- SenderSubID = the supervisor
- OnBehalfOfXXX = the service provider session
- Parties block / Party Role = 12 (Executing Trader) = the “owner” broker
Sorry I did not have the silver bullet answer, yet…
Rikard
Hi there!
we really need some help in dealing with Trader Identification through
FIX. Let me describe our scenarios:SCENARIO 1) Simple Trader Identification
- A trader stablishes a FIX session with our Exchange
- The trader sends an New Order Single (D) message.
- Our system must identify who is the trader (Trader Identification -
“JOHN_DOE001”) that send the message, for business purposes
(authorization, what are the limits for this trader, what kind of
securities is he able to trade etc) NOT, a repeat, NOT the
origination station or session level identification (SenderCompID -
“MACHINE01”).SCENARIO 2) A Trader sending an order on "business " behaulf of
another trader.
- The market supervision is contacted by a trader by phone, asking for
an order to be put on the market.- The market supervision sends a New Order Single (D) to the trading
engine, there the trader identification (see scenario above) must the
the supervision one (let´s say, “SUPERVISOR01”), and indicating that
this order was send on “business” behaulf of another trader
(“JOHN_DOE001”).We did not find an “straight” way to do this through FIX. Opinions vary
from using SenderSubID to using Parties component block, but no
“winner” choice has been elected. Could some one gives us some
guideline here please?We really appreciate the help
[ original email was from Matt Simpson - msimpson@cme.com ]
I think we’re headed toward a solution that says SenderCompID and SenderSubID should be used to identify and validate a particular session or thread of a session. They provide the routing ‘key’ for message exchange. Business context, such as Executing TraderID, should be carried in the Parties block.
I can envision a scenario where a trader is capable of using multiple operators (SenderSubID) across multiple sessions (SenderCompID) and therefore would need to be identified at a separate level using the Parties block.
In the end, this type of approach provides greater flexibility and avoids mixing the routing-level and business-level concepts together.
This is certainly an area where best practices would be welcome. I hope
the Exchanges / ECN’s WG will be able to contribute.Obviously many implementations would use the SubID tags to identify an
individual (even if sessíons are on the CompID level). At the same time
the Parties block can also host such data. With the introduction of the
Parties component block, it has become possible to use the Standard
Header for routing purposes only and the Parties block for business
level related actors. But where is the dividing line? Do you
authenticate actors (probably a session level activity, use the SubID)
or only check their privileges in the business layer (use the Parties
block)? But what if you need to do both?And just to complicate thing even more, I have a third scenario:
- A supervisor at the broker firm updates an order that is owned by a
broker and sends the transaction to the marketplace via a service
provider. You could use:
- SenderSubID = the supervisor
- OnBehalfOfXXX = the service provider session
- Parties block / Party Role = 12 (Executing Trader) = the
“owner” brokerSorry I did not have the silver bullet answer, yet…
Hi there!
we really need some help in dealing with Trader Identification through
FIX. Let me describe our scenarios:SCENARIO 1) Simple Trader Identification
- A trader stablishes a FIX session with our Exchange
- The trader sends an New Order Single (D) message.
- Our system must identify who is the trader (Trader Identification -
“JOHN_DOE001”) that send the message, for business purposes
(authorization, what are the limits for this trader, what kind of
securities is he able to trade etc) NOT, a repeat, NOT the
origination station or session level identification (SenderCompID -
“MACHINE01”).SCENARIO 2) A Trader sending an order on "business " behaulf of
another trader.
- The market supervision is contacted by a trader by phone, asking
for an order to be put on the market.- The market supervision sends a New Order Single (D) to the trading
engine, there the trader identification (see scenario above) must
the the supervision one (let´s say, “SUPERVISOR01”), and indicating
that this order was send on “business” behaulf of another trader
(“JOHN_DOE001”).We did not find an “straight” way to do this through FIX. Opinions
vary from using SenderSubID to using Parties component block, but no
“winner” choice has been elected. Could some one gives us some
guideline here please?We really appreciate the help
[ original email was from Marcondes Farias - mfarias@bmf.com.br ]
Thank you guys, looking throughout the ECN/Exchange Working Group Harmonization documento proposal we see this same kind of discussion and the proposed solution based upon the scenario you described Matt. Thank you for the support. We will implement our solution this way.
Marcondes
I think we’re headed toward a solution that says SenderCompID and
SenderSubID should be used to identify and validate a particular session
or thread of a session. They provide the routing ‘key’ for message
exchange. Business context, such as Executing TraderID, should be
carried in the Parties block.I can envision a scenario where a trader is capable of using multiple
operators (SenderSubID) across multiple sessions (SenderCompID) and
therefore would need to be identified at a separate level using the
Parties block.In the end, this type of approach provides greater flexibility and
avoids mixing the routing-level and business-level concepts together.This is certainly an area where best practices would be welcome. I
hope the Exchanges / ECN’s WG will be able to contribute.Obviously many implementations would use the SubID tags to identify an
individual (even if sessíons are on the CompID level). At the same
time the Parties block can also host such data. With the introduction
of the Parties component block, it has become possible to use the
Standard Header for routing purposes only and the Parties block for
business level related actors. But where is the dividing line? Do you
authenticate actors (probably a session level activity, use the SubID)
or only check their privileges in the business layer (use the Parties
block)? But what if you need to do both?And just to complicate thing even more, I have a third scenario:
- A supervisor at the broker firm updates an order that is owned by a
broker and sends the transaction to the marketplace via a service
provider. You could use:
- SenderSubID = the supervisor
- OnBehalfOfXXX = the service provider session
- Parties block / Party Role = 12 (Executing Trader) = the “owner”
brokerSorry I did not have the silver bullet answer, yet…
Hi there!
we really need some help in dealing with Trader Identification
through FIX. Let me describe our scenarios:SCENARIO 1) Simple Trader Identification
- A trader stablishes a FIX session with our Exchange
- The trader sends an New Order Single (D) message.
- Our system must identify who is the trader (Trader Identification
- “JOHN_DOE001”) that send the message, for business purposes
(authorization, what are the limits for this trader, what kind of
securities is he able to trade etc) NOT, a repeat, NOT the
origination station or session level identification (SenderCompID- “MACHINE01”).
SCENARIO 2) A Trader sending an order on "business " behaulf of
another trader.
- The market supervision is contacted by a trader by phone, asking
for an order to be put on the market.- The market supervision sends a New Order Single (D) to the
trading engine, there the trader identification (see scenario
above) must the the supervision one (let´s say, “SUPERVISOR01”),
and indicating that this order was send on “business” behaulf of
another trader (“JOHN_DOE001”).We did not find an “straight” way to do this through FIX. Opinions
vary from using SenderSubID to using Parties component block, but no
“winner” choice has been elected. Could some one gives us some
guideline here please?We really appreciate the help