[This message was posted by Scott Atwell of American Century Investments <scott_atw...@americancentury.com> to the "Algorithmic Trading" discussion forum at http://fixprotocol.org/discuss/31. You can reply to it on-line at http://fixprotocol.org/discuss/read/c83831aa - PLEASE DO NOT REPLY BY MAIL.]
My take is that this discussion thread is making the case more complex than it necessarily needs to be, and is likely overlooking the role of Strategy/@name. 1) To clarify, the providerID simply refers to the firm (not the strategy, not the Asian vs. other desk of the firm) providing a suite of algo strategies. Thus the universe of these values will be quite small and relatively static. I also think that the likelihood of name collisions is relatively low. 2) If we did ask FPL to maintain a catalog of providerID values, I don't think the maintenance effort to do so would be that significant. In addition, there may be some benefit to the promotion and adoption of FIXatdl as it could help illustrate the broad universe of algo firms who have registered their id and are adopting FIXatdl. 3) An OMS/EMS integrating FIXatdl files from numerous algo providers will most likely be "receiving" the files individually from each algo provider, and these files will continually be updated and re-received individually. Thus, the OMS/EMS would need to determine what 'process' they will use to extract the content from algo provider X's file into their master (as there is only one <Strategies> element). If, there was a case of provider X and provider Y happened to use the same id, the OMS/EMS integration step could easily do a search/replace at that time. 4) To be very clear, Strategy/@providerID is not part of any 'uniqueness' rule (it is not Strategy/@providerID + Strategy/@name that makes each Strategy in the file unique), rather Strategy/@name is solely the only attribute that makes each Strategy unique. From the schema for Strategy/@name: "Uniquely identifies the strategy or algorithm." 5) Given #4 and the proposed approach of integrating multiple algo provider's FIXatdl files into a single file, I believe the much bigger challenge will be to ensure Strategy/@name unqiueness within the file. I guarantee you that you will have many "VWAP", "TWAP", "IS", etc. or "VWAP_EU", "VWAP_AS", "VWAP_NA", etc.) entries for Strategy/@name as a result. Thus, I would think that that OMS/EMS integration of a new provider's file would need to 'handle' that, perhaps by pre-pending, at the point of file integration, a string (could be Strategy/@providerID) representing that algo provider to the front of each of their Strategy/@name attributes before incorporating them within the OMS/EMS' master file. I, personally, manage and load one-file per algo provider, and given that I know which algo provider I'm assigning an order to, use/load that provider's file when rendering the screen. This makes it easy to do source code revision control for each provider's file (to see differences with latest file vs. pre-existing one) and simply replace the provider's previous file with their latest file. This does require configuration data to associate each provider with the specific file to use. Though, I do see the other use case of wanting a single, master file to use. Bottom line is that I don't think this is that big of a problem. If we think it would be beneficial for a registry of Strategy/@providerID values representing the algo providers who are adopting FIXatdl, then I would support FPL maintaining such a list on the FIX website. I think the much bigger challenge when looking at incorporating algo suites from multiple providers into a single file is Strategy/@name (and forcing uniquness for that is not something I think we should be trying to solve). [You can unsubscribe from this discussion group by sending a message to mailto:unsubscribe+100932...@fixprotocol.org] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to fix-proto...@googlegroups.com. To unsubscribe from this group, send email to fix-protocol+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
