Imported from previous forum
[ original email was from Igor Seleznev - selez@mail.ru ]
According to FIX specs for 4.3/4.4:
http://fixprotocol.org/specifications/fix4.3fiximate/field_description.html#symbol
http://fixprotocol.org/specifications/fix4.4fiximate/field_description.html#Symbol
Symbol<55> can be in the “Instrument” component block only, and this block marks the tag as “***” in 4.3 and “N” in 4.4:
http://fixprotocol.org/specifications/fix4.3fiximate/instrument.html
http://fixprotocol.org/specifications/fix4.4fiximate/Instrument.html
In docs “***” explained as [*** = Required status should match “Req’d” setting for component block in the message definition], not sure I understand it correctly.
Also, according to some users’ experience, it is de facto mandatory:
http://fixprotocol.org/discuss/read/3bfc873a
So, the question both for 4.3 and 4.4: is the tag Symbol<55> really optional?
Igor,
Am not quite sure if I am 100% correct on this. As per my understanding, Fix 4.3 & 4.4 have made tag 55 as an optional field. Prior to 4.3 it was mandatory to be sent in a new order apart from other tags such as 22/28, 107, etc.
However, what I understand is that from Fix 4.3 & 4.4 specs, this tag was made optional and instead was replaced by the definition: Instrument - component block, which in turn contains a number of tags which can be used by the client to communicate the security details.
Regards,
Sunil
[ original email was from Rikard Hedberg - rikard.hedberg@omxgroup.com ]
Symbol (55) is a required field in the Instrument component block, in the case you don’t have a symbol you should fill the field with “[N/A]” (without quote marks but with brackets) and generally use the SecurityID instead (some markets however use other fields as identifiers).
There is a long story to why this is the case and about attempts to make it optional. The reasons include:
- FIX’s heritage in US equities where trading is done on symbols and the breakage that would occur with a change
- that the Instrument block sometimes is the first component in a repeating group, meaning the Symbol must be mandatory in those cases
- etc
Regards
Rikard
[ original email was from Igor Seleznev - selez@mail.ru ]
Thanks for your answers!
I actually feel like I’ve come to what I’ve initially started from: FIX specs mark it as optional (FIX 4.4 for sure, FIX 4.3 – so-so), but de facto it seems like mandatory.
I don’t understand why it is not marked as mandatory to withdraw all questions from agenda?
Having all that said, if you are about to validate an incoming FIX 4.4 message with the component block, would you require the presence of Symbol, or not (of course, without looking into its actual value)?
[ original email was from Rikard Hedberg - rikard.hedberg@omxgroup.com ]
Igor,
the problem is that the Instrument block is not always mandatory. When no field of the instrument block need to be specified, the Symbol (55) does not need to be there either. This would occur e.g. in cases where the Instrument block is used as an optional filter for a query, subscription or mass action as in Order Mass Cancel Request.
A component block is just a wrapper for a set of fields that are related. The wrapper itself is not represented in a message, so any required properties of the fields cannot be limited to whether the wrapper exists or not. In many cases the component blocks contains a repeating group, but that is not the case for the Instrument one. Still the Instrument block is used inside repeating groups and sometimes as the first thing there. In those cases the Symbol, being the delimiter of the repeating group, must be specified if NoOfXXX is specified.
Given the above usages of the Instrument component block, the Symbol (55) cannot be marked as mandatory in the Instrument block. I and many others have had the same problem as you in understanding the rules around the Ssymbol (55) field. Hope this explanation helps.
Regard
Rikard
There are two independent elements to distinguish. One is the Instrument component block and the other is the repeating group. If no repeating group is involved, then the value of “Req’d” for the Instrument component block in this message tells you whether Symbol is mandatory or not. The FIX documentation (not the FIXimate)contains “***” up to FIX 4.4 and a footnote, FIX 5.0 only contains the footnote. It says that the setting of “Req’d” should match the one at the component block level. The comment field of Symbol tells you to use “[N/A]” when you do not have a value which shows you that if an instrument needs to be conveyed then the field Symbol is always part of that, even if it means to send a dummy value.
The second case where Instrument component block is the first “entry” of a repeating group, Symbol is always mandatory for technical reasons due to the lack of an explicit delimiter. The first field in a repeating group is always required so that the parser has such a delimiter to work with.
For consistency, I would simply see Symbol as mandatory for now. There is work underway to remove the technical restriction related to repeating groups and delimiters. Then it is time to start a discussion on the security identification via Symbol vs SecurityID/SecurityIDSource (value 8=Exchange Symbol).
Regards,
Hanno.
Thanks for your answers!
I actually feel like I’ve come to what I’ve initially started from: FIX
specs mark it as optional (FIX 4.4 for sure, FIX 4.3 – so-so), but de
facto it seems like mandatory.I don’t understand why it is not marked as mandatory to withdraw all
questions from agenda?Having all that said, if you are about to validate an incoming FIX
4.4 message with the component block, would you require
the presence of Symbol, or not (of course, without looking into its
actual value)?
[ original email was from Igor Seleznev - selez@mail.ru ]
Thanks to your explanations I’ve finally understood the footnote for “***” 
So, if no repeating group is involved, Symbol becomes mandatory if and only if the Instrument component block in this message is mandatory?
If there is a repeating group, Symbol becomes mandatory if and only if the Instrument component block is the first “entry” of that group?
Actually both these situations look similar: they both seem to be based on some technical glitch in parsing you mention (is it indeed a case?). Am I right that Symbol got affected here because it is the very first tag of the Instrument component block? If so, I am curious are there other tags with similar “life” (I would call it “strangely required”)?
All this indeed seems confusing, also I don’t see how the presense of Symbol in aforementioned cases could help to avoid problems with parsing… nevertheless, I think now I understand the underlying problems more closely, thanks for explanations!
P.S. In my test case, we used SecurityID/SecurityIDSource, and it was a surprise to know that we have to populate Symbol for some reason too.
Your assumptions are correct and I appreciate that you use SecurityID/Source for the “real” content. The “glitch” you are referring to was a choice made by FPL a while ago to avoid the need for an explicit delimiter field for every repeating group. This was a good idea at the time but has become a burden for Symbol as soon as you try to move away from a US equity market. Repeating groups have their mandatory fields come first, the Instrument block is special as there is more than one field denoting the same type of information. The problem has been recognized and will eventually be solved. Until then, we just need to use a little more bandwidth…