4. Choosing a FIX engine
A FIX engine is a piece of software that manages a network connection, creates and parses outgoing and incoming messages, respectively, and recovers if something goes wrong. A FIX engine manages the session and application layers and is the single piece of software you need in order to FIX-enable trading or order management systems.
In the context of a trading system your FIX engine is the interface to the outside world, which, together with a network, connects you to outside world and allows you to trade and exchange related information in a standard fashion. Thus, to FIX-enable an application refers to the integration of a FIX engine and connection to a routing network.
Implementing FIX has different meanings depending if you are using an off-the-shelf OMS or building your own solution. FIX-enabled OMS come in two flavors. Some vendors select a FIX engine and integrate it into their system. If this is the case selecting a FIX engine has little relevance to you. You get what you are given. Other vendors allow clients to select which FIX engine they should use. In this instance, and for those building their own solutions, this chapter is a must-read.
All FIX engines do essentially the same thing but differ in three main ways:
On the softer side, engines differ by how many firms use them. Popular engines will have been more widely tested against than others, in itself an advantage for new entrants selecting the same engine.
The following data represents an overview of the features you should look at and their meaning.
|Support for asset classes other than equities||
|High availability, load balancing, and scalability||
|Speed and robustness||
|Ability to implement per-connection business logic||
|Provided as a set of class libraries or a FIX-in-a-box solution||
|Access to source code||
|Upgrades and updates||
|Cost and pricing options||
A current list of FIX engine vendors can be found on the FIX Protocol website. With over a hundred engines listed any selection process would appear to be non-trivial. FIX engines have become, to some extent, a commodity item and with so many engines available there is an implication that consolidation lies ahead.
Many FIX engines give prominence to the number of messages they can process a second. Being able to process many messages tells you much about an engine but this is sometimes achieved with extremely high performance configurations that may not match what you are planning to use. You need to ask yourself just what level of performance you need. If you regularly undertake statistical arbitrage or heavy list trading then a very powerful engine might be appropriate. Otherwise it is not so relevant.
Further to this, some engines do not store messages, and this is how they achieve a high-speed appearance. Messages stored in a database by the engine gives the ability to restore in the event of a hardware failure.
Consideration should be given to the different hardware requirements for the FIX engine chosen. Buyers should have an understanding of the infrastructure currently in place at their firm, the current and anticipated trading volumes, and how the engine selected will perform in that environment. Also, understand that any benchmark performance statistics provided by a vendor are dependent not only on the FIX engine software, but the hardware they are running on.
FIX engines tend to run on most all platforms or be specialized to operate under a Microsoft� environment. Finding an engine that runs on your platform is rarely an issue. Better to focus on whether you want an engine that runs as a Java or C++ codebase, implying a consideration between flexibility and performance.
Desirable because of any legacy messaging protocols you have, multi-protocol support can be very useful, and this could include support for such messaging protocols as IBM MQ Series, TIBCO Rendezvous or Smart Sockets, interfaces into middle and back office protocols like OASYS or SWIFT, or even lightweight protocols to connect directly to ECNs.
Consideration should also be given to support for other financial messaging protocols (for example, CMS), and what is required in order for the engine to support them.
Connectivity to ECNs and ATSs has become more important as firms look to other sources of liquidity and lower commissions. Most ECNs and ATSs now have FIX interfaces, but historically these have tended to be flavors of FIX, implying additional development and testing requirements. Some FIX engines have pre-built interfaces to such liquidity sources, saving you time and money. However, these interfaces can change as the ECN/ATS introduces new technologies and trading tools. Careful consideration should be given to how the FIX engine supports these destination specific configurations, and how easily they can be modified.
Taking this idea further some FIX engines, recognizing that it is not uncommon for firms to implement slightly different interpretations of FIX, have engaged with many leading counterparties and tested against them. They then provide their FIX engine with pre-built interfaces to these counterparties, the idea being to reduce the time, effort and cost required to go live. Again, understanding the complexities surrounding how the FIX engine builds these interface-specific configurations is important.
Less common in FIX engines is business logic within the engine itself. The idea is that you put business logic in the engine rather the application that sits on top of it - and provide a cleaner interface to the application. Uses would include logic to deal with different counterparties, message validation, protocol translation, and version mapping. This is quickly gaining popularity and it is likely more vendors will implement it.
With an increasing amount of business being transacted using FIX, alerting and monitoring are becoming vital. Increasingly FIX engines are starting to provide tools to monitor FIX connections and alerting functionality beyond that. Some are provided as applications, others as web front-ends, and others as frameworks easily integrated into other monitoring functionality you have in place.
Some vendors also offer testing tools, certification harnesses, and FIX simulators. Some are provided as simple stand alone tools allowing you to test the validity of your FIX implementation. Others allow you to host what you have at their site and permit your counterparties to test against this in an automated fashion.
Sound, automated testing tools significantly reduce your need for initial testing and the associated cost, getting you "to market" far faster. With further testing implied when one party upgrades to a new version or implementation of FIX, these tools can be used many times saving further time and resource.
Historically FIX engines were very expensive and as FIX has become more mainstream so the price has fallen. Most FIX engines charge on a licensing basis and, although some do not, you are generally charged in a different way, such as through support fees. Although freeware FIX engines exist they are best used for educational purposes or perhaps as a base on which to build your own engine. Unless the FIX engine seems really expensive (and some do still exist) price shouldn't be a major issue. More important is the ability of the vendor to be flexible around your needs, such as offering the engine on a rental basis or perhaps pay-as-you go support.
Taking into account the functionality to look for in a FIX engine and some of the more important aspects to examine, the following lists a suggested selection checklist.
Document Status: FPL's Global Steering Committee has approved this document for release on an online basis to FPL members only. This is the first edition of the Implementation Guide. The Global Fixed Income Committee, as sponsor of this Guide, advises members that the Guide may undergo frequent revision in format, content, or style in the coming months. Among these revisions may the system for assigning edition or version identifiers to the Guide. Whenever the Guide is revised the Global Fixed Income Committee will endeavor to notify all members through the FPL Program Office.