[This message was posted by John Cameron of Cameron Edge <[email protected]> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/20714b08 - PLEASE DO NOT REPLY BY MAIL.]
I agree that we don't want to be parsing values of fields like CFICode. However, I still think that CFICode is worth keeping simply because it has a logical convention for assigning values to it, rather than just making up values as we need them. For example the SecurityType value for options on futures is OOF. CFICode would use OXXFXX. It would seem better to me to choose values that adhered to an existing standard. Note that I think we can and should still have clearly defined separate fields which specify call/put, underlying asset type etc. SecuritySubType is just an unstructured String which can contain anything which I think will become a problem in future. I am sure that there a lots of people who know more about this than I do and have thought about it a lot more than I have. But it does seem odd to be reverting on this previous decision to adopt a standard with CFICode. Maybe there is a good compromise position - use CFICode standard values but do not require the values to be parsed. Instead add the specialized fields, like PutOrCall as needed. > As of FIX 4.4 we have tag SecuritySubType (762) to further qualify the > type of security. It is tough to keep the entire text of the spec up to > date and comments pointing out such inconsistencies are welcome. > > The CFI Code has the disadvantage that it needs to be parsed. Processing > is easier (and probably faster) if one has explicit fields. For that > reason PutOrCall was reintroduced. > > For FIX versions below 4.4, CFICode (461) is probably the best way to go > (only if SecurityType is insuffcient) unless you can pull in tags from > higher versions. With FIX 4.4 and above I would opt for SecurityType > (167) and SecuritySubType (762). > > > There is a relevant discussion on this at > > http://www.fixprotocol.org/discuss/read/19f5aae5 > > > > However, one issue that does not seem to be addressed is how do you > > specify that the underlying of the derivative is an interest rate > > rather than anything else? > > > > CFICode(461) addresses this issue (but it was only introduced in > > FIX4.3). For example, the code for a call option on interest rates > > would be OCXDXX. The O indicates option, the C indicates call and the > > D indicates interest rate. Similarly, a call option on an index would > > be OCXIXX. A call option on a stock would be OCXSXX. See appendix D of > > Volume 6 of the spec. > > > > In his typically thorough response in the link quoted above, Jim > > Northey notes that "We have however, moved away from the use of > > CFICode for identification of derivatives". However, the latest spec > > still says in Appendix 6D "It is recommended that CFICode be used > > instead of SecurityType for non-Fixed Income instruments". > > > > It seems to me that without CFICode we do not have a means of > > indentifying the type of the underlying associated with a derivative > > instrument - which appears to be important to Sachin in his question. > > > > > > > > In FIX 4.2, a combination of Tag 55 (Symbol), Tag 48 (Security ID) > > > and Tag 167 (SecurityType), Tag 200 (MaturityMonthYear) will > > > identify the derivative instrument. For Options, additionally, Tag > > > 201 (PutOrCall) & Tag 202 (StrikePrice) would be required. > > > > > > Regards, Bivas > > > > > > > How will I differentiate instrument name as FUTSTK, FUTIDX, > > > > FUTINT. As the buy side will request tag# 167 = FUT. > > > > > > > > Thanks. Sachin. > > > > > > > > > I Think the values 'FUT', 'OPT' can be used for Exchange Traded > > > > > Derivatives like Interest Rate Futures/Options. > > > > > > > > > > Regards, Bivas > > > > > > > > > > > In FIX 4.2, which value should be used in tag# 167 for > > > > > > interest rate derivatives w.r.t. Indian Derivatives Market? > > > > > > > > > > > > Thanks in advance. Sachin. [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en -~----------~----~----~----~------~----~------~--~---
