FIXatdl – Changing the landscape of strategy trading

By Witold Sames
FIX Algorithmic Trading Definition Languagesm, or FIXatdl as it’s more succinctly known, is an emerging standard that allows for the expression of electronic trading strategies in relatively simple XML format. It is built on top of the FIX Protocol and, importantly, it’s free. However, as Portware’s Witold Sames explains, to successfully implement FIXatdl, you’ll need some careful planning and resources.
From the first broker strategy screen ever created to today’s many strategy implementations, the process of developing practical, functional, and even handsome user interfaces has not changed dramatically. To provide some context, imagine that a strategy provider (usually a sell-side trading firm) has just finished inventing and testing a strategy to provide new capabilities to their clients. Its sales team would then call on the client to explain the process and how to tweak the related parameters to make the strategy work in the client’s favor.
A graphical user interface (GUI) allows a trader to make these adjustments easily and quickly. A “typical” broker strategy screen as imagined by a broker would contain a logo to “brand the experience”, a list of entry fields (such as start and end time, volume participation limits, etc.) and controls to either send the order(s) as defined or cancel the action. To present this functionality to their clients, brokers would create documents outlining the technical details of the messages to be generated by the client’s order management system (OMS) or execution management system (EMS). Vendors would then review the specifications, perform necessary business analysis and start coding. Some artistic license with respect to layouts or control types would be taken, especially when the broker didn’t supply any layout examples. Once development completes, a walkthrough demo would be performed to validate the implementation.
The last step involves functional certification: Does the strategy GUI do what the specifications prescribed? Is it practical? Are there ambiguities? Upon sign-off, the code can then be installed for the client to use. Depending on the vendor, coding is done in any number of languages, formats, and designs – each specifically tailored to that vendors system. This is currently the most widely adopted method to integrate broker strategies into an OMS or EMS, and can be costly, both in terms of time and money. Depending on the complexities, the process can take months to complete.
The recent growth in the use of algorithmic order types, as well as the increase in the number of brokers offering them, has shown that the process does not scale well. The resulting implementations are rather static, and may require code releases to every affected client every time a change is made. When we take the number of brokers, strategies, clients, and vendors into consideration, it becomes painfully clear that there is a need to rethink this strategy.
Could FIXadtl be the answer?
FIXatdl creates a framework useful to all players. It defines a broker specification on four basic levels:
Level 1 – The Core Schema
This part of the FIXatdl specification contains those attributes and elements that describe the data content of the strategy order. For example, one could define that the start time parameter in a VWAP order is to be sent in tag 168, using the UTCTimeStamp data type definition. The definition of the strategy type itself (in FIX: 847=VWAP, for example) is also done here.
Level 2 – The Layout or Graphical User Interface (GUI) sub-schema
The attributes and elements in this part of the FIXatdl specifications deal with the visual representation of the strategy parameters on the client’s screen. For instance, it could describe where (relative to the order entry screen itself) a start time parameter should be shown as well as define the control type to be used (a “Clock” control would be the most appropriate for the start time parameter).
Level 3 – The Validation sub-schema
Attributes and elements in this schema describe any constraints placed on the parameters or combination thereof in the strategy. For example, we could stipulate that the user should see an error message if the start time chosen is not before the end time, or a percentage of volume limit is entered to be greater than 100.
Level 4 – The Flow sub-schema
This schema provides the ability to control the appearance of the order entry screen. In this case, a rule could be created that disables or grays out a particular section of the order entry screen if the “Advanced Parameters” checkbox was not chosen by the user.