Imported from previous forum
I’d like to propose that the current spec be enhanced to allow region specific controls within the strategy layout itself. Currently you are limited to either copying an existing strategy and making it into a separate region specific strategy with the appropriate control differences or to create region combos within a single strategy to hide/show/enable/disable controls for a region.
This seems fairly inefficient to me and causes overload for the trader using your interface which ultimately leads to frustration and less order flow. If the Region and Country identifiers could be added to each parameter/control, you could condense your offering and harmonize many strategies across regions with the minor differences that may exist (auction controls for example).
Being a trader myself, I understand the frustration associated with looking at a unnecessarily long list of strategies to choose from and the desire to keep things as compact as possible.
Thoughts?
I’d like to propose that the current spec be enhanced to allow region specific controls within the strategy layout itself. Currently you are limited to either copying an existing strategy and making it into a separate region specific strategy with the appropriate control differences or to create region combos within a single strategy to hide/show/enable/disable controls for a region.
This seems fairly inefficient to me and causes overload for the trader using your interface which ultimately leads to frustration and less order flow. If the Region and Country identifiers could be added to each parameter/control, you could condense your offering and harmonize many strategies across regions with the minor differences that may exist (auction controls for example).
Being a trader myself, I understand the frustration associated with looking at a unnecessarily long list of strategies to choose from and the desire to keep things as compact as possible.
Thoughts?
I had recently suggesting adding such region/country/security type/market filtering capability (the same as Strategy) to StrategyPanel (vs. your suggestion of to individual controls). I think that might be easier to implement, plus it would allow one to control the applicability of a set of controls with one filter expression. You could always wrap individual controls with their own StrategyPanel.
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!
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.
Two use cases surrounding Jason’s suggestion:
-
It is common for an algo provider to provide the same suite of algos across all markets, however, it is also common for a specific market to have its own feature (eg Auction features germane to one region). Although, a separate Strategy ‘keeps it clean’, there is a lot of duplication and maintenance.
-
FIXatdl 1.1 works really well in terms of strategy filtering for a single order, however, if you select a set of orders on your blotter and place them with an algo provider displaying and ‘filling in’ the algo screen once, it does not work so well. To clarify, in this case 20 New Order Singles are generated, each of them independent (not a basket or program) of one another, and each are populated with the same algo settings. In this case, having 3 (or more) VWAP (or TWAP, etc) Strategy definitions, each with their own Regional filtering, becomes a problem if the trader’s set of orders represents more than one region (eg assigning US ADRs, Canadian orders, and European orders at 10am ET). In this case, you can effectively “filter all of the strategies out”. We have had to build ‘awareness’ into our OMS of how a specific broker has ‘segmented’ their file and prevent our trader from ‘mixing’ orders across those boundaries. If the FIXatdl file had a single VWAP strategy definition and the one small, region-specific feature was controlled via Jason or my suggestion, then it might only be the region-specific feature/control that would be 'filtered out.