[This message was posted by Ryan Pierce (FPL Technical Director) of FIX Protocol Ltd. <[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/94066a9f - PLEASE DO NOT REPLY BY MAIL.]
Hanno, that's a very interesting point. If one wishes to use OPRA/SIAC Participant ID codes and FPL does not create a new PartyIDSource and ExDestinationIDSource for them, my personal opinion is that "C = Generally accepted market participant identifier (e.g. NASD mnemonic)" would be inappropriate. The intent with "C" was to provide a means to identify brokers using whatever is the generally accepted standard, e.g. NASD mnemonics in the US. If one used C and indicated an OPRA/SIAC Participant ID, that would cause confusion. I would think OPRA/SIAC Participant IDs should either: 1. Be expressed using "D = Proprietary / Custom code" where such usage is agreed bilaterally, or 2. Be given their own PartyIDSource / ExDestinationIDSource enumeration, or 3. Be translated to ISO 10303 MICs, in which case one would use "G". Regarding extending PartyIDSource / ExDestinationIDSource, I think this goes beyond the scope of the Market Transparency proposal, as an additional PartyIDSource could affect a wide number of applications. I see arguments on both sides for this. On one hand, I think the values you mention map to MICs, so I'd question whether the additional complexity of allowing two formats benefits the FIX Protocol user community. And on the other hand, I also recognize that FIX allows many different ID sources for symbology, when mappings clearly exist, so a similar argument could be made for identifying exchanges. The big question in my mind is whether OPRA/SIAC Participant ID codes include the three FINRA "meta-values" as I'm calling them, e.g. Foreign exchange, Multiple venues, and Unknown venue. If so, I'd see this as a good argument for inclusion. It is uncertain whether these meta-values could be added to the ISO 10383 MIC standard, so use of them in the OPRA/SIAC Participant ID code standard could solve this problem. Also, ExDestinationIDSource brings up an interesting issue. Its enumerations are a subset of the values of PartyIDSource. Within the FIX Repository, we can't map that; ExDestinationIDSource simply duplicates the applicable values of PartyIDSource. I'm wondering if it would be possible to model this relationship. I believe ISO 20022 modeling has this kind of concept. [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.
