[This message was posted by Richard Labs of CL&B Capital Management, LLC <[email protected]> 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/905908df - PLEASE DO NOT REPLY BY MAIL.]
Jason, Thanks very much for the post! The WG has other requests for just that functionality so we are likely going to elevate looking at this. I want to strongly encourage you to stay with us on this and provide further input! We created the "indexing/categorization" set of attributes initially as a marketing concept. We wanted allow the buy side, when faced with a "shoebox" filled to the brim with various and sundry FIXatdl algos from a wide variety of sources, (including entities they had never done business with before) to have "hooks" attached to each strategy to allow browsing through that "pile" and presenting to traders sub sets that _might_ be relevant to their trading objective, right at the "purchasing moment". In the schema, we isolated the index entries for that marketing purpose thinking, "what if a BD gets aggressive and loose with their indexing" (i.e. the strategy works well in most of that region specified however there are several troublesome exceptions". We didn't want "looseness" in categorization/indexing/marketing area to leak into the much more tightly controlled "operations" end. There was much debate regarding how to index. With nowhere near universal agreement. Significant dissension. In the end the majority ruled. So, it's not an exceptionally tight spec in that area. The idea, back then was to keep use of the indexing entries isolated. We also, from the start, came up with the idea "don't allow/encourage" a single strategy to "morph" itself into a different strategy. The idea was each strategy was to accomplish a single trading technique (what you see is what you get). Lastly, a few years back when we did the original design, we found that BD's often had completely different data centers / computer set ups in different regions. Therefore a VWAP in North America, ran on a data center in that region, while the VWAP in EMEA ran on a wholly different data center in that region. Often times this set up was left over from M&A activity and still fairly loosely integrated. Although the VWAP (and other algo) names were the same (and marketing worldwide was consistent), and the algos were indeed similar, they were NOT 100% identical. (Often the underlying FIX messages were radically different. And routing might also be different.) Each strategy also had the potential to behave differently (for example different risks in use: near options/future expiration, same named parameter such as "aggression level" working radically different in different regions, different "got-ya's" such as around market open/close, holidays, circuit breaker interruptions, resets after interruptions, etc.). We also felt the written disclosure document would likely be wholly different for each region (if the underlying execution infrastructure was different). Back then we had the concept of one strategy, one disclosure document. KISS. We also have the one strategy, one FIX order type concept. That is, if the strategy results in a new order single, there is no way to "morph" that into a basket order. The OMS/EMS faces a daunting job of integrating across BD offerings if strategies are not granular and "atomic". If they morph (and each will morph in different ways), with some BDs offering 5 underlying strategies under a single name with morphing, while the next BD presents them as individual strategies, that makes the "selection" process exceptionally difficult. Some OMS's want to take all VWAP strategies from all its BDs and present each strategy to the trader with all the fields in identical position. That requires granularity Way, way down the road (perhaps 5+ years out) we also envisions "algos of algos" - that is the ability to build a higher level algo that presented a nice clean UI but in fact "under the hood" deployed multiple individual algos (even across BDs!) to execute its objectives. For that kind of "tinker toy" building of complex strategies to work the underlying algos at the base level really need generic interfaces. Just wanted to give some background. WG needs more input here - particularly to gauge 1. how urgent is this need to use indexing data in "operations", 2. will the loose "indexing" we now permit cause real trouble if it leaks into to operations, 3. where is the best place to "draw the line" on morphing strategies - AT THIS TIME? What allows the broadest FIXatdl deployment without causing too much implementation pain "downstream" from the FIXatdl file itself. Often we have to take "baby steps". (Particularly if there is "looseness") I'd strongly encourage others to weight in here! Please offer specific use cases if at all possible and clearly indicate how large the challenge is, how urgent the solution sought is. A simple change to FIXatdl (really just an ADDITION to the schema, no other structural changes or deletions) might be rolled in going from v1.1 -> v1.2. A complex change (altering anything now deployed in the marketplace would be v1.1 -> v2.0 and would take much longer (i.e. years) to go through a much more formal and rigorous release process. Looking for all input. Thanks again Jason for posting! [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.
