Imported from previous forum
My observation would be that BrokerDealer acceptance of ATDL seems non-existant. Every major house I have spoken to recently has either not heard of it or will not make any committement to supporting.
The great enthusiasm of 12-18 months ago has obviously been battered and the brokers seem happy enough with the status-quo (with the OMS/EMS community maintaining the support)
Where will the driver for adoption come from in this case? It has to, as I have found be Broker led. It seems there is little appetite for this.
My experience with ATDL acceptance is a bit different. There are pockets of support developing for ATDL.
I have recently interfaced to Lime Brokerage who uses ATDL for their also service providers. In addition, some developers at large institutions are using ATDL internally to describe their sell side broker’s algo tags. That is, they are creating ATDL that in the future, the algo providers themselves will one day likely provide.
I think this is a normal evolution and reminds me of the adoption of FIX in the 90’s.
Regards, Greg.
My observation would be that BrokerDealer acceptance of ATDL seems non-
existant. Every major house I have spoken to recently has either not
heard of it or will not make any committement to supporting.The great enthusiasm of 12-18 months ago has obviously been battered and
the brokers seem happy enough with the status-quo (with the OMS/EMS
community maintaining the support)Where will the driver for adoption come from in this case? It has to, as
I have found be Broker led. It seems there is little appetite for this.
Matt,
FIXatdl is very much alive and moving forward. There admittedly been some slowing because of the market crash and broker/dealer merger into banks. Likewise there have large reductions in IT staff with most houses going into the mode of “cut ALL IT development, reduce all IT staff to the bare bones to just support existing applications”.
On the other end of this has been a natural shift in emphasis within the Work Group from BD emphasis (FIXatdl xml file production) to OMS emphasis (consume a variety of xml files, parse them, and make them all usable within the tier-1 OMS systems). While producing FIXatdl xml files only involves about a developer day learning the standard, and perhaps 2-4 hours per strategy after that to write error free xml, the one-time effort of OMS makers to come up to speed, develop and install parsers, and modify their production systems to incorporate FIXatdl files is much more resource intense. Knowing full well this is the case, after rallying 17 BDs to produce FIXatdl xml files, the WG totally shifted its very limited internal resources to working with selected tier-1 OMS providers to resolve all issues on that end (consumption of the xml) of the delivery chain.
While we thought we really knew what we were doing after getting BDs to produce xml files, we have found the issues on the OMS side to be at least an order of magnitude more involved than we first expected. As they say, the devil is in the details… Thankfully however, prior to the market crash, we were well on our way with all that and had completed >90% of that OMS “punch list” with a very high degree of confidence that it met their virtually all their industry-wide needs. However, as you correctly have observed, with our WG spending all our (highly limited) resources on the OMS side, the BD’s haven’t been contacted in so long they have all but forgotten about us. There is no buzz at the BD’s because we have largely totally ignored them though this phase.
I can assure you however that the core group of BDs producing algos remain very much aware of FIXatl at the R&D level, and are very well positioned for the WG to get things settled on the OMS end. As I mentioned before, BD support is NOT difficult to rally. We have done that before with near 100% market participation, and will do that again when we are “done” with the rest of this. If there is anything we have learned during the first 24 months of this is that the bulge bracket BDs can move exceptionally quickly to exploit any perceived market opportunities. So, getting algo executing BDs to produce FIXatdl files will not be a hold up.
In looking at the detailed use-cases on hundreds of actual algos and perhaps a dozen or so OMS systems in depth, plus reviewing some of FIXs longer range (3-5 year) technical plans we opted over the past several months to refactor the FIXatdl standard to absolutely isolate the GUI area from the “data contract” area - i.e. the data on the FIX wire (which, btw, is exactly the same as its always been so FIXatdl adoption requires zero FIX infrastructure change). Due to very scant WG resources, that last refactoring took a bit longer than expected and is now publicly exposed at http://fixprotocol.org/FIXatdl
Our major constraint now REMAINS very limited WG resources working through the final stages of delivery on what will be FIXatdl v1.1 We have some “punch list” items left to go and all the documentation needs to be brought up to date. With XMLspy, current users can generate about 277 pages of documentation and get a very solid picture of things. However, it would be very useful for the WG to better elaborate on all the various features and how to use them. At FIX we are held up from submitting the V1.1 draft standard for final approval until we have that documentation finished in pristine publishable form. Right now we have to rally resources to that effort.
We are operating with greatly reduced WG resources. Its like a neutron bomb went off and took out 20-40% of the IT bodies in our member organizations and the bodies remaing are working 24/7/365 to keep exsiting applications runing. Time to volunteer to the WG is very limited, so we are moving much more slowly than when things were “flush”.
What we really need are MORE voluntary final QA testers and documentation writers to speed up the delivery process. That is the only thing holding up FIXatdl at this point. Technically, we are on the one yard line. Best of all we have a nucleus of very active tier-1 OMS support so just as soon as this thing goes final we are not anticipating ANY problem getting the BDs to pump out xml files.
Rick
Rick,
Many thanks for this update. This is truly what I was after, there is life out there!
I have been getting increasingly despondent over recent months trailing round the brokers and getting little or no interest in ATDL and no idea on the direction. All the while they are pushing out many changes to their current Algo suites.
thinkFolio is a predominately UK/Europe based OMS with about 1500 users, we are delibrately a light weight OMS and only develop for and take money from our client community for the rental of our product. Hence I am very keen in any commodity technology that cuts down cost and time to market.
My only other point in your comments below is that I do think it will be harder now to rouse the BD community when as you say so many people have been dropped certainly from a European perspective the Brokers seem fairly comfortable with the status quo.
I do hope to be proved wrong!
Many thanks,
Matt
Matt,
FIXatdl is very much alive and moving forward. There admittedly been
some slowing because of the market crash and broker/dealer merger into
banks. Likewise there have large reductions in IT staff with most houses
going into the mode of “cut ALL IT development, reduce all IT staff to
the bare bones to just support existing applications”.On the other end of this has been a natural shift in emphasis within the
Work Group from BD emphasis (FIXatdl xml file production) to OMS
emphasis (consume a variety of xml files, parse them, and make them all
usable within the tier-1 OMS systems). While producing FIXatdl xml files
only involves about a developer day learning the standard, and perhaps
2-4 hours per strategy after that to write error free xml, the one-time
effort of OMS makers to come up to speed, develop and install parsers,
and modify their production systems to incorporate FIXatdl files is much
more resource intense. Knowing full well this is the case, after
rallying 17 BDs to produce FIXatdl xml files, the WG totally shifted its
very limited internal resources to working with selected tier-1 OMS
providers to resolve all issues on that end (consumption of the xml) of
the delivery chain.While we thought we really knew what we were doing after getting BDs to
produce xml files, we have found the issues on the OMS side to be at
least an order of magnitude more involved than we first expected. As
they say, the devil is in the details… Thankfully however, prior to
the market crash, we were well on our way with all that and had
completed >90% of that OMS “punch list” with a very high degree of
confidence that it met their virtually all their industry-wide needs.
However, as you correctly have observed, with our WG spending all our
(highly limited) resources on the OMS side, the BD’s haven’t been
contacted in so long they have all but forgotten about us. There is no
buzz at the BD’s because we have largely totally ignored them though
this phase.I can assure you however that the core group of BDs producing algos
remain very much aware of FIXatl at the R&D level, and are very well
positioned for the WG to get things settled on the OMS end. As I
mentioned before, BD support is NOT difficult to rally. We have done
that before with near 100% market participation, and will do that again
when we are “done” with the rest of this. If there is anything we have
learned during the first 24 months of this is that the bulge bracket BDs
can move exceptionally quickly to exploit any perceived market
opportunities. So, getting algo executing BDs to produce FIXatdl files
will not be a hold up.In looking at the detailed use-cases on hundreds of actual algos and
perhaps a dozen or so OMS systems in depth, plus reviewing some of FIXs
longer range (3-5 year) technical plans we opted over the past several
months to refactor the FIXatdl standard to absolutely isolate the GUI
area from the “data contract” area - i.e. the data on the FIX wire
(which, btw, is exactly the same as its always been so FIXatdl adoption
requires zero FIX infrastructure change). Due to very scant WG
resources, that last refactoring took a bit longer than expected and is
now publicly exposed at http://fixprotocol.org/FIXatdlOur major constraint now REMAINS very limited WG resources working
through the final stages of delivery on what will be FIXatdl v1.1 We
have some “punch list” items left to go and all the documentation needs
to be brought up to date. With XMLspy, current users can generate about
277 pages of documentation and get a very solid picture of things.
However, it would be very useful for the WG to better elaborate on all
the various features and how to use them. At FIX we are held up from
submitting the V1.1 draft standard for final approval until we have that
documentation finished in pristine publishable form. Right now we have
to rally resources to that effort.We are operating with greatly reduced WG resources. Its like a
neutron bomb went off and took out 20-40% of the IT bodies in our
member organizations and the bodies remaing are working 24/7/365 to
keep exsiting applications runing. Time to volunteer to the WG is
very limited, so we are moving much more slowly than when things
were “flush”.What we really need are MORE voluntary final QA testers and
documentation writers to speed up the delivery process. That is the only
thing holding up FIXatdl at this point. Technically, we are on the one
yard line. Best of all we have a nucleus of very active tier-1 OMS
support so just as soon as this thing goes final we are not anticipating
ANY problem getting the BDs to pump out xml files.Rick
[ original email was from Emma Sullivan - emma.sullivan@patsystems.com ]
Hi Matt,
Many thanks for this update. This is truly what I was after, there is
life out there!
There is life out there!
We have created flexible order tickets using FIXatdl and are currently enhancing our products so that brokers can write their own algoritms and quickly and flexibly change how the front-end is displayed using FIXatdl.
I am particularly interested in keeping up with any enhancements to ensure that we do not fall behind! :o)
Emma
[ original email was from jim whitehead - jwhitehead@latentzero.com ]
> My observation would be that BrokerDealer acceptance of ATDL seems non-
existant. Every major house I have spoken to recently has either not
heard of it or will not make any committement to supporting.The great enthusiasm of 12-18 months ago has obviously been battered and
the brokers seem happy enough with the status-quo (with the OMS/EMS
community maintaining the support)Where will the driver for adoption come from in this case? It has to, as
I have found be Broker led. It seems there is little appetite for this.
I think it would be a decent idea to have more visibility into which brokers can ship their algo files in an ADTL format, its probably come up before but what I’d quite like is an enhancement to the http://www.fixprotocol.org/adopters/ page (or something similar) showing who supports ADTL