FIXatdl
FIX Algorithmic Trading Definition Language, better known as FIXatdl, is a standard for the exchange of meta-information required to enable algorithmic trading activity within the financial markets. It works in tandem with the Financial Information eXchange protocol which is the lingua franca of electronic trading in the securities market.
Background
Prior to the mid-nineties, virtually all trading of securities was transacted over the phone, but with the advent of FIX, trading moved steadily over to electronic means. The FIX protocol is used to communicate between sell-side and the buy-side Order Management Systems to exchange orders and order execution information without human intervention, using standardised messages and workflows that are defined by the protocol.Initially, sell-side firms only provided access to their 'trading desks' via FIX, which meant that once an order arrived at the sell-side broker, it was handled by a human trader, at least at the start of its lifecycle. Subsequently, sell-side firms started to offer direct access via FIX to the exchanges/markets they were members of; this is known as direct market access. At this time, many sell-side firms had their own proprietary systems to trade automatically in the market, using algorithmic trading strategies, and over time they began to see that offering access to these trading strategies to the buy-side was a way to attract business and increase revenue.
Whilst FIX is an extensible protocol, there were two challenges that arose as a result of sell-side firms offering access to their algorithmic trading strategies via FIX. The first was that each sell-side strategy had its own parameters that had to be included as part of the order, so every firm ended up requiring a different set of fields to be included in the FIX message. This made life very difficult for the buy-side, and more particularly for their suppliers as adding new algorithms to their trading systems and managing all the different combinations of tags became a significant overhead for their development operations.
The second issue for the market was that each sell-side firm had a specific way they wanted their algorithms to be displayed on the buy-side OMS, with controls in the user interface arranged logically for easy order entry. Again this proved a challenge for the buy-side systems vendors, as each new screen for each sell-side broker required dedicated development and testing effort.
History
To tackle these issues, FIX Protocol Limited established the Algorithmic Trading Working Group in Q3 2004. The initial focus of the group was to solve the first of these issues, which it did by defining a new group of fields, the StrategyParametersGrp, made up of FIX tags 957 through 960 – these tags were formally introduced with the release of FIX 5.0 in Q4 2006. By allowing sell-side firms to include their proprietary fields in a repeating name-value pair structure, there was no requirement for OMS vendors to define specific FIX message structures for each sell-side trading destination.This solution was not broadly adopted, in part because of the limited penetration of FIX 5.0 and in part due to the fact that firms already had working implementations in the market place that they were unwilling to change without good cause. Perhaps more importantly, it failed to solve what was the more substantial issue for the market, the complexity for the buy-side vendors resulting from lack of standardisation.
The idea of using an XML structure to describe the presentation of algorithm user interfaces and their accompanying parameters was firstly suggested within the working group by Daniel Clayden, then of JP Morgan Chase in a 2005 forum posting. Members of the working group developed this idea during 2006 and in January 2007 invited broader industry participation at a workshop to review their ideas. A specification was eventually produced and this began beta testing in July 2007. This specification became FIXatdl 1.0 which was approved by the FPL Global Technical Committee on March 28, 2008.
Despite some initial enthusiasm, overall Version 1.0 had a lacklustre reception by the marketplace. Some vendors saw an opportunity to provide services around the standard, such as ULLINK with their algorithm publication and management and tool UL AMS but whilst the major OMS vendors were irritated by the overhead of implementing new broker algorithms, they had grown to enjoy the revenue that they could command from both their customers and from brokers keen to get their algorithms onto buy-side desks.
Although Version 1.0 was a major step forward, it had some significant limitations. In particular, the definition of the data to be transmitted and its presentation on the user interface were tightly bound together, limiting the flexibility sell-side brokers had in defining their algorithms. The 1.0 specification also afforded insufficient control in terms of user interface layouts.
The working group set out to address these limitations in what was to become Version 1.1 on the specification. The first major change was to split the definition of the data content from the presentation, defining what is referred to as a separate "Data Contract" made up of the algorithm parameters, their data types and supporting information such as minimum and maximum values. A separate section of the XML document is then concerned with the layout of the user interface, what controls to use for each parameter and where to place them on the screen. An XSD schema is provided to ensure that FIXatdl files are valid and well-formed.
FIXatdl Version 1.1 was preliminarily approved by the GTC on February 9, 2010, when it entered a public comment period, and then finally approved on March 3, 2010. The specification was formally introduced to the market at the FPL’s Europe Middle East and Africa conference on March 23, 2010.
Some early work was undertaken on a Version 1.2 of the standard, but lack of industry interest in accommodating further changes meant the standard remained at Version 1.1.
Document structure
A FIXatdl document can contain one or more strategy definitions. Within a strategy definition, there are four main sections as follows:- Meta-data section defining which geographical regions, markets and asset classes the strategy is applicable to
- Parameters section, listing out each of the parameters used by the strategy, their data types, constraints and how they should be represented in the resulting FIX message
- StrategyLayout section which defines the user interface controls to be used for this strategy, how they should be laid out on the screen and how they map to the parameters described in the previous section of the document
- StrategyEdit section which describes the validation rules to be applied – typically these will be cross field validations
- Core
- Layout
- Validation
- Flow
User interface capabilities
- Labels
- Text entry fields
- Checkboxes and radio buttons, both singly and in lists
- Listboxes, both single and multi-selection
- Dropdown lists, both editable and non-editable
- Clock controls, for date/time entry
- Sliders, for selecting one of a small number of settings
- Numeric spinners, both single and double for integers and floating point numbers respectively
Adoption
Unlike the previous version, Version 1.1 was widely accepted and adopted by the securities industry. Even at the end of 2009, there were already firms using the 1.1 standard, despite its pre-release status. Examples of firms supporting the FIXatdl standard include:- RealTick Execution Management System, by Eze Software Group
- SimCorp Dimension's Module
- Itiviti, with their
- The Portware Execution Management System
- RapidAddition, with their
- Assimilate Technology, with their
- , with their FIXatdl Jump-Start packaged consulting service, public FIXatdl training workshops and free FIXatdl validation service,