FIXatdl: The New Frontier
By Greg Malatestinic, Co-Chair, FIX Algorithmic Trading Working Group (FIXatdl), FIX Trading Community and Jordan & Jordan and Richard Labs, CPA, CFA, Co-Chair, FIX Algorithmic Trading Working Group (FIXatdl), FIX Trading Community and CL&B Capital Management LLC.
It’s been more than ten years since FIXatdl™ had its last upgrade. FIXatdl version 1.1 (released in 2010), achieved its main objective: standardizing the specification of algorithmic order types into a machine-readable XML format. Its scope covers pre-trade analytics, order build workflow, local validation, and finally, submission of a FIX message over the wire. That was a large area to cover in such an early version of a standard. Version 1.0 addressed the needs of algo providers, but it wasn’t until version 1.1, when several OMS/EMS providers were brought on board and started coding against v1.0, that things really took off.
Today, with version 1.1 deployed widely, algo suites, written in FIXatdl from more than a dozen broker-dealers, integrate quickly and easily into several different OMS/EMS systems, with minimal effort. Code-test-and-deploy cycles are nearly eliminated and brokers can get their latest algorithms in front of their clients in shorter timeframes. Now algo providers can innovate faster, OMS/EMS vendors can deploy those algos very quickly, and traders can concentrate on using the new strategies. Indeed, version 1.1 has had great success and has survived a full decade in the field without an upgrade. Now it’s time for version 1.2 to ship, and perhaps time to start concept work on a possible version 2.0.
Introducing FIXatdl v1.2
Soon to be delivered, version 1.2 will greatly expand usability features against those original design objectives without disturbing the structure and design philosophy of what is already in widespread use today. The on ramp for version 1.2 is specifically designed to be high speed, high reward, and bracing, all while being relatively painless. The enhancements and new features of this release include:
Grid Alignment of GUI Controls – The layout of GUI controls (the elements of a graphical user interface such as check boxes, drop-down lists and radio buttons), is a key feature of FIXatdl. Most often the controls are included in panels, which are nested into other panels and applied with vertical and horizontal alignments to achieve the desired layout. While this works well for a small number of controls, things get complicated when their numbers are large – the XML gets rather ugly and hard to read. So, a grid alignment has been added where each control is assigned to a specific row and column. This is more intuitive and less prone to error.
Enhanced Filtering – Typically some of the parameters to algorithmic order types may be applicable only in certain regions. For example, an “aggression” parameter may be applicable in the US but not in EMEA. To differentiate between the regions, one must create two separate and distinct FIXatdl definitions each with a filter statement to indicate where it was applicable. So, to simplify matters, FIXatdl v1.2 has expanded its filtering capabilities which can now be applied to parameters and GUI controls. Now one strategy definition can be used for a cross-regional strategy rather than one for each region.
Support for Multi-leg orders – Though FIXatdl v1.1 includes features to support for multi-leg order entry, it lacks the clarity and guidance necessary to make them useful. It is also apparent that, from a lack of input during the design phase, some use cases were not considered. As a result, few broker-dealers have attempted to describe their highly unique multi-leg orders with FIXatdl. So, version 1.2 provides more robust support for multi-leg order types and clarifies how their interfaces are to be described. Sample code is included in the release which highlights several use cases, such as pairs and basket strategies, and gives guidance on best-practices.
Other enhancements, which are intended to make the XML less verbose and more readable, have been included in version 1.2. These include:
- support for a new type of clock control to simplify the handling of default values;
- support for global definitions of parameters and controls which allows them to be defined once, rather than repeating their definition within each strategy in which they are used; and
- clarification on how to access certain environment variables or order parameters held in the OMS, not defined in the XML, so they can be used in validation and filtering.
With these enhancements it will be easier for algo providers to write cleaner FIXatdl code and manage regional differences. Similarly, for vendors, fewer ambiguities from the previous release will help them support a more standardized service.
FIXatdl v1.2 is currently out for public comment, use the following link to view the document. (fixtrading.org/standards/fixatdl)
Beyond FIXatdl v1.2
With 10 years’ experience in the field, and with version 1.2 ready for release, the FIXatdl Working Group can now look even further down the road. FIXatdl of the future will need a slight expansion of its original design scope. This new vision that is forming includes standardizing the reporting around events that occur during the timeframe between order submission and actual execution, and to making the information contained in those reports directly available in standardized but highly flexible formats.
What is needed is a flexible but standardized structure for messages arising within the downstream execution infrastructure, after orders leave an OMS/EMS. Those messages need to flow backwards towards the initial trading intention (i.e., the trader/portfolio team or computer program) and inform how it’s all going, or not going. The goal will be to facilitate mid-course corrections with a view of actual, real-time market conditions; to navigate, if possible, around bottlenecks and obstacles and to keep that process very well-informed in very-near-real-time regarding order execution. Exception reports (at various levels such as: information, warnings, or actual faults) need to be very well-structured and freely communicable all the way back upstream, to ensure thorough and timely understanding at the very origin of trading.
FIXatdl, in its current form, does a great job at functionally describing an algo’s Human Computer Interface (HCI) without mandating an exact look and feel. This new execution feedback mechanism will also need to prescribe only the metadata (likely in XML Schema) for messages in such a way that the OMS/EMS systems can process those messages in any way they deem advisable. They should always have the freedom to vigorously compete based on their unique look and feel, and great workflow. That is what makes the variety of those systems so great, because it’s not a one-size-fits-all trading industry.
Anywhere in complex execution paths, exceptions and faults do occur. Since the entire network is a complex web, these events come from geographically distributed points, owned by numerous business entities. One future area where FIXatdl can deliver is to ensure the exception and fault events are very well communicated all the way back to the fountainhead of the trading business. That way, very quick, very intelligent action can be taken in direct support of the original trading intention. Indeed, such a standard should help keep traders and portfolio managers very happy.