Defining new values for tag 456 (SecurityAltIDSource)

1

Hi,

I would like to receive suggestions on the following issue:

In the implementation of our FIX Server, for tag 456 (SecurityAltIDSource), we need to add some additional values to those defined by the standard.

We have reviewed another implementation and, in that case, they are defining additional values for tag 456 starting from the value “90”.

Is this the most appropriate way to extend the list of valid values? Starting from the value “90”?

Best regards
xavi

2

Tag 456 (SecurityAltIDSource) is naturally highly related to tag 22 (SecurityIDSource). The documentation for tag 22 states

"Identifies class or source of the SecurityID (48) value. Required if SecurityID is specified.

100+ are reserved for private security identifications"

so i’d go for 100+ rather than 90+, although expect you’d have quite a few years before the standard definitions reach 90

3

Hi,

Thanks for your help.

So, we will start by assigning the new values from 100+.

Best regards.
xavi

4

There seems to be a bug in the FIX Repository that shows up in FIXimate for SecurityIDSource(22). It shows Reserved100Plus as Union Datatype. This usually does mean “Values “100” and above are reserved for bilaterally agreed upon user defined enumerations.” However, this only applies to integer fields with a datatype of “int” where enumerated values are issued in a gapless sequence. Value 99 is then often used for “Other” and user defined values start with 100.

SecurityIDSource(22) and all of its derived fields are either “String” or “char” but not “int”. None of the derived fields shows Reserved100Plus as Union Datatype, also SecurityAltIDSource(456) does not show it, i.e. it does not support user defined values. The current values range from 1-9 and then A-X. Please do not assign values of 100 or above for SecurityAltIDSource(456).

@xbalo what kind of values are you missing in the standard? Have you checked FIX Latest (https://fiximate.fixtrading.org/) to see if there are newer values you may not be aware of? SecurityIDSource(22) and its derived fields are key fields in the message and only standard values should be used to identify sources. FIX has added a few over the years, also to support de-facto industry standards such as the Fidessa Instrument Mnemonic (FIM) and the Uniform Symbol (UMTF Symbol).

5

Hi Hanno,

Thanks for pointing out this typo. In that case, we will not add values to those already defined.

We will thoroughly review the list of values already defined to determine which ones best fit our needs.

Regards
xavi

6

@xbalo: I must apologise for my previous post as it turns out that it is not a bug but a feature :slight_smile: introduced with EP161 (https://www.fixtrading.org/extension-packs/). SecurityIDSource(22) was transitioned to a union datatype and combined with Reserved100Plus. It is a coincidence that SecurityAltIDSource(456) was forgotten and does not show Reserved100Plus as union datatype.

It is a rare case of using Reserved100Plus for String fields that are actually enumerated values instead of free text. Reserved100Plus ensures that it stays that way, i.e. only strings “100”, “101”,… are allowed as user defined values and not for example “My special ID source”.

I still urge you to check the latest valid values to see if anything fits and post to the forum if you have a business requirement that is not covered by any of the existing values.

7

Hi Hanno

Thanks for the update.

We are reviewing the current values.
If we finally have a business requirement not covered by the current values, we will post a request on the forum.

Regards.
xavi

1 Like