Imported from previous forum
Hello,
My question is w.r.t. the usage of security details related fields in various business messages viz. New Order Single, Order Cancel/Replace Request, Execution Report etc.
In these messages, SecurityId tag (Tag 48) defines the uniqueness of Security for which a transaction is initiated or reponded.
FIX also allows mentioning security details via fields like Symbol (Tag 55), SymbolSfx (Tag 65), Security Type (Tag 167), MaturityMonthYear (Tag 200), MaturityDay (Tag 205), Strike Price (Tag 202), PutOrCall (Tag 201) and OptAttribute (Tag 206).
If these details can be made available by Security Definition Information and both Buy Side and Sell Side have full information about the security details with the use of SecurityId (Tag 48), can both side work with Tag 48 and do away with the sending of all other security related fields mentioned above?
Hi Parag,
Typically, the information specified in Tag 48 depends on the kind of security identification you choose (Tag 22) i.e. RIC, ISIN, Exchange specific identifier. In many cases, this information (Tag 48) is sufficient to uniquely identify a contract. In the situation that you mention, where the client and server both have a security download from the same source, the value of tag48 should definitely be sufficient.
However, in an environment where ISINs, RICs and Exchange specific codes are not available, one would expect that despite having a security download from the same source, the client and server would rely on tags 55, 65, 167, 200, 205, etc.
Specifically in FIX 4.2, since CFI Code is not part of the FIX Spec, it would be recommended to send all available security information.
Beyond FIX 4.2, i.e. 4.3 upwards, one could rely on the CFI Code to identify the instrument and its type.
Kind Regards,
Prateek Jain
Certainly, this is becoming common practice for exchanges/MTFs where performance is key. Tag 22 SecurityIDSource is conditionally required when using tag 48. This is debatable if you only ever use one source, e.g. ISINs, but some FIX engines might reject messages if tag 48 comes without tag 22.
In the derivatives area, the source of the IDs is often M=“Marketplace assigned identifier”, i.e. a synthetic number which does not change over the lifetime of the contract.
In any case it makes sense for environments such as exchanges/MTFs to issue instrument reference data with FIX over FAST via multicast (or also through the FIX engine) and only have an identifier in the order handling messages.
The component block is part of almost all FIX application messages but this does not mean that you should use an explicit description of an instrument in all cases. You could use shotcuts in all but one message type which is provided to order submitters upfront to let them build up a mapping table.
Hello,
My question is w.r.t. the usage of security details related fields in various business messages viz. New Order Single, Order Cancel/Replace Request, Execution Report etc.In these messages, SecurityId tag (Tag 48) defines the uniqueness of Security for which a transaction is initiated or reponded.
FIX also allows mentioning security details via fields like Symbol (Tag 55), SymbolSfx (Tag 65), Security Type (Tag 167), MaturityMonthYear (Tag 200), MaturityDay (Tag 205), Strike Price (Tag 202), PutOrCall (Tag 201) and OptAttribute (Tag 206).
If these details can be made available by Security Definition Information and both Buy Side and Sell Side have full information about the security details with the use of SecurityId (Tag 48), can both side work with Tag 48 and do away with the sending of all other security related fields mentioned above?