Imported from previous forum
Hi,
In FIX is it acceptable to forward a message which is already forwarded? For an example think A sends a message to B with DeliverToCompID field set. As a result B forwards the message to C. Then at C the message gets forwarded again. Is this acceptable?
Best Regards,
Hiranya
Yes, it is, at least from a technical perspective. The in the standard header allows you to capture the intermittent points. The target and sender fields change while you are following the chain, OnBehalf and DeliverTo give you the start- and endpoint of the chain.
Hi,
In FIX is it acceptable to forward a message which is already forwarded?
For an example think A sends a message to B with DeliverToCompID field
set. As a result B forwards the message to C. Then at C the message gets
forwarded again. Is this acceptable?Best Regards, Hiranya
Yes, it is, at least from a technical perspective. The in the
standard header allows you to capture the intermittent points. The
target and sender fields change while you are following the chain,
OnBehalf and DeliverTo give you the start- and endpoint of the chain.
The specification says routing is done based on the Sender, Target, OnBehalf and DeliverTo fields. HopGroup is used optionally to store routing history.
Doesn’t that mean that OnBehalf and DeliverTo fields also should change when the message is going through a chain of third parties?
Hiranya
Hi,
In FIX is it acceptable to forward a message which is already
forwarded? For an example think A sends a message to B with
DeliverToCompID field set. As a result B forwards the message to C.
Then at C the message gets forwarded again. Is this acceptable?Best Regards, Hiranya
Not necessarily, especially if your hops are for purely technical reasons and do not provide a business function. The receiver simply has to put the OnBehalf values into the DeliverTo fields when responding. If you change these values within the chain, then the elements within the chain need to have local knowledge about where a message needs to go. You do not need this if the ultimate endpoint is static. The hops might be different at times, i.e. represent alternate paths between two business entities.
In my view, DeliverTo from the first entity (A) should point to the nearest entity that looks into the business content of a message. If this entity (B) decides to forward the message to some other such entity (C), a new DeliverTo value is needed but the very first entity does not need any knowledge about this and only sees B. The example in the FIX documentation is different as it deals with Q between A and B being a service provider simply routing a message. In business terms, FIX defines the communication between two parties. In my example there are two such relationships, namely A/B and B/C.
Regards,
Hanno.
Yes, it is, at least from a technical perspective. The in
the standard header allows you to capture the intermittent points. The
target and sender fields change while you are following the chain,
OnBehalf and DeliverTo give you the start- and endpoint of the chain.The specification says routing is done based on the Sender, Target,
OnBehalf and DeliverTo fields. HopGroup is used optionally to store
routing history. Doesn’t that mean that OnBehalf and DeliverTo
fields also should change when the message is going through a chain
of third parties?Hiranya
Hi,
In FIX is it acceptable to forward a message which is already
forwarded? For an example think A sends a message to B with
DeliverToCompID field set. As a result B forwards the message to C.
Then at C the message gets forwarded again. Is this acceptable?Best Regards, Hiranya