Uniquely identify trade origin

, ,
1

Imported from previous forum

2

Hi All

Please note that this question primarily relates to FIX 4.0.

I have a question that relates to identifying where a trade originated when receiving it over a network (series of FIX nodes).

Let’s say we have entities O, H and D, where the message originates at O and is sent to D via H, and the order is destined for X

Assume that in such a case we have that

SenderCompID=H
OnbehalfOfCompID=O
TargetCompID=D.
DeliverToCompID=X

Let us further assume that H starts sending orders through another FIX node N.

Am I right to assume that the field content for a message arriving at D will be

SenderCompID=H
OnbehalfOfCompID=N
TargetCompID=D.
DeliverToCompID=X

In other words we have lost the knowledge at node D that the actual origin of the order was O. Assume further, that the actual client/broker relationship is between D (that will then route the order further), and X. The account field will thus contain the account information of the account of D at X. There is thus in this scenario no obvious way to retain (at D) that the order originated at O.

I have two questions:

What is the ‘best practice’, using FIX 4.0, to retain this information.
Are there better ways to do this un later versions of FIX?

Thanx
Herman

3

re: "Are there better ways to do this in later versions of FIX?" (than FIX 4.0)

Yes, FIX 4.3 introduced NoHops and repeating group of HopCompID, HopSendingTime, and HopRefID in the Standard Header.

> Hi All
>
> Please note that this question primarily relates to FIX 4.0.
>
> I have a question that relates to identifying where a trade originated when receiving it over a network (series of FIX nodes).
>
> Let’s say we have entities O, H and D, where the message originates at O and is sent to D via H, and the order is destined for X
>
> Assume that in such a case we have that
>
> SenderCompID=H
> OnbehalfOfCompID=O
> TargetCompID=D.
> DeliverToCompID=X
>
> Let us further assume that H starts sending orders through another FIX node N.
>
> Am I right to assume that the field content for a message arriving at D will be
>
> SenderCompID=H
> OnbehalfOfCompID=N
> TargetCompID=D.
> DeliverToCompID=X
>
>
> In other words we have lost the knowledge at node D that the actual origin of the order was O. Assume further, that the actual client/broker relationship is between D (that will then route the order further), and X. The account field will thus contain the account information of the account of D at X. There is thus in this scenario no obvious way to retain (at D) that the order originated at O.
>
> I have two questions:
>
> What is the ‘best practice’, using FIX 4.0, to retain this information.
> Are there better ways to do this un later versions of FIX?
>
> Thanx
> Herman
>
>
>

4

Hi

Thanx for the response.

Is there any solution to this problem using FIX 4.0?

Thanx
Herman

> re: “Are there better ways to do this in later versions of FIX?” (than FIX 4.0)
>
> Yes, FIX 4.3 introduced NoHops and repeating group of HopCompID, HopSendingTime, and HopRefID in the Standard Header.
>
>
>
> > Hi All
> >
> > Please note that this question primarily relates to FIX 4.0.
> >
> > I have a question that relates to identifying where a trade originated when receiving it over a network (series of FIX nodes).
> >
> > Let’s say we have entities O, H and D, where the message originates at O and is sent to D via H, and the order is destined for X
> >
> > Assume that in such a case we have that
> >
> > SenderCompID=H
> > OnbehalfOfCompID=O
> > TargetCompID=D.
> > DeliverToCompID=X
> >
> > Let us further assume that H starts sending orders through another FIX node N.
> >
> > Am I right to assume that the field content for a message arriving at D will be
> >
> > SenderCompID=H
> > OnbehalfOfCompID=N
> > TargetCompID=D.
> > DeliverToCompID=X
> >
> >
> > In other words we have lost the knowledge at node D that the actual origin of the order was O. Assume further, that the actual client/broker relationship is between D (that will then route the order further), and X. The account field will thus contain the account information of the account of D at X. There is thus in this scenario no obvious way to retain (at D) that the order originated at O.
> >
> > I have two questions:
> >
> > What is the ‘best practice’, using FIX 4.0, to retain this information.
> > Are there better ways to do this un later versions of FIX?
> >
> > Thanx
> > Herman
> >
> >
> >
>

5

If you can’t distinctly use existing fields such as ClientID or Account, then you probably need to consider using one or more User Defined fields.

> Hi
>
> Thanx for the response.
>
> Is there any solution to this problem using FIX 4.0?
>
> Thanx
> Herman
>
> > re: “Are there better ways to do this in later versions of FIX?” (than FIX 4.0)
> >
> > Yes, FIX 4.3 introduced NoHops and repeating group of HopCompID, HopSendingTime, and HopRefID in the Standard Header.
> >
> >
> >
> > > Hi All
> > >
> > > Please note that this question primarily relates to FIX 4.0.
> > >
> > > I have a question that relates to identifying where a trade originated when receiving it over a network (series of FIX nodes).
> > >
> > > Let’s say we have entities O, H and D, where the message originates at O and is sent to D via H, and the order is destined for X
> > >
> > > Assume that in such a case we have that
> > >
> > > SenderCompID=H
> > > OnbehalfOfCompID=O
> > > TargetCompID=D.
> > > DeliverToCompID=X
> > >
> > > Let us further assume that H starts sending orders through another FIX node N.
> > >
> > > Am I right to assume that the field content for a message arriving at D will be
> > >
> > > SenderCompID=H
> > > OnbehalfOfCompID=N
> > > TargetCompID=D.
> > > DeliverToCompID=X
> > >
> > >
> > > In other words we have lost the knowledge at node D that the actual origin of the order was O. Assume further, that the actual client/broker relationship is between D (that will then route the order further), and X. The account field will thus contain the account information of the account of D at X. There is thus in this scenario no obvious way to retain (at D) that the order originated at O.
> > >
> > > I have two questions:
> > >
> > > What is the ‘best practice’, using FIX 4.0, to retain this information.
> > > Are there better ways to do this un later versions of FIX?
> > >
> > > Thanx
> > > Herman
> > >
> > >
> > >
> >
>

6

Herman,

What you wrote is not how I would inturrpret how the fields would change.

The OnBehalfOfCompID in all the hops would remain the same, for all the hops. The information lost would not be the original sender, but the Nodes that it took to get there.

Consider H on network N, wanting to send orders on X on network D. Via FIX hub O.

The header starts as:
SenderCompID=H
OnbehalfOfCompID=N
TargetCompID=O
DeliverToCompID=X

From H and N’s perspective, X is on Network O. Only O knows that it needs to forward it to Network D.

The message arrives to D with with the header:

SenderCompID=H
OnbehalfOfCompID=O
TargetCompID=D
DeliverToCompID=X

Likewise D think’s H is on O’s network. Only O know that it actually came from N.

Cheers,
Rob

> Hi All
>
> Please note that this question primarily relates to FIX 4.0.
>
> I have a question that relates to identifying where a trade originated when receiving it over a network (series of FIX nodes).
>
> Let’s say we have entities O, H and D, where the message originates at O and is sent to D via H, and the order is destined for X
>
> Assume that in such a case we have that
>
> SenderCompID=H
> OnbehalfOfCompID=O
> TargetCompID=D.
> DeliverToCompID=X
>
> Let us further assume that H starts sending orders through another FIX node N.
>
> Am I right to assume that the field content for a message arriving at D will be
>
> SenderCompID=H
> OnbehalfOfCompID=N
> TargetCompID=D.
> DeliverToCompID=X
>
>
> In other words we have lost the knowledge at node D that the actual origin of the order was O. Assume further, that the actual client/broker relationship is between D (that will then route the order further), and X. The account field will thus contain the account information of the account of D at X. There is thus in this scenario no obvious way to retain (at D) that the order originated at O.
>
> I have two questions:
>
> What is the ‘best practice’, using FIX 4.0, to retain this information.
> Are there better ways to do this un later versions of FIX?
>
> Thanx
> Herman
>
>
>