Imported from previous forum
Greetings,
For the case of a third party (Q) relaying messages between two endpoints (A and B) can it be assumed that the two FIX sessions (A-Q and Q-B) are completely independent? As such, is there any requirement or strong reason to map MsgSeqNum’s from one session to the other?
The question arises in at least two areas:
Business Message Reject (MsgType=j) contains tag 45 RefSeqNum, the MsgSeqNum of the rejected message. If this is generated by B then it would have to be replaced with the appropriate number by Q before passing to A. Alternatively that field could be ignored and tag 379 BusinessRejectRefID used instead to identify the message. Is there some sort of best practice for this case?
PossDupFlag requires comparison of MsgSeqNum between messages. Is this exclusively done at the FIX engine level? PossResend seems to rely on use of OrderID etc to determine if the message is a duplicate and so would work at the application level.
If BusinessRejectRefID can avoid sending RefSeqNum and PossDupFlag can be resolved at the FIX engine level then it seems that maintaining a MsgSeqNum mapping table is unnecessary. Is this considered to be the case by the FIX community or am I missing something?
Thanks,
David.
Yes, the assumption is that the two FIX sessions are completely independent with regard to MsgSeqNum. When third parties are involved, a given FIX session (e.g. A-Q) may be multi-party from A’s perspective (using DeliverToCompID when A sends to Q) which definitely could not be 1:1 MsgSeqNum mapped in your example.
There is no reason to attempt to use the same MsgSeqNum values for the same message on both sessions, however, Q would have the responsibility to both "receive and forward" and "track" messages between A and B.
> Greetings,
>
> For the case of a third party (Q) relaying messages between two endpoints (A and B) can it be assumed that the two FIX sessions (A-Q and Q-B) are completely independent? As such, is there any requirement or strong reason to map MsgSeqNum’s from one session to the other?
>
> The question arises in at least two areas:
>
> Business Message Reject (MsgType=j) contains tag 45 RefSeqNum, the MsgSeqNum of the rejected message. If this is generated by B then it would have to be replaced with the appropriate number by Q before passing to A. Alternatively that field could be ignored and tag 379 BusinessRejectRefID used instead to identify the message. Is there some sort of best practice for this case?
>
> PossDupFlag requires comparison of MsgSeqNum between messages. Is this exclusively done at the FIX engine level? PossResend seems to rely on use of OrderID etc to determine if the message is a duplicate and so would work at the application level.
>
> If BusinessRejectRefID can avoid sending RefSeqNum and PossDupFlag can be resolved at the FIX engine level then it seems that maintaining a MsgSeqNum mapping table is unnecessary. Is this considered to be the case by the FIX community or am I missing something?
>
> Thanks,
>
> David.
>
>
I understand that the sequence numbers would be different for the same message passing through the A-Q session then the Q-B session. My question is essentially, is there any situation where it necessary to map between those numbers? In other words, does B need to reference to A a particular message by MsgSeqNum, such that Q would have to map from B’s number to A’s number? If so, what is that situation?
Thanks for your help.
David.
> Yes, the assumption is that the two FIX sessions are completely independent with regard to MsgSeqNum. When third parties are involved, a given FIX session (e.g. A-Q) may be multi-party from A’s perspective (using DeliverToCompID when A sends to Q) which definitely could not be 1:1 MsgSeqNum mapped in your example.
>
> There is no reason to attempt to use the same MsgSeqNum values for the same message on both sessions, however, Q would have the responsibility to both “receive and forward” and “track” messages between A and B.
>
>
> > Greetings,
> >
> > For the case of a third party (Q) relaying messages between two endpoints (A and B) can it be assumed that the two FIX sessions (A-Q and Q-B) are completely independent? As such, is there any requirement or strong reason to map MsgSeqNum’s from one session to the other?
> >
> > The question arises in at least two areas:
> >
> > Business Message Reject (MsgType=j) contains tag 45 RefSeqNum, the MsgSeqNum of the rejected message. If this is generated by B then it would have to be replaced with the appropriate number by Q before passing to A. Alternatively that field could be ignored and tag 379 BusinessRejectRefID used instead to identify the message. Is there some sort of best practice for this case?
> >
> > PossDupFlag requires comparison of MsgSeqNum between messages. Is this exclusively done at the FIX engine level? PossResend seems to rely on use of OrderID etc to determine if the message is a duplicate and so would work at the application level.
> >
> > If BusinessRejectRefID can avoid sending RefSeqNum and PossDupFlag can be resolved at the FIX engine level then it seems that maintaining a MsgSeqNum mapping table is unnecessary. Is this considered to be the case by the FIX community or am I missing something?
> >
> > Thanks,
> >
> > David.
> >
> >
>
I don’t think there is such a situation. You may be communicating via FIX to a service bureau which is not communicating via FIX on the other end (e.g. to terminal-based system, CMS, native API, etc.)
> I understand that the sequence numbers would be different for the same message passing through the A-Q session then the Q-B session. My question is essentially, is there any situation where it necessary to map between those numbers? In other words, does B need to reference to A a particular message by MsgSeqNum, such that Q would have to map from B’s number to A’s number? If so, what is that situation?
>
> Thanks for your help.
>
> David.
>
> > Yes, the assumption is that the two FIX sessions are completely independent with regard to MsgSeqNum. When third parties are involved, a given FIX session (e.g. A-Q) may be multi-party from A’s perspective (using DeliverToCompID when A sends to Q) which definitely could not be 1:1 MsgSeqNum mapped in your example.
> >
> > There is no reason to attempt to use the same MsgSeqNum values for the same message on both sessions, however, Q would have the responsibility to both “receive and forward” and “track” messages between A and B.
> >
> >
> > > Greetings,
> > >
> > > For the case of a third party (Q) relaying messages between two endpoints (A and B) can it be assumed that the two FIX sessions (A-Q and Q-B) are completely independent? As such, is there any requirement or strong reason to map MsgSeqNum’s from one session to the other?
> > >
> > > The question arises in at least two areas:
> > >
> > > Business Message Reject (MsgType=j) contains tag 45 RefSeqNum, the MsgSeqNum of the rejected message. If this is generated by B then it would have to be replaced with the appropriate number by Q before passing to A. Alternatively that field could be ignored and tag 379 BusinessRejectRefID used instead to identify the message. Is there some sort of best practice for this case?
> > >
> > > PossDupFlag requires comparison of MsgSeqNum between messages. Is this exclusively done at the FIX engine level? PossResend seems to rely on use of OrderID etc to determine if the message is a duplicate and so would work at the application level.
> > >
> > > If BusinessRejectRefID can avoid sending RefSeqNum and PossDupFlag can be resolved at the FIX engine level then it seems that maintaining a MsgSeqNum mapping table is unnecessary. Is this considered to be the case by the FIX community or am I missing something?
> > >
> > > Thanks,
> > >
> > > David.
> > >
> > >
> >
>
> For the case of a third party (Q) relaying
> messages between two endpoints
> (A and B) can it be assumed that the two
> FIX sessions (A-Q and Q-B) are
> completely independent?
As Scott says, the sessions themselves are independent …
> As such, is there any requirement or strong
> reason to map MsgSeqNum’s from
> one session to the other?
… but there are some reasons to consider maintaining a map nevertheless
…
> The question arises in at least two areas:
>
> Business Message Reject (MsgType=j) contains
> tag 45 RefSeqNum, the
> MsgSeqNum of the rejected message. If this is
> generated by B then it would
> have to be replaced with the appropriate
> number by Q before passing to A.
> Alternatively that field could be ignored
> and tag 379 BusinessRejectRefID
> used instead to identify the message.
> Is there some sort of best practice
> for this case?
The best practice is to supply as much information as possible, so it would
include both the BusinessRejectRefID and the RefSeqNum (and the text
description etc 
This gives the system receiving the reject more
possibilities (a dumb system will still work, whereas if you don’t send
RefSeqNum, it may not).
Perhaps more serious is what to do if the problem with the message is that
the business ref ID is faulty. For example, suppose the ID is a duplicate;
then you can’t use it to identify the particular message that is being
rejected. Similarly, if the BusinessRejectReason is 1=Unknown ID then it
may not be wise to use that ID to identify the message since it may have
been corrupted somewhere.
> PossDupFlag requires comparison of
> MsgSeqNum between messages. Is this
> exclusively done at the FIX engine level?
This is generally done by the engine, but some engines do provide hooks so that
the application can decide whether to resend particular messages or not.
For example, the buy-side may not wish to resend an order at a later time.
So the answer to your question depends on the sophistication of the setup -
it’s a requirements issue. Do the end users need that possibility, or are
they OK with a simple solution?
> it seems that maintaining a MsgSeqNum
> mapping table is unnecessary. Is
> this considered to be the case by
> the FIX community or am I missing
> something?
There is another reason that you might consider a mapping table, which is as
part of a scheme designed to allow auditing and debugging of the message
forwarding system.
Cheers, Dave