Imported from previous forum
[ original email was from Jeremy Sutton - jezza.sutton@patsystems.com ]
I and a counter-party are talking about a FIX interface in which the instrument to trade will be identified by a SecurityID which is based on the exchange symbol but is somewhat extended in that it includes the maturity of the future to be traded (something that is not always defined in the exchange symbol).
In the interest of a more standard FIX, should I encourage them to use SecurityIDSource of Exchange (8) which is close-ish or define one in the 100+ range, which the standard says is for “private security identifications”.
I and a counter-party are talking about a FIX interface in which the
instrument to trade will be identified by a SecurityID which is based on
the exchange symbol but is somewhat extended in that it includes the
maturity of the future to be traded (something that is not always
defined in the exchange symbol).
Probably you have checked for other fields which could transport maturity information.
In the interest of a more standard FIX, should I encourage them to use
SecurityIDSource of Exchange (8) which is close-ish or define one in the
100+ range, which the standard says is for “private security
identifications”.
We also have the situation where we had to place extra information into the SecurityID field. We felt the value of 8 (Exchange Symbol) fitted best, since it looked like some exchange specific, proprietary information. Indeed, I would feel better if I could replace it by 4 for ISIN.
So I would like to hear any other ideas/objections.
Cheers, Jörg
[ original email was from Jeremy Sutton - jezza.sutton@patsystems.com ]
> Probably you have checked for other fields which could transport
maturity information.
Normally we would use MaturityMonthYear for this but the counter-party has a preference to use their internal direct access code, which saves them mapping back and forth.
We also have the situation where we had to place extra information
into the SecurityID field. We felt the value of 8 (Exchange Symbol)
fitted best, since it looked like some exchange specific,
proprietary information. Indeed, I would feel better if I could
replace it by 4 for ISIN.So I would like to hear any other ideas/objections.
I think the ISIN value should be left to indicate what really are ISIN codes - that is, I would not use value 4 unless the SecurityID actually contained an ISIN code.
We will probably stick with using 8 for the same reasons you have. Although the values are not exactly the same as the exchange symbols they bear a fairly stroing resemblance to them.
information. Indeed, I would feel better if I could replace it by 4
for ISIN.I think the ISIN value should be left to indicate what really are ISIN
codes - that is, I would not use value 4 unless the SecurityID actually
contained an ISIN code.
True. Actually I did want to say: I would like to use onyl the ISIN in the field SecurityID (and therefore could replace it by 4).
Jörg
[ original email was from Raj Patel - raj.t.patel@hsbcgroup.com ]
Have you considered using Security Alternate identifiers ?
This block can be used to hold an alternate identifier that is agreed with the counterparty
Info:-
" The Security Alternative identifier block should not be populated unless SecurityID and SecurityIDSource are populated and should not duplicate the SecurityID and SecurityIDSource values contained in the SecurityID/SecurityIDSource tags.
Use of SecurityAltID may be used if bilaterally agreed to assist in security identification, and does not imply an obligation on the receiver of the message to ensure validity or consistency with the SecurityID and SecurityIDSource fields which take precedence "
Regards Raj