Imported from previous forum
[ original email was from Mark Hinman - mhinman@easetech.com ]
When OnBehalfOf transactions occur. Is SenderSubID a required field?
scenario 1:
SenderCompID (required)
SenderSubID (required if OnBehalfOfCompID)
OnBehalfOfCompID (required if OnBehalfOfSubID)
OnBehalfOfSubID (optional)
Scenario 2:
SenderCompID (required)
SenderSubID (optional)
SenderCompID (required)
OnBehalfOfCompID (required if OnBehalfOfSubID)
OnBehalfOfSubID (optional)
which scenario is correct or are both scenario possible?
Mark Hinman
Ease Technologies, Inc.
mhinman@easetech.com
(301) 854-0010
No, SenderSubID is not required even if OnBehalfOfCompID is being used. Same holds true with TargetSubID and use of DeliverToCompID.
The idea is that OnBehalfOf… and DeliverTo… can be used to identify the prinicipal’s (i.e. broker or institution) details when the FIX message is being passed via a FIX connection to a third-party (i.e. Bloomberg, Trinitech NYFIX, Tradeware FIXLink, Bridge EZ-FIX, AutEX, etc). The ability to use these fields eliminates the need to “overload” the SenderSubID and TargetSubID fields with some concatenated combination of this kind of information.
A secenario might be that brokerage firms BRKR1 and BRKR2 are communicating with institution ABC. BRKR1 and BRKR2 use Bloomberg as a third party network. Thus ABC establishes a FIX connection with Bloomberg’s FIX system which lets say has a CompID of BLP.
An IOI sent from BRKR1 might have the following:
SenderCompID: BLP
SenderSubID: (optional might be the name of a particular system)
OnBehalfOfCompID: BRKR1
OnBehalfOfSubID: (optional might be the name of a particular salestrader)
TargetCompID: ABC
TargetSubID: (optional might be the name of a particular targeted trader)
An Allocation sent from ABC to BRKR2 might have the following:
SenderCompID: ABC
SenderSubID: (optional might be the name of a trader)
TargetCompID: BLP
TargetSubID: (optional might be the name of a particular system)
DeliverToCompID: BRKR2
DeliverToSubID: (optional might be the name of a particular salestrader or backoffice person)
The above scenario could have an additional twist if ABC is communicating via a third-party network as well. In this case the Sender and Target CompID and SubIDs would represent the two third-party networks and the examples above would each have both OnBehalfOfCompID and DeliverToCompID specified representing the broker and institution involved.
Hope that helps.
> When OnBehalfOf transactions occur. Is SenderSubID a required field?
> scenario 1:
> SenderCompID (required)
> SenderSubID (required if OnBehalfOfCompID)
> OnBehalfOfCompID (required if OnBehalfOfSubID)
> OnBehalfOfSubID (optional)
>
> Scenario 2:
> SenderCompID (required)
> SenderSubID (optional)
>
> SenderCompID (required)
> OnBehalfOfCompID (required if OnBehalfOfSubID)
> OnBehalfOfSubID (optional)
>
>
> which scenario is correct or are both scenario possible?
>
> Mark Hinman
> Ease Technologies, Inc.
> mhinman@easetech.com
> (301) 854-0010
>
[ original email was from Koji Ishikawa - ishikawa@quick.co.jp ]
> The idea is that OnBehalfOf… and DeliverTo… can be used to identify the prinicipal’s (i.e. broker or institution) details when the FIX message is being passed via a FIX connection to a third-party (i.e. Bloomberg, Trinitech NYFIX, Tradeware FIXLink, Bridge EZ-FIX, AutEX, etc). The ability to use these fields eliminates the need to “overload” the SenderSubID and TargetSubID fields with some concatenated combination of this kind of information.
>
Assuming that FIX application messages would be
delivered between principals in multiple FIX
session via third-party, it seems that the
following scenario might arise.
Institution establishes own FIX session with
third-party, also broker establishes own FIX
session with third-party.
(i.e. Institution ABC <- FIX session 1 -> Third-
party ZZZ <- FIX session 2 -> Broker BRKR.)
Then, principals will start exchanging FIX
application messages via third-party
associated with the appropriate destination IDs.
As independent FIX sessions are laid between
institution and broker, it could be recognized
that FIX administrative messages are exchanged
not between principals but with third-party.
However Reject message could be exchanged
between principals for the business level
rejections.
In case of this scenario, how the destination
IDs are supposed to be used is shown below:
A New Order Single delivered to broker might be
as follows:
1)At first, sent from institution to third-party
through FIX session 1.
SenderCompID: ABC
TargetCompID: ZZZ
DeliverToCompID: BRKR
2)Then, sent forward from third-party to
broker through FIX session 2.
SenderCompID: ZZZ
TargetCompID: BRKR
OnBehalfOfCompID: ABC
An Execution Report delivered to institution
might be as follows:
1)At first, sent from broker to third-party
through FIX session 2.
SenderCompID: BRKR
TargetCompID: ZZZ
DeliverToCompID: ABC
2)Then, sent forward from third-party to
institution through FIX session 1.
SenderCompID: ZZZ
TargetCompID: ABC
OnBehalfOfCompID: BRKR
Is above scenario correct or possible ?
Thanks for your attention, any comment would be
appreciated.
Koji Ishikawa
QUICK Corp.
ishikawa@quick.co.jp
Your example is correct. The Reject message in the 4.1 spec is an Administrative vs. Business Message. There is not currently a generic business-level reject message, however, there are some specific business-level reject messages (OrderCancelReject, Order Reject via ExecutionRpt, Allocation Reject via AllocationAck, etc). Administrative messages (i.e. Heartbeats) are exchanged between FIX engines vs. principals and thus are not forwarded on from the institution to the principal in your example.
The Technical Committee has recognized that examples regarding the use of SenderCompID, TargetCompID, DeliverToCompID, and OnBehalfOfCompID are needed for clarity and plans to add the following to the "Message header" section:
The following provides examples regarding the use of SenderCompID, TargetCompID, DeliverToCompID, and OnBehalfOfCompID. Assumption (A=sellside, B and C=buyside, Q=third party):
a) Send "message a" from A to B via Q
- A sends to Q:
SenderCompID: A TargetCompID: Q
OnBehalfOfCompID: DeliverToCompID: B - Then Q will send to B:
SenderCompID: Q TargetCompID: B
OnBehalfOfCompID: A DeliverToCompID:
b) B responds to A via Q:
- B sends to Q:
SenderCompID: B TargetCompID: Q
OnBehalfOfCompID: DeliverToCompID: A - Then Q will send to A:
SenderCompID: Q TargetCompID: A
OnBehalfOfCompID: B DeliverToCompID:
c) You cannot have Q involved and send a message from A to B "directly". Without Q, sending A to B:
SenderCompID: A TargetCompID: B
OnBehalfOfCompID: DeliverToCompID:
d) You cannot have Q involved and send a message from B to A "directly". Without Q, sending B to A:
SenderCompID: B TargetCompID: A
OnBehalfOfCompID: DeliverToCompID:
e) Send from A to B AND C via Q
- A sends to Q:
SenderCompID: A TargetCompID: Q
OnBehalfOfCompID: DeliverToCompID: B - Then Q will send to B:
SenderCompID: Q TargetCompID: B
OnBehalfOfCompID: A DeliverToCompID: - A sends to Q:
SenderCompID: A TargetCompID: Q
OnBehalfOfCompID: DeliverToCompID: C - Then Q will send to C:
SenderCompID: Q TargetCompID: C
OnBehalfOfCompID: A DeliverToCompID:
e) B AND C send to A via Q
- B sends to Q:
SenderCompID: B TargetCompID: Q
OnBehalfOfCompID: DeliverToCompID: A - Then Q will send to A:
SenderCompID: Q TargetCompID: A
OnBehalfOfCompID: B DeliverToCompID: - C sends to Q:
SenderCompID: C TargetCompID: Q
OnBehalfOfCompID: DeliverToCompID: A - Then Q will send to A:
SenderCompID: Q TargetCompID: A
OnBehalfOfCompID: B DeliverToCompID:
Hopefully that will help you and others.
> > The idea is that OnBehalfOf… and DeliverTo… can be used to identify the prinicipal’s (i.e. broker or institution) details when the FIX message is being passed via a FIX connection to a third-party (i.e. Bloomberg, Trinitech NYFIX, Tradeware FIXLink, Bridge EZ-FIX, AutEX, etc). The ability to use these fields eliminates the need to “overload” the SenderSubID and TargetSubID fields with some concatenated combination of this kind of information.
> >
>
> Assuming that FIX application messages would be
> delivered between principals in multiple FIX
> session via third-party, it seems that the
> following scenario might arise.
>
> Institution establishes own FIX session with
> third-party, also broker establishes own FIX
> session with third-party.
> (i.e. Institution ABC <- FIX session 1 -> Third-
> party ZZZ <- FIX session 2 -> Broker BRKR.)
> Then, principals will start exchanging FIX
> application messages via third-party
> associated with the appropriate destination IDs.
>
> As independent FIX sessions are laid between
> institution and broker, it could be recognized
> that FIX administrative messages are exchanged
> not between principals but with third-party.
> However Reject message could be exchanged
> between principals for the business level
> rejections.
>
> In case of this scenario, how the destination
> IDs are supposed to be used is shown below:
>
> A New Order Single delivered to broker might be
> as follows:
> 1)At first, sent from institution to third-party
> through FIX session 1.
> SenderCompID: ABC
> TargetCompID: ZZZ
> DeliverToCompID: BRKR
> 2)Then, sent forward from third-party to
> broker through FIX session 2.
> SenderCompID: ZZZ
> TargetCompID: BRKR
> OnBehalfOfCompID: ABC
>
> An Execution Report delivered to institution
> might be as follows:
> 1)At first, sent from broker to third-party
> through FIX session 2.
> SenderCompID: BRKR
> TargetCompID: ZZZ
> DeliverToCompID: ABC
> 2)Then, sent forward from third-party to
> institution through FIX session 1.
> SenderCompID: ZZZ
> TargetCompID: ABC
> OnBehalfOfCompID: BRKR
>
> Is above scenario correct or possible ?
>
> Thanks for your attention, any comment would be
> appreciated.
>
> Koji Ishikawa
> QUICK Corp.
> ishikawa@quick.co.jp
>
>
Hello,
[…]
> The following provides examples regarding the use of SenderCompID, TargetCompID, DeliverToCompID, and OnBehalfOfCompID. Assumption (A=sellside, B and C=buyside, Q=third party):
> a) Send "message a" from A to B via Q
> 1) A sends to Q:
> SenderCompID: A TargetCompID: Q
> OnBehalfOfCompID: DeliverToCompID: B
> 2) Then Q will send to B:
> SenderCompID: Q TargetCompID: B
> OnBehalfOfCompID: A DeliverToCompID:
[…]
And what role have SubID and LocationID? Should they be considered as a part of address in exactly the same manner as CompID?
Using the exmple above, A establishes connection
with SenderCompID A and SenderSubID SUB_1.
Should A receive messages to A.SUB_2 or even without any SubID?
In other words, should trinity [CompID, SubID, LocationID] be considered as exact address of connecting point (like IP) or it depends on circumstances?
Best regards,
Yury
Yury Voronov mailto:yury@workmail.com[ original email was from , - ]
this fields could be same after routing is performed, so routing could be completely transparent to them.
> Hello,
>
> […]
> > The following provides examples regarding the use of SenderCompID, TargetCompID, DeliverToCompID, and OnBehalfOfCompID. Assumption (A=sellside, B and C=buyside, Q=third party):
> > a) Send "message a" from A to B via Q
> > 1) A sends to Q:
> > SenderCompID: A TargetCompID: Q
> > OnBehalfOfCompID: DeliverToCompID: B
> > 2) Then Q will send to B:
> > SenderCompID: Q TargetCompID: B
> > OnBehalfOfCompID: A DeliverToCompID:
> […]
>
> And what role have SubID and LocationID? Should they be considered as a part of address in exactly the same manner as CompID?
> Using the exmple above, A establishes connection
> with SenderCompID A and SenderSubID SUB_1.
> Should A receive messages to A.SUB_2 or even without any SubID?
> In other words, should trinity [CompID, SubID, LocationID] be considered as exact address of connecting point (like IP) or it depends on circumstances?
>
> Best regards,
> Yury
>
> Yury Voronov mailto:yury@workmail.com
>
>
>
Hi,
> this fields could be same after routing is performed, so routing could be completely transparent to them.
As for routing - yes. But regardless of routing the question is the same:
Should trinity [CompID, SubID, LocationID] be considered as exact address of connecting point (like IP) or it depends on circumstances?
Best regards,
Yury
Yury Voronov mailto:yury@workmail.comNo. FIX messages are exchanged between firms (CompID). SubID and LocationID are optional. They can be used to help identify the source (who sent it and from where) of a message. They can be used to help facilitate routing or directing a message within a firm. They are not really applicable on session-level messages. Their use and values are established via bi-lateral agreement between counterparties.
> Hi,
>
> > this fields could be same after routing is performed, so routing could be completely transparent to them.
>
> As for routing - yes. But regardless of routing the question is the same:
>
> Should trinity [CompID, SubID, LocationID] be considered as exact address of connecting point (like IP) or it depends on circumstances?
>
> Best regards,
> Yury
>
> Yury Voronov mailto:yury@workmail.com
>
>