FIXatdl – Changing the landscape of strategy trading

Share

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.

How FIXatdl changes the process
In order to make this standard work for all parties involved, a number of conditions should be met:

1. The OMS /EMS vendor would support the standard. A system must exist that can “consume” a broker specification in FIXatdl format and render the order entry screen dynamically. The broker should support the standard.
2. In order for the vendor to make (economical) use of the new capability to read and parse FIXatdl files, it wants to receive specifications in that format (as opposed to Excel, Word, PDF, etc. formats). Some vendors have meanwhile announced support of FIXatdl, and are “translating” the legacy formatted specifications into FIXatdl themselves. Ideally, the maintenance of the FIXatdl specification is done by the broker.
3. The buy-side should be on board because traditionally, changes on the sell-side happen quicker if the provider of the order flow asks for them.
4. Commercial software vendors and service providers are entering the scene. While some authors of FIXatdl files are perfectly content creating them in a simple XML or even text editor, it’s significantly easier for a broker to create the FIXatdl specifications in a GUI-driven editing program.
If conditions (1) and (2) are met, the process of integrating a broker specification into an existing system becomes much simpler. Vendors would receive and review the new FIXatdl specifications, load and parse them, and the GUI is ready for immediate use. While the need for integration testing and certification is not removed, that task can now be accomplished quicker and potentially “on-the-fly”. A new strategy needs to be added? Maybe a new parameter needs to be included in an existing strategy? The layout of the GUI needs to be tweaked? Just create an updated FIXatdl file and you are ready to go.
The Business Case – to adopt or not to adopt?
If the process is so easy, why isn’t everyone doing this already? Consider a broker who has paid vendors dearly, for years, to implement and maintain a complex set of strategies. This was presumably done to carve out a certain amount of competitive advantage, to gain an edge over others in the same space, and get clients to direct more flow accordingly.

How would FIXatdl work with this business strategy when it effectively lowers the barriers to entry? One could surmise that this case is comparable to a face-off between Encyclopedia Britannica and Wikipedia. If the broker chooses not to support the emerging standard that firm may run the risk of being “left out” when the number of other supporters grow. On the other hand, the increased implementation speed, in terms of time to market, along with a greater measure of consistency across vendor systems could result in the same – if not better – competitive advantage to that same broker.
Additionally, a measure of risk management is inherent to a standardized specification format such as FIXatdl – the room for “interpretation errors” is much smaller, thus reducing the chance of trading errors.
For the smaller broker dealer, “to adopt or not to adopt” is much less relevant – the easier and faster the implementation, the greater the chances to be able to take a slice of the “competitive pie”.
On the buy-side the case is clear. The more access to algorithmic order types is provided, the greater the ability to implement the desired trading strategies, be that cost optimization, reduction of manual trading tasks, or performing relative to a benchmark.
Last, but not least – the vendors. The process of adopting FIXatdl is not painless, but the effort is definitely worth it – it allows vendors to standardize processes and procedures and can cut down development and implementation time for our clients dramatically.
What’s next?
Adoption
As with any emerging field, no progress is made without encountering at least a few challenges. If you recall the adoption of the FIX Protocol in the mid-1990s, you will remember that it was not a fast and easy process. A standard is most easily considered a standard when it is widely used. To get to that point, more people have to adopt the standard – a classic Catch-22 scenario. The difficulty of this scenario decreases with each new adopter.

Editing
Another stumbling block for some is the relative lack of tools to create and edit FIXatdl files. There already are some vendors providing software to assist in the creation and maintenance of FIXatdl formatted specifications; however, just like the standard itself, this field is still emerging. For an editing software package to be viable, particularly in such a specialized field, the audience needs to be large enough, or the costs (to create or to charge the customer) will become prohibitive.

Education & Training
In recent weeks, I have asked people the question: “What do you think about FIXatdl?” The answers I got ranged from “another FIX standard that people will just ‘bend’ to suit” to “why hasn’t anyone thought of this earlier?”.

While this magazine, the FPL website, and the FIXatdl Working Group are fantastic, volunteer-driven resources, it appears that understanding the impact of FIXatdl and successfully transforming the specification creation process needs more than written documentation. Seminars, roundtables, and training sessions, for business and technology alike, could speed and ease the adoption process.
Conclusion
Considering the advantages and current maturity of the FIXatdl standard, it appears that widespread adoption is just around the corner. The ever increasing need for customercontrolled order behavior and the chase for best execution dictate a change in the current process, and FIXatdl is just the recipe we need.