From the buy-side perspective, how can a broker use FIXatdlSM algorithms to their advantage?
FIXatdlSM provides cost efficiencies in onboarding algos by dramatically reducing certification time. Algo providers can test their FIXatdlSM files before clients receive them, which dramatically reduces the likelihood of misspecification. Since the buy-side can process the FIXatdlSM file directly into their OMS, the potential error in translating spec documents into code is removed. Unforeseen misspecification, however, can still occur. If thisvhappens, a good implementation of FIXatdlSM will allow for on-the-fly adjustments. The buy side tester is empowered to correct mistakes during the process and continue the certification, rather than going through another round of Graphic User Interface (GUI )development. Nimble responses reduce the time period for certification from weeks to days, improving timeto-market. We have a long queue of algo requests, which allows the brokers that provide FIXatdlSM to enter our system more quickly. Another major benefit to FIXatdlSM is that it provides high-detail customization at a low cost, which empowers the algo sales team. With FIXatdlSM, the same algo can be set up with different defaults or custom dependency rules, according to the specific needs of the client. Vendors can also expose different optional fields to each client rather than the current ’one size fits all’ approach. This removes the need to have confusing generic placeholder fields (i.e. “Option 1”) that vendors use to avoid extra GUI development cycles.
The biggest win, though, is time-tomarket, as enhancements to algos can be seamlessly pushed to the clients. Depending on the amount of time needed to re-certify, new functionality can theoretically be made available within days, allowing for a heightened level of service.
What are the main issues you encounter when using FIXatdlSM algorithms, and how do you see them resolved?
A potential issue with FIXatdlSM is the strong focus on evolving the standard, without an equivalent effort to provide sufficient coding tools to facilitate adoption. The FPL Algorithmic Trading Working Group must make it easy for organizations to integrate and keep up with updates. One solution could be for the Working Group to produce Open Source software in multiple languages. A base level of functionality to render/test the screens, with hooks allowing for customization, would drastically reduce the burden of implementation for new entrants. Making the software backwards compatible would facilitate easier upgrades.
As the standard evolves, early adopters must consistently play catch-up. We started using FIXatdlSM a few years ago in its nascent stages. At that point, there were many gaps that we needed to fill with custom solutions and proprietary tags. The recent versions have addressed almost all of our needs and the functionality is now quite comprehensive. However, the recurring need to upgrade our infrastructure has slowed down our ability to incorporate newer versions.
From a technical perspective, there are two logical pieces of infrastructure that require updating with new versions.
- Parser: This code reads the XML and creates Data Objects that can be used programmatically. Our parser can process multiple versions of ATDL, which produces generic Data Objects that our application leverages to construct the GUI.
- GUI Generator: This code interprets the Data Objects and generates screens on the fly with appropriate layout, rules and validations. These screens are constructed to produce the FIX Tags to be sent by the EMS.
