Getting the Right Fit : Buy-side, Sell-side and Vendor on Non-Standard ATDL Implementation

How to Get the Most From FIXatdl^SM : FPL Global Technical Committee
When traders do some minimal tweaking of the broker supplied FIXatdl^SM, often they are effectively extending the FIXatdl^SM to include certain proprietary OMS-required information. One elegant approach to this uses XML namespaces to extend the FIXatdl^SM by referencing the standard schema as a component in a larger schema that include the additional information. This means that the FIXatdl^SM remains completely compliant with the official schema, and any local customisation information can be carried alongside it.
While some industry participants have commented on the rapidly evolving nature of the specification, this is the trade off volunteers make when they are involved in the development of a standard. Effectively, they trade influence over the direction of a standard for the inconvenience of working with an evolving specification; however, since the release of  FIXatdl^SM v1.1, which is the stable, approved version, there have been no changes to the specification.

Deutsche Bank’s Boris Goykhman talks with FIXGlobal about how DB walks the line, trying to match different vendors’ FIXatdl^SM offerings to clients’ needs.
Boris Goykhman, Vice President, Product Development, Deutsche Bank
How do you evaluate a vendor’s FIXatdlSM offerings relative to other vendors or relative to your existing algorithmic products? Are you requiring / looking for them to stick to the ‘standard’?
The most important aspect of a vendor’s FIXatdl^SM offering is how closely they adhere to the FPL recognized FIXatdlSM 1.0 or 1.1 protocols. The purpose of ATDL was to define a protocol that would be widely adapted and supported uniformly throughout the OMS/EMS and Broker Dealer community. In order for a vendor to have a successful FIXatdl^SM offering, they must be able to support all data types, validations, control workflows, and GUI elements defined in the FIXatdl^SM protocol. The expectation is that they would be able to accept our Algorithmic Ticket ATDL file, and seamlessly load it into their environment. This serves as a minimum requirement for classifying a vendor as being FIXatdl^SM compliant. Additional features that a vendor may offer include Algo Ticket viewers, XML file editing environment, and an online repository for updating files.
Any vendor that does not adhere to the protocol is not classified as FIXatdl^SM compliant and we would not be able to leverage existing code. A number of vendors use proprietary XML based syntax for defining broker Algorithmic tickets. Working with these vendors requires a full implementation cycle to generate code that could not be leveraged for any other vendor.
How would you characterize your clients’ expectations regarding FIXatdlSM and algorithmic trading? Is it expected, appreciated, a competitive advantage?
Clients that use a vendor that is FIXatdl^SM compliant have a much better expectation of time-to-market for delivering our products to them. When utilizing an environment that allows the broker to make updates to their Algo ticket offering, the speed at which these changes can be reflected on the client’s machine is greatly increased. With FIXatdl^SM we could deliver changes to our clients within 1 week of the original request. This includes requirements gathering, implementation, testing, and upgrading. Without FIXatdl^SM, this process takes roughly 2 months.