Imported from previous forum
We are setting up a FIX 4.4 link with a brokerage firm, and we need to download a SecurityList [type ‘y’] message.
Our counterparty is implementing a nonstandard version of the SecurityList message, having another Text field (tag 58) at root level, i.e. outside the SecListGrp.
Therefore, our questions are:
-
Generally speaking, the usage of a tag in a group with the same tag into the container message is allowed/recommendable by fix standards?
-
Adding a standard tag (tag 58) in a standard message (type y) should not be allowed, because the new field should have a custom tag (> 10000). Is it right?
Many thanks in advance.
Luigi
Hmm…very interesting. As you know Tag 58 is within the component block and using it outside that at the root level of the Security List message is definitely not a good idea.
Maybe they have a legitimate business reason to do so and have just repurposed this field but as you are finding out deviating from the standard raises the cost of implementation.
By the way the custom tags are between 5000-9999 which are registered on the FPL website and the new range which does not require registartion is between 20000-39999 (usage to be agreed upon bilaterally between counterparties).
–Aditya Kapur
We are setting up a FIX 4.4 link with a brokerage firm, and we need to download a SecurityList [type ‘y’] message.
Our counterparty is implementing a nonstandard version of the SecurityList message, having another Text field (tag 58) at root level, i.e. outside the SecListGrp.
Therefore, our questions are:
Generally speaking, the usage of a tag in a group with the same tag into the container message is allowed/recommendable by fix standards?
Adding a standard tag (tag 58) in a standard message (type y) should not be allowed, because the new field should have a custom tag (> 10000). Is it right?
Many thanks in advance.
Luigi
FIX tag=value syntax does not permit a tag number to occur more than once in the message, i.e. tag 58 cannot occur a second time on the root level. A standard FIX parser should reject the message. Submitting a Gap Analysis would be the proper procedure to extend the FIX standard if there is a business requirement that is shared by a number of users. User-defined fields are available for very specific extensions and Aditya pointed out the valid ranges. If you use FIXML and not tag=value then you have to come up with your own abbreviation for the user-defined field. A FIXML abbreviation only needs to be unique within the same component of the message, i.e. in your case you could use “Txt” for both instances but your Rules of Engagement should not show “58 Text @Txt” twice but e.g. “20000 RootText @Txt” and “58 Text @Txt”.
Regards,
Hanno.
We are setting up a FIX 4.4 link with a brokerage firm, and we need to download a SecurityList [type ‘y’] message.
Our counterparty is implementing a nonstandard version of the SecurityList message, having another Text field (tag 58) at root level, i.e. outside the SecListGrp.
Therefore, our questions are:
Generally speaking, the usage of a tag in a group with the same tag into the container message is allowed/recommendable by fix standards?
Adding a standard tag (tag 58) in a standard message (type y) should not be allowed, because the new field should have a custom tag (> 10000). Is it right?
Many thanks in advance.
Luigi
Hmm – interesting tidbit about FIXML – thanks.
FIX tag=value syntax does not permit a tag number to occur more than once in the message, i.e. tag 58 cannot occur a second time on the root level. A standard FIX parser should reject the message. Submitting a Gap Analysis would be the proper procedure to extend the FIX standard if there is a business requirement that is shared by a number of users. User-defined fields are available for very specific extensions and Aditya pointed out the valid ranges. If you use FIXML and not tag=value then you have to come up with your own abbreviation for the user-defined field. A FIXML abbreviation only needs to be unique within the same component of the message, i.e. in your case you could use “Txt” for both instances but your Rules of Engagement should not show “58 Text @Txt” twice but e.g. “20000 RootText @Txt” and “58 Text @Txt”.
Regards,
Hanno.We are setting up a FIX 4.4 link with a brokerage firm, and we need to download a SecurityList [type ‘y’] message.
Our counterparty is implementing a nonstandard version of the SecurityList message, having another Text field (tag 58) at root level, i.e. outside the SecListGrp.
Therefore, our questions are:
Generally speaking, the usage of a tag in a group with the same tag into the container message is allowed/recommendable by fix standards?
Adding a standard tag (tag 58) in a standard message (type y) should not be allowed, because the new field should have a custom tag (> 10000). Is it right?
Many thanks in advance.
Luigi