The Gateway to Algorithmic and Automated Trading

Technology Workshop: Algo Integration - Can FIX Fix It?

Published in Automated Trader Magazine Issue 03 October 2006

The FIX Protocolís provision of a broad set of commonly accepted standards has radically simplified and reduced the cost of financial messaging in capital markets. A relatively recent innovation within FIX has been the work of the Algorithmic Trading Working Group which is evaluating the integration issues surrounding algorithmic trading. AT talks to John Goeller of Lehman Brothers, who heads the group, about its proposed solution for algorithmic trading interfaces.

What do you see as the area of algorithmic trading in which your group has most to contribute?

There is no question in our mind that it is in defining a set of standards for algorithmic trading interfaces. At present when people use FIX for algorithms they define custom tags to represent the algorithms' parameters. Therefore a lot of sellside firms in particular have registered a large number of custom tags for the parameters in their proprietary strategies. While some of these may become industry standards by adoption, they are still essentially a proprietary extension to the FIX Protocol.


What is the practical impact of this way of doing things?

Inefficiency, because every time you create a new algorithm you have to figure out which existing proprietary tags you will use for your algorithm parameters and/or whether you will have to create your own proprietary tags. However, the big problem is that you then have to persuade all the order management system (OMS) vendors to integrate your particular algorithm and custom tags. In addition, you will probably have to negotiate with network providers as well to ensure that they won't automatically discard your non-standard custom tags in transit. A further complication is that because of the lack of standardisation, different sell side vendors may use the same tags for different parameters. Last year's FIX Protocol Limited (FPL) sponsored survey identified the cost of adapting order management systems and changing procedures to support algorithms on those systems as the single biggest barrier to greater adoption of algorithmic trading.


Despite that barrier, algorithmic trading continues to expand. Presumably this expansion is only exacerbating the situation?

Yes. You already have perhaps thirty or so sellside suppliers of algorithms, some of which may offer as many as ten algorithms. Furthermore, the rate of change is increasing, with some providers already working on their third generation of algorithms. These new algorithms require parameter inputs that have to be made available to clients. Another factor is the growth in customisation and specialisation. For example, a hedge fund might approach a sellside firm and ask it to create a custom algorithm or to apply tweaks to an existing one. The logical extension to this, which is already being discussed, is to allow clients to define their own execution algorithms to run on their sellside providers' platforms. There seems little doubt that a scalable and reliable algorithmic trading platform where participants such as hedge funds could run their own algorithms securely would have considerable appeal.


So presumably as more algorithms emerge, the implementation bottleneck with the OMS vendors becomes worse? oms_box.jpg

"...the typical upgrade cycle takes months (if not longer) largely because of the lengthening implementation queue."
Yes - the typical upgrade cycle takes months (if not longer) largely because of the lengthening implementation queue. Even after implementation starts, every algorithm has to be custom integrated by hand into each different OMS. It then has to be regression tested and certified by the OMS vendor. You then have to wait for the client to upgrade to the latest version of the OMS that incorporates your hard coded algorithm. That might add another year to the whole process. A further concern is the effect that this has on new markets where clients are undecided about algorithmic trading and would like to dip a toe in the water first. The protracted implementation process makes this largely impractical at present, but even where a client is set up (at considerable effort and cost) for a trial they might still decide not to proceed into production.


How did this evolve into a proposed FIX solution?

The FPL Algorithmic Working Group previously created a document entitled "Proposed Algorithmic Trading Extensions" which has the stated goal of supporting unlimited algorithmic parameters in a standardised manner with the major implication being that the solution was data driven. The document introduced several new tags (957, 958, 959 and 960) in a repeating group structure which allowed for counterparty agreement of algorithmic parameters. Every time a broker wanted to add a new strategy or parameter to an existing strategy they would not have to come up with new tag numbers. Further strategies or refinement to existing strategies would be handled by providing the client/vendor with the appropriate values for Tags 958 (StrategyParameter Name) and 959 (Strategy ParameterType). From a FIX perspective, buyside clients/vendors only had to code support for tags 957, 958, 959 and 960 in their FIX gateways. However, this approach only solved one part of the problem. The biggest challenge was how vendors/clients would represent these new features on their front-ends. Around that time, a number of firms started looking at ways in which they might use XML as a means of defining the interface for an algorithm and integrating this in real time with an OMS. A number of threads on the subject began appearing on the FIX web-site and we thought it made sense to formalise these discussions under the FPL Algorithmic Trading Working Group. I'm currently the co-chair of the FPL Americas Regional Committee and a member of the FPL Global Steering Committee, so I helped organise a series of workshops to present ideas on solutions for algorithm integration. We held a couple of presentations in New York and London late last year for the buyside, sellside and vendor communities. The working group has been conducting intensive interviews with all these groups since then to try and discover what they want from such a standard.


You mentioned XML, is that the core technology supporting the proposed standard?

Well, more specifically, we are evaluating a combination of XML and two XML user interface languages called XUL (User Interface Language) and XAML (Extensible Application Markup Language). XUL is an open source language developed by the Mozilla organisation, and is used extensively in their Firefox browser. XAML is Microsoft's equivalent, and underpins the user interface technology in its next version of Windows, Vista. Essentially, we intend to use XML to define algorithms and their parameters via a FIX Protocol provided standard XML Schema and leverage the XML based display technology (XUL or XAML) to richly display each algorithm and its parameters in any user interface.


So does the standard just relate to how an algorithm's parameters can be displayed to the user?

No, that is just part of it. The crucial point is that the solution contains an XML schema that allows an algorithm, its parameters and the exchanges it is available on to be defined in a consistent and portable manner. For each parameter it is possible to define its type (string, floating point, integer etc), min/max/default values, whether it is mandatory/optional, and some "Tool Tip" text. However, the most important point is that it is also possible to define which FIX tags a parameter's value maps to. This information can then be displayed in any user interface using XUL or XAML, without requiring any of the extensive one-off manual integration used today.


So from a practical perspective, this would streamline the process of implementing new algorithms?

Yes, assuming that the OMS vendors supported this standard schema, it would make it straightforward for the sellside to define their algorithms in an XML document. Basically, the broker would create an XML file (much like a configuration file) which describes its algorithms, their parameters, FIX tag mappings and how the algorithms should be rendered in any third party application. The OMS vendor would parse this XML file and render it in their application eliminating the need for custom programming. This would mean that algorithm implementation could be a real time process, so algorithms could immediately be made available to clients using an OMS that supported the standard.


Who is involved in the development process of the standard?

It is a collaborative effort which is very similar to other developments managed by the FIX organisation (FIX Protocol Ltd). We have a number of volunteers from the buyside, sellside and vendor communities who are collaborating on the proposed solution. We actually divided the volunteers into business and technical teams. The business team inventoried the strategy parameters currently in use in the industry and developed the business requirements for the technical team. They've also been interviewing a number of industry participants around the challenges of algorithm integration. The technical team will identify the integration options and develop the technical requirements and create the XML schema. This broad participation is valuable, as it is very important that the standard is seen as an industry-wide initiative with a lot of collaboration, otherwise it will not be widely adopted.


Have you had to make significant changes to the schema during its evolution?

The tricky bit hasn't been the technology but deciding how far to go. OMS vendors have obviously invested in their GUIs over the years and some are therefore unenthusiastic about the graphical element in the standard allowing the sellside to define how their algorithms will be displayed in the OMS. We therefore modified the original vision so we will have an XML schema that defines the attributes of an algorithm and the FIX tag parameter mapping. There will also be an optional graphic sub-schema using either XAML or XUL that be applied to the basic algorithm definition in order to auto generate a customised GUI for the algorithm.


What about usability from a trader's perspective?

This is something we started examining at the workshops in New York and London. There were a lot of questions about usability at the workshops and the crucial point here will be workflow. The validation logic has to take into account whether or not the algorithm is actually currently running. For example, can you do a cancel replace with a particular algorithm? (Some algorithms support this, but some don't). Can you change the parameters? That will depend on the algorithm and whether it is running or not. Therefore, do you pause the algorithm first and then change it, or can you change it while it's running? What is the effect of that? Do you actually get a cancel replace or do an amendment intraday? How is that reflected back in the OMS? Does the OMS need to know or care? If the OMS goes down and comes back up again, how do you know what algorithms you are running and what their parameters were? None of this is particularly difficult to do in terms of the technology, but one still has to work through all the possible scenarios in the process and deal with them appropriately.


What is your feel as regards buy-in at present?

We have had a very positive response so far. The only significant push back we have had relates to some OMS vendors and the GUI, which I mentioned earlier. (Buyside firms with their own proprietary OMS have no problem with this element). However, the decision to make the graphical sub-schema optional addresses the OMS vendors' concerns. The sellside can produce XML definitions of their algorithms that include the graphical elements, but because these are optional, the OMS vendor is at liberty to ignore them. This does not of course alter the main XML schema, which defines algorithm parameters and FIX tag mapping, so whether or not the graphical elements are used will not affect the ease and speed of algorithm integration.


What about more complex algorithms?

That is very much an attribute of the strategy and there are two ways of dealing with this. On the one hand, you could just cancel and replace every few minutes, as and when the parameter changes occur. On the other, many sophisticated algorithms are self-adaptive and only have minimum and maximum user settings - no parameter inputs are required between these two levels as the exact setting is determined automatically. However, an altogether trickier problem is how one deals with something like a pairs strategy. Most OMSs can handle multiple stocks or baskets but this is not really conditional functionality in the sense of a pairs strategy where the purchase of one stock is conditional upon the sale of another. I think therefore that pairs will be a special case that will need special logic within the OMS. (picture here).

racing_car.jpg
What about multi asset algorithms?

FIX is a multi asset protocol, so there is no reason why this schema cannot be used across classes. Obviously the bulk of the work to date has been done in the equity space, but there is no technical or practical obstacle to it being applied across foreign exchange, futures and options, bonds or anything else.


What is the timescale for the launch of the standard?

We hope to have the solution finalised by early next year. It may take little longer to have it formally included as part of the FIX Protocol, but we hope to have at least one OMS vendor that has integrated and is actively supporting it, and at least one sellside provider supplying algorithm updates as a reference implementation. I think once one OMS vendor and sellside firm adopt it, the rest will want to follow as the advantages will be obvious. The question we asked during the road shows was, "Why wouldn't you want to do this?" If you are a sellside provider of algorithms you can deploy more of them, and if you are an OMS vendor your clients can obtain access to their brokers' algorithms more easily. Essentially, everybody benefits from a shorter time to market. While the initial release will cover the most common situations, we see this very much as an ongoing process. Therefore, we will look at areas such as more complex state transition problems and pairs trading at a later date.


What other developments do you anticipate for the standard?

Every algorithm produces lots of exhaust. By that I mean commentary on what and how it is doing, and its performance against various benchmarks. One possibility would be to capture that commentary and send it back via FIX for display in a standardised way. The graphical elements and technology we have proposed for the current prototype standard will be well suited for this, so the sellside could produce charts and graphics that provided a real time intuitive graphical representation of this exhaust. This is just one example of the possibilities, so you could argue that the current initiative is just opening the lid on what is eventually possible.