Message Uniqueness

[fplpo_x]

Imported from previous forum

[fplpo_x]

[ original email was from Tyler Longpre - ]
What makes a message unique?

For example:
An Indication of Interest has an IOIid field.
But this would not be unique unless all of the companys
of the world had a central place for storing the next available ID.

1. So, message uniqueness is IOIid and SenderCompID?

But, what if the same company has 20 salesman sending IOIs? There would have to be an ID storage area per company?

2. Unless, IOI message uniqueness was base on IOIid, SenderCompID and SenderSubID.

Any feedback would be much appreciated.

                        Thanks,
                        Tyler

[fplpo_x]

[ original email was from Scott Atwell - ]
A single FIX session could represent IOI and other business messages from multiple counterparties. In that case, the FIX messages would represent the company via the OnBehalfOfCompID and OnBehalfOfSubID fields in FIX 4.0 (in 3.0 you would have to kludge this via a single SenderSubID field). I’m not sure that it is clear whether or not in a multiple-company FIX session scenario a field like IOIid must be unique for all counterparties represented or just for each counterparty. I would think that the unique requirement would be by counterparty.

It should be unique across salesman. Unfortunately IOIid is currently of type int, but I believe 4.1 will make all of these ID fields of type char which might simplify combining SubID with IOIid.

The IOIid’s primary purpose is to enable the buyside to know and reference a previously sent IOI when it receives a Cancel or Replace IOITransType. (It can also be used to reference an IOI received when sending a NewOrder).

The same issues would apply to AdvID, ExecID, etc. in other business-level messages and probably need to be accounted for in one’s system design.

Scott Atwell - American Century
scott_atwell@americancentury.com

> What makes a message unique?
>
> For example:
> An Indication of Interest has an IOIid field.
> But this would not be unique unless all of the companys
> of the world had a central place for storing the next available ID.
>
> 1) So, message uniqueness is IOIid and SenderCompID?
>
> But, what if the same company has 20 salesman sending IOIs? There would have to be an ID storage area per company?
>
> 2) Unless, IOI message uniqueness was base on IOIid, SenderCompID and SenderSubID.
>
> Any feedback would be much appreciated.
>
>
> Thanks,
> Tyler
>
>

[fplpo_x]

[ original email was from Gordon Mitchell - Gordon.Mitchell@Reuters.Com ]
How long is a message id unique for? Does unique mean forever or is an id typically unique for a given period (e.g. one trading cycle).

For example, if receiving Adverts from a counterparty would I be expected to modify or cancel adverts from the previous trading day. This would mean keeping id’s unique for more than one trading cycle. The question then is how long should id be unique for?

IOIs have a ValidUntilTime so theoretically (although unlikely) I can make an IOI valid for as lomng as I like. This would mean the IOIid could not be re-used whilst the IOI was ‘live’.

What’s the expected practise here? Does FIX suggest an approach?

Would appreciate any feedback on how people currently handle this.

Rgds, Gordon

> A single FIX session could represent IOI and other business messages from multiple counterparties. In that case, the FIX messages would represent the company via the OnBehalfOfCompID and OnBehalfOfSubID fields in FIX 4.0 (in 3.0 you would have to kludge this via a single SenderSubID field). I’m not sure that it is clear whether or not in a multiple-company FIX session scenario a field like IOIid must be unique for all counterparties represented or just for each counterparty. I would think that the unique requirement would be by counterparty.
>
> It should be unique across salesman. Unfortunately IOIid is currently of type int, but I believe 4.1 will make all of these ID fields of type char which might simplify combining SubID with IOIid.
>
> The IOIid’s primary purpose is to enable the buyside to know and reference a previously sent IOI when it receives a Cancel or Replace IOITransType. (It can also be used to reference an IOI received when sending a NewOrder).
>
> The same issues would apply to AdvID, ExecID, etc. in other business-level messages and probably need to be accounted for in one’s system design.
>
> Scott Atwell - American Century
> scott_atwell@americancentury.com
>
>
>
> > What makes a message unique?
> >
> > For example:
> > An Indication of Interest has an IOIid field.
> > But this would not be unique unless all of the companys
> > of the world had a central place for storing the next available ID.
> >
> > 1) So, message uniqueness is IOIid and SenderCompID?
> >
> > But, what if the same company has 20 salesman sending IOIs? There would have to be an ID storage area per company?
> >
> > 2) Unless, IOI message uniqueness was base on IOIid, SenderCompID and SenderSubID.
> >
> > Any feedback would be much appreciated.
> >
> >
> > Thanks,
> > Tyler
> >
> >
>

[fplpo_x]

[ original email was from Matt Koehler - matt.koehler@transacttools.net ]
Hi Gordon -

From a business/practical perspective, IOIs generally have a really short lifespan (esp. in volatile markets.) I don’t think I’ve ever heard of an IOI that was valid for much more than 15 minutes to 1/2 hour. Firms will re-publish IOIs every so often to announce that they’re still valid (in case a buy side firm doesn’t pay attention to the expiry time, or the sell-side’s systems can’t set it.)

Some additional perspective on Scott’s response - IOIs aren’t necessarily always explicitly sent out by a salesperson. The same IOI can be sent out to multiple firms by multiple ‘salespeople’ – really a system doing the work for them. Admittedly, salespeople are responsible for maintaining the rules on which of their clients get what.

so to answer your question on a practical level, you’re probably OK resetting the ID’s daily. or you could embed a date/time stamp in the IOI ID and be done with it. unique forever!

-matt

> How long is a message id unique for? Does unique mean forever or is an id typically unique for a given period (e.g. one trading cycle).
>
> For example, if receiving Adverts from a counterparty would I be expected to modify or cancel adverts from the previous trading day. This would mean keeping id’s unique for more than one trading cycle. The question then is how long should id be unique for?
>
> IOIs have a ValidUntilTime so theoretically (although unlikely) I can make an IOI valid for as lomng as I like. This would mean the IOIid could not be re-used whilst the IOI was ‘live’.
>
> What’s the expected practise here? Does FIX suggest an approach?
>
> Would appreciate any feedback on how people currently handle this.
>
> Rgds, Gordon
>
>
> > A single FIX session could represent IOI and other business messages from multiple counterparties. In that case, the FIX messages would represent the company via the OnBehalfOfCompID and OnBehalfOfSubID fields in FIX 4.0 (in 3.0 you would have to kludge this via a single SenderSubID field). I’m not sure that it is clear whether or not in a multiple-company FIX session scenario a field like IOIid must be unique for all counterparties represented or just for each counterparty. I would think that the unique requirement would be by counterparty.
> >
> > It should be unique across salesman. Unfortunately IOIid is currently of type int, but I believe 4.1 will make all of these ID fields of type char which might simplify combining SubID with IOIid.
> >
> > The IOIid’s primary purpose is to enable the buyside to know and reference a previously sent IOI when it receives a Cancel or Replace IOITransType. (It can also be used to reference an IOI received when sending a NewOrder).
> >
> > The same issues would apply to AdvID, ExecID, etc. in other business-level messages and probably need to be accounted for in one’s system design.
> >
> > Scott Atwell - American Century
> > scott_atwell@americancentury.com
> >
> >
> >
> > > What makes a message unique?
> > >
> > > For example:
> > > An Indication of Interest has an IOIid field.
> > > But this would not be unique unless all of the companys
> > > of the world had a central place for storing the next available ID.
> > >
> > > 1) So, message uniqueness is IOIid and SenderCompID?
> > >
> > > But, what if the same company has 20 salesman sending IOIs? There would have to be an ID storage area per company?
> > >
> > > 2) Unless, IOI message uniqueness was base on IOIid, SenderCompID and SenderSubID.
> > >
> > > Any feedback would be much appreciated.
> > >
> > >
> > > Thanks,
> > > Tyler
> > >
> > >
> >
>

[scott.atwell]

If possible, you may want to consider using a "serial" (just add +1 each time) number for ids such as IOIid. It definitely should be unique through the course of a "fix session" defined by when you start MsgSeqNum with 1 and when you restart with MsgSeqNum of 1 (typically a "trading day").

> Hi Gordon -
>
> From a business/practical perspective, IOIs generally have a really short lifespan (esp. in volatile markets.) I don’t think I’ve ever heard of an IOI that was valid for much more than 15 minutes to 1/2 hour. Firms will re-publish IOIs every so often to announce that they’re still valid (in case a buy side firm doesn’t pay attention to the expiry time, or the sell-side’s systems can’t set it.)
>
> Some additional perspective on Scott’s response - IOIs aren’t necessarily always explicitly sent out by a salesperson. The same IOI can be sent out to multiple firms by multiple ‘salespeople’ – really a system doing the work for them. Admittedly, salespeople are responsible for maintaining the rules on which of their clients get what.
>
> so to answer your question on a practical level, you’re probably OK resetting the ID’s daily. or you could embed a date/time stamp in the IOI ID and be done with it. unique forever!
>
> -matt
>
>
> > How long is a message id unique for? Does unique mean forever or is an id typically unique for a given period (e.g. one trading cycle).
> >
> > For example, if receiving Adverts from a counterparty would I be expected to modify or cancel adverts from the previous trading day. This would mean keeping id’s unique for more than one trading cycle. The question then is how long should id be unique for?
> >
> > IOIs have a ValidUntilTime so theoretically (although unlikely) I can make an IOI valid for as lomng as I like. This would mean the IOIid could not be re-used whilst the IOI was ‘live’.
> >
> > What’s the expected practise here? Does FIX suggest an approach?
> >
> > Would appreciate any feedback on how people currently handle this.
> >
> > Rgds, Gordon
> >
> >
> > > A single FIX session could represent IOI and other business messages from multiple counterparties. In that case, the FIX messages would represent the company via the OnBehalfOfCompID and OnBehalfOfSubID fields in FIX 4.0 (in 3.0 you would have to kludge this via a single SenderSubID field). I’m not sure that it is clear whether or not in a multiple-company FIX session scenario a field like IOIid must be unique for all counterparties represented or just for each counterparty. I would think that the unique requirement would be by counterparty.
> > >
> > > It should be unique across salesman. Unfortunately IOIid is currently of type int, but I believe 4.1 will make all of these ID fields of type char which might simplify combining SubID with IOIid.
> > >
> > > The IOIid’s primary purpose is to enable the buyside to know and reference a previously sent IOI when it receives a Cancel or Replace IOITransType. (It can also be used to reference an IOI received when sending a NewOrder).
> > >
> > > The same issues would apply to AdvID, ExecID, etc. in other business-level messages and probably need to be accounted for in one’s system design.
> > >
> > > Scott Atwell - American Century
> > > scott_atwell@americancentury.com
> > >
> > >
> > >
> > > > What makes a message unique?
> > > >
> > > > For example:
> > > > An Indication of Interest has an IOIid field.
> > > > But this would not be unique unless all of the companys
> > > > of the world had a central place for storing the next available ID.
> > > >
> > > > 1) So, message uniqueness is IOIid and SenderCompID?
> > > >
> > > > But, what if the same company has 20 salesman sending IOIs? There would have to be an ID storage area per company?
> > > >
> > > > 2) Unless, IOI message uniqueness was base on IOIid, SenderCompID and SenderSubID.
> > > >
> > > > Any feedback would be much appreciated.
> > > >
> > > >
> > > > Thanks,
> > > > Tyler
> > > >
> > > >
> > >
> >
>

[davehoworth_x]

Hi Gordon,

Further to what Scott and Matt said:

FIX 4.2 Appendix L says: "It is expected that every indication of interest message will have a unique IOIid for the fix session usually the trading day."

I think this is a very concise statement of FIX philosophy

It expresses a very desirable goal, but recognizes - implicitly - that everything is subject to bilateral agreement. In this case, the reality is whatever the source of an IOI stream has actually implemented. The problem for the recipient is how to key it in their systems.

The obvious ideal solution is to assign an arbitrary but truly globally unique ID (from the recipient’s point of view) and have a secondary table that cross-references it with the time and source.

So the question is whether there are any costs, such as a technical straitjacket, that make the obvious solution undesirable. And what’s the penalty for not being able to handle an ‘unusual’ (pronounced ‘cussed’) source.

Cheers, Dave

> How long is a message id unique for? Does unique mean forever or is an id typically unique for a given period (e.g. one trading cycle).
>
> For example, if receiving Adverts from a counterparty would I be expected to modify or cancel adverts from the previous trading day. This would mean keeping id’s unique for more than one trading cycle. The question then is how long should id be unique for?
>
> IOIs have a ValidUntilTime so theoretically (although unlikely) I can make an IOI valid for as lomng as I like. This would mean the IOIid could not be re-used whilst the IOI was ‘live’.
>
> What’s the expected practise here? Does FIX suggest an approach?
>
> Would appreciate any feedback on how people currently handle this.
>
> Rgds, Gordon