Imported from previous forum
[ original email was from Bernt Sanden - bernt.sanden@omgroup.com ]
Hi,
I have understood that the symbol field is not enough to identify options and futures in the FIX protocol. Options, for ecample require SecurityType=”OPT”, Symbol, MaturityMonthDate, PutOrCall, and StrikePrice.
In our OMS system, however, each security (even futures and options) is fully identified via the Symbol field. Our Symbol field contains Underlying security, putorcall, strikeprice, year and month of maturity)
So my questions is:
Can i skip all additional fields (except for the symbol) used for identification of options and futures in all FIX messages were the Symbol field is used? Do i abuse the FIX spec in this case?
Actually i want to reject messages that contain additional identification fields. Is this strategy ok?
Regards, Bernt Sandén
[ original email was from Koorosh Alahiari - alahiari.koorosh@msdw.com ]
> Hi,
>
> I have understood that the symbol field is not enough to identify options and futures in the FIX protocol. Options, for ecample require SecurityType=”OPT”, Symbol, MaturityMonthDate, PutOrCall, and StrikePrice.
>
> In our OMS system, however, each security (even futures and options) is fully identified via the Symbol field. Our Symbol field contains Underlying security, putorcall, strikeprice, year and month of maturity)
>
> So my questions is:
>
> Can i skip all additional fields (except for the symbol) used for identification of options and futures in all FIX messages were the Symbol field is used? Do i abuse the FIX spec in this case?
>
> Actually i want to reject messages that contain additional identification fields. Is this strategy ok?
>
>
> Regards, Bernt Sandén
>
>
> From my experience it would be easier to retreive the details of an option contract given a "trade symbol" if your FIX engine has access to some sort of database in order to pull out the contract specification.
However, if you try to decipher the symbol in order to work out the Option type, strike, etc…, you may find that you will have to have prior knowledge of how the symbol is encoded.
In my view, the proper way to do this is to populate the relevant fix fields.
In any case why would you want to reject the message when you could simply choose to ignore them!
regards,
Koorosh Alahiari
7c Information systems
[ original email was from Jim Northey - jnorthey@lasalletech.com ]
Her at the CBOE, we permit two approaches for identification of derivatives within our system. The first is fully qualified using:
Symbol (Reqd)
SecurityType (Reqd)
MaturityMonthYear (Reqd)
MaturityDay (Optional - due to standardized contract specifications in US listed markets)
PutOrCall (Required)
StrikePrice (Required)
SecurityExchange (Optional - as this information is consistent across US listed markets)
The other approach we permit is the use of our internal productkey in the SecurityID field:
Symbol (Required)
SecurityID (Required)
IDSource=8[Exchange]
SecurityType (Optional)
The productkey(SecurityID), an integer value, identifies the product and the type of product. This information is available from CBOE via using Security Definition Request / Security Definition messages - thus providing a mechanism for communicating the exchange symbol, security identification information to the counterparty.
I think it best that if you are not providing a database (as recommended in the previous e-mail from Koorosh Alahiari) of symbol identifiers to contract specification then you should fully populate the contract specifications. What we try to avoid is requiring users to perform sub-parsing on a field (such as symbol) to extract information that is already defined in other tags. The subparsing of tags reduces the value of the FIX protocol - in that we all end up deploying extra resources to write lower level code (I understand there are times when this guideline has to be broken because of older systems).
Also, keep in mind your users. My view is that with the retail, brokerage business - the closer to the actual customer the message originates the more likely you should use the FIX standard fields and not internal fields:
Symbol
SecurityType
MaturityMonthYear (Reqd)
MaturityDay (Optional)
PutOrCall (Required)
StrikePrice (Required)
SecurityExchange (Optional)
The closer you get to the internal market participants (market makers for instance) the more likely their systems are suited for encoded symbol information and can benefit from reduced message size. However, any time encoding is done - parsing should not be required and you should provide Symbol / SecurityID standing data via the Security Definition messages.
If you need further help or would like to ensure that your implementation follows an approach consistent with the overall FIX community - I strongly encourage you to participate in the Futures and Options Working Group. We will be starting up again shortly - continuing to adress usage of 4.2 for derivatives probably in February.
Hope this helps. Good luck.
[ original email was from Bernt Sanden - bernt.sanden@omgroup.com ]
> Her at the CBOE, we permit two approaches for identification of derivatives within our system. The first is fully qualified using:
>
> Symbol (Reqd)
> SecurityType (Reqd)
> MaturityMonthYear (Reqd)
> MaturityDay (Optional - due to standardized contract specifications in US listed markets)
> PutOrCall (Required)
> StrikePrice (Required)
> SecurityExchange (Optional - as this information is consistent across US listed markets)
>
> The other approach we permit is the use of our internal productkey in the SecurityID field:
>
> Symbol (Required)
> SecurityID (Required)
> IDSource=8[Exchange]
> SecurityType (Optional)
>
> The productkey(SecurityID), an integer value, identifies the product and the type of product. This information is available from CBOE via using Security Definition Request / Security Definition messages - thus providing a mechanism for communicating the exchange symbol, security identification information to the counterparty.
>
> I think it best that if you are not providing a database (as recommended in the previous e-mail from Koorosh Alahiari) of symbol identifiers to contract specification then you should fully populate the contract specifications. What we try to avoid is requiring users to perform sub-parsing on a field (such as symbol) to extract information that is already defined in other tags. The subparsing of tags reduces the value of the FIX protocol - in that we all end up deploying extra resources to write lower level code (I understand there are times when this guideline has to be broken because of older systems).
>
> Also, keep in mind your users. My view is that with the retail, brokerage business - the closer to the actual customer the message originates the more likely you should use the FIX standard fields and not internal fields:
>
> Symbol
> SecurityType
> MaturityMonthYear (Reqd)
> MaturityDay (Optional)
> PutOrCall (Required)
> StrikePrice (Required)
> SecurityExchange (Optional)
>
> The closer you get to the internal market participants (market makers for instance) the more likely their systems are suited for encoded symbol information and can benefit from reduced message size. However, any time encoding is done - parsing should not be required and you should provide Symbol / SecurityID standing data via the Security Definition messages.
>
> If you need further help or would like to ensure that your implementation follows an approach consistent with the overall FIX community - I strongly encourage you to participate in the Futures and Options Working Group. We will be starting up again shortly - continuing to adress usage of 4.2 for derivatives probably in February.
>
> Hope this helps. Good luck.
>
>
What does the Symbol field represent in the case of options and futures? Is it the underlying security? Anything else?
Regards, Bernt Sandén
[ original email was from Jim Northey - jnorthey@lasalletech.com ]
In our case (listed options) and in the general case the symbol field should correspond to the ticker symbol (or a derivation thereof) of the underlying security. For instance, IBM options in the US have symbols, such as (IBM, IBZ, WIB, VIB).
CBOT, CME Futures use one or two letter symbol (SP - S&P Futures, ED - Eurodollars, ) - a third letter is and encoding for month and year (yes, if the MaturityMonthYear is not provided - then there needs to be a sub-parsing and lookup to determine month / year).
>
> What does the Symbol field represent in the case of options and futures? Is it the underlying security? Anything else?
>
> Regards, Bernt Sandén
>
I have a problem with the SecurityExchange field for Orders for LIFFE.
Liffe is effectively divided into 3 exchanges, Financials/Commodities and Equity Options on two physical Hosts. - but only one Exchange code is given for LIFFE in Appendix C Vol 6 of the manual. This causes problems because Different products share the same Symbol e.g. 'C ’ can be Cocoa or Euro (LIBOR) the ExchangeCode (L or X) makes them unique.
I can use SecurityID/ID source OK but I also want to support the standard way of specifing a contract.
My solution would be to prefix the LIFFE exchange code to the Symbol e.g. LC and XC but am worried that no standards have been adopted to cope.
Anybody have any thoughts/solutions to this one.
I personally think that REUTERS should have 3 codes for LIFFE (Financials/Equities/Commodities)
Use TradingSessionID to designate the "divided entity/system".
> I have a problem with the SecurityExchange field for Orders for LIFFE.
>
> Liffe is effectively divided into 3 exchanges, Financials/Commodities and Equity Options on two physical Hosts. - but only one Exchange code is given for LIFFE in Appendix C Vol 6 of the manual. This causes problems because Different products share the same Symbol e.g. 'C ’ can be Cocoa or Euro (LIBOR) the ExchangeCode (L or X) makes them unique.
> I can use SecurityID/ID source OK but I also want to support the standard way of specifing a contract.
> My solution would be to prefix the LIFFE exchange code to the Symbol e.g. LC and XC but am worried that no standards have been adopted to cope.
> Anybody have any thoughts/solutions to this one.
> I personally think that REUTERS should have 3 codes for LIFFE (Financials/Equities/Commodities)
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> Use TradingSessionID to designate the "divided entity/system".
Another alternate approach could be to use the FIX 4.3 MIC codes instead of Reuters codes.
My understanding is that, like a BIC code, the first part of the MIC code defines the firm, and certain parts of the MIC code are reserved for branches or divisions within a firm. LIFFE could provide distinct MIC codes for each of the three systems you mention.
[ original email was from Francesc Prats - fprats@meff.com ]
Another possibility coould be to use TargetSubID. For messages going to an
exchange, TargetCompID identifies the exchange, so TargetSubID could be
considered as different divisions of that exchange.
> > Use TradingSessionID to designate the "divided entity/system".
>
> Another alternate approach could be to use the FIX 4.3 MIC codes instead of Reuters codes.
>
> My understanding is that, like a BIC code, the first part of the MIC code defines the firm, and certain parts of the MIC code are reserved for branches or divisions within a firm. LIFFE could provide distinct MIC codes for each of the three systems you mention.
>
>