Imported from previous forum
I would appreciate some clarification. I am referring to the ‘FIX4.1 with Errata’ document. Page 7 states that for Required Fields ‘Systems should be designed to operate when only the required and conditionally required fields are present’.
For most messages, the Symbol field is required and SecurityID (along with IDSource) is an optional field. This is fine within North America where tickers are explicit, but in the international community tickers can be ambiguous. However according to page 7, the Symbol field, which contains tickers, must be present.
I do realise that it is possible to supplement the ticker information with, for example, a SEDOL to get around this ambiguity, but the statement on page 7 has more implication than that. Systems are being developed that are ‘Fix 4.x’ compliant which only use the ‘required’ and ‘conditionally required’ fields. These do not contain SecurityID and IDSource so are difficult to implement outside North America.
There are several ways forward to counter this problem. One would be to make Symbol an optional field for backwards compatibility and make SecurityID and IDSource required. Another would be to make all three fields required in future versions. A further solution may be to ‘flag’ certain fields as being required for ‘Fix 4.x International’ enabling FIX developers to certify that the minimum fields have been included to their protocol to enable easier implimentation in the international marketplace.
Any further discussion would be gratefully received.
Many thanks,
Roger Pembery.
IDSource and SecurityID have benefits within North America as well. The fact that Symbol is a required field should not present a problem if you’re using IDSource/SecurityID. Most systems which match against symbol masters and use the IDSource/SecurityID would attempt to match that identifier before attempting to match on the Symbol. You simply need to provide a value for the Symbol field and if you argue that no “ticker” is applicable for that particular security then you could easily populate the Symbol field with the SecurityID value. I think it is unwise to consider making Symbol non-required.
I don’t think we can make IDSource/SecurityID required, though. This requires one’s system to have a security master/cross reference and some FIX implementations are “standalone” (display what it receives and send what you type in) in nature. Those of us using FIX internationally quickly realize the benefits of using IDSource/SecurityID and the use of those fields (as well as Currency and others) should be “recommended”.
> I would appreciate some clarification. I am referring to the ‘FIX4.1 with Errata’ document. Page 7 states that for Required Fields ‘Systems should be designed to operate when only the required and conditionally required fields are present’.
>
> For most messages, the Symbol field is required and SecurityID (along with IDSource) is an optional field. This is fine within North America where tickers are explicit, but in the international community tickers can be ambiguous. However according to page 7, the Symbol field, which contains tickers, must be present.
>
> I do realise that it is possible to supplement the ticker information with, for example, a SEDOL to get around this ambiguity, but the statement on page 7 has more implication than that. Systems are being developed that are ‘Fix 4.x’ compliant which only use the ‘required’ and ‘conditionally required’ fields. These do not contain SecurityID and IDSource so are difficult to implement outside North America.
>
> There are several ways forward to counter this problem. One would be to make Symbol an optional field for backwards compatibility and make SecurityID and IDSource required. Another would be to make all three fields required in future versions. A further solution may be to ‘flag’ certain fields as being required for ‘Fix 4.x International’ enabling FIX developers to certify that the minimum fields have been included to their protocol to enable easier implimentation in the international marketplace.
>
> Any further discussion would be gratefully received.
>
> Many thanks,
>
> Roger Pembery.
>
Thanks for the prompt reply.
I agree with your answer. I think though that it is necessary to stress to software developers certain fields are more useful to the international community. I have come across several systems which only populate the symbol field and have no scope for the optional fields. This means that to get the system to work efficiently it is necessary to populate the symbol field with non-ticker data. Obviously, that is not a good idea.
To a person who is familiar with FIX your suggestion is common sense. However there are a companies creating ‘FIX Gateways’ who simply create the minimum system to say that they are compliant with FIX 4.x. We need to educate them to be able to handle these optional fields or FIX will not be that popular outside North America without some non-standard customizations made, or some further development. I feel that statements indicating which fields are recommended, such as yours below showing the use of SecurityID, will save months of development reworking an already released product.
e.g. If I am developing a FIX gateway of some sort that makes multiple connections and I create it to look only at symbol. However once I start testing I find that all the messages from one source are being rejected. This is because they are sending RIC codes down in the symbol field. This is because they quickly developed their gateway to the mininum specs and so SecurityID is not included. They realised that tickers did not fullfill their requirements, and so they send RICs. They cannot change their code very easily as their other clients are coding to this specification, even though it is not FIX.
If there had been a statement in the FIX protocol document stating that it is a good idea to include the SecurityID and IDSouce fields for non-North American securities then all this may have been avoided.
Remember also that the North American community is more familiar with FIX. They may be on version 2 of their Gateway. This may not be the case in Europe and so guidance for the first version of their gateway should be included. I would very much like FIX to expand outside the US, but issues like this can delay products by several months.
To summarise:
I agree with you below as to making the fields required, but can we make them ‘recommended’ in the text. There are a lot of optional fields, but some are less optional than others.
> IDSource and SecurityID have benefits within North America as well. The fact that Symbol is a required field should not present a problem if you’re using IDSource/SecurityID. Most systems which match against symbol masters and use the IDSource/SecurityID would attempt to match that identifier before attempting to match on the Symbol. You simply need to provide a value for the Symbol field and if you argue that no “ticker” is applicable for that particular security then you could easily populate the Symbol field with the SecurityID value. I think it is unwise to consider making Symbol non-required.
>
> I don’t think we can make IDSource/SecurityID required, though. This requires one’s system to have a security master/cross reference and some FIX implementations are “standalone” (display what it receives and send what you type in) in nature. Those of us using FIX internationally quickly realize the benefits of using IDSource/SecurityID and the use of those fields (as well as Currency and others) should be “recommended”.
>
>
> > I would appreciate some clarification. I am referring to the ‘FIX4.1 with Errata’ document. Page 7 states that for Required Fields ‘Systems should be designed to operate when only the required and conditionally required fields are present’.
> >
> > For most messages, the Symbol field is required and SecurityID (along with IDSource) is an optional field. This is fine within North America where tickers are explicit, but in the international community tickers can be ambiguous. However according to page 7, the Symbol field, which contains tickers, must be present.
> >
> > I do realise that it is possible to supplement the ticker information with, for example, a SEDOL to get around this ambiguity, but the statement on page 7 has more implication than that. Systems are being developed that are ‘Fix 4.x’ compliant which only use the ‘required’ and ‘conditionally required’ fields. These do not contain SecurityID and IDSource so are difficult to implement outside North America.
> >
> > There are several ways forward to counter this problem. One would be to make Symbol an optional field for backwards compatibility and make SecurityID and IDSource required. Another would be to make all three fields required in future versions. A further solution may be to ‘flag’ certain fields as being required for ‘Fix 4.x International’ enabling FIX developers to certify that the minimum fields have been included to their protocol to enable easier implimentation in the international marketplace.
> >
> > Any further discussion would be gratefully received.
> >
> > Many thanks,
> >
> > Roger Pembery.
> >
>
I have captured the suggestion as a candidate for a future Errata. thanks.
> Thanks for the prompt reply.
>
> I agree with your answer. I think though that it is necessary to stress to software developers certain fields are more useful to the international community. I have come across several systems which only populate the symbol field and have no scope for the optional fields. This means that to get the system to work efficiently it is necessary to populate the symbol field with non-ticker data. Obviously, that is not a good idea.
>
> To a person who is familiar with FIX your suggestion is common sense. However there are a companies creating ‘FIX Gateways’ who simply create the minimum system to say that they are compliant with FIX 4.x. We need to educate them to be able to handle these optional fields or FIX will not be that popular outside North America without some non-standard customizations made, or some further development. I feel that statements indicating which fields are recommended, such as yours below showing the use of SecurityID, will save months of development reworking an already released product.
>
> e.g. If I am developing a FIX gateway of some sort that makes multiple connections and I create it to look only at symbol. However once I start testing I find that all the messages from one source are being rejected. This is because they are sending RIC codes down in the symbol field. This is because they quickly developed their gateway to the mininum specs and so SecurityID is not included. They realised that tickers did not fullfill their requirements, and so they send RICs. They cannot change their code very easily as their other clients are coding to this specification, even though it is not FIX.
>
> If there had been a statement in the FIX protocol document stating that it is a good idea to include the SecurityID and IDSouce fields for non-North American securities then all this may have been avoided.
>
> Remember also that the North American community is more familiar with FIX. They may be on version 2 of their Gateway. This may not be the case in Europe and so guidance for the first version of their gateway should be included. I would very much like FIX to expand outside the US, but issues like this can delay products by several months.
>
> To summarise:
>
> I agree with you below as to making the fields required, but can we make them ‘recommended’ in the text. There are a lot of optional fields, but some are less optional than others.
>
> > IDSource and SecurityID have benefits within North America as well. The fact that Symbol is a required field should not present a problem if you’re using IDSource/SecurityID. Most systems which match against symbol masters and use the IDSource/SecurityID would attempt to match that identifier before attempting to match on the Symbol. You simply need to provide a value for the Symbol field and if you argue that no “ticker” is applicable for that particular security then you could easily populate the Symbol field with the SecurityID value. I think it is unwise to consider making Symbol non-required.
> >
> > I don’t think we can make IDSource/SecurityID required, though. This requires one’s system to have a security master/cross reference and some FIX implementations are “standalone” (display what it receives and send what you type in) in nature. Those of us using FIX internationally quickly realize the benefits of using IDSource/SecurityID and the use of those fields (as well as Currency and others) should be “recommended”.
> >
> >
> > > I would appreciate some clarification. I am referring to the ‘FIX4.1 with Errata’ document. Page 7 states that for Required Fields ‘Systems should be designed to operate when only the required and conditionally required fields are present’.
> > >
> > > For most messages, the Symbol field is required and SecurityID (along with IDSource) is an optional field. This is fine within North America where tickers are explicit, but in the international community tickers can be ambiguous. However according to page 7, the Symbol field, which contains tickers, must be present.
> > >
> > > I do realise that it is possible to supplement the ticker information with, for example, a SEDOL to get around this ambiguity, but the statement on page 7 has more implication than that. Systems are being developed that are ‘Fix 4.x’ compliant which only use the ‘required’ and ‘conditionally required’ fields. These do not contain SecurityID and IDSource so are difficult to implement outside North America.
> > >
> > > There are several ways forward to counter this problem. One would be to make Symbol an optional field for backwards compatibility and make SecurityID and IDSource required. Another would be to make all three fields required in future versions. A further solution may be to ‘flag’ certain fields as being required for ‘Fix 4.x International’ enabling FIX developers to certify that the minimum fields have been included to their protocol to enable easier implimentation in the international marketplace.
> > >
> > > Any further discussion would be gratefully received.
> > >
> > > Many thanks,
> > >
> > > Roger Pembery.
> > >
> >
>