Is FIX Protocol Use Declining?
We've been having our own great debate about fairness in the markets, and it's about native binary protocols versus the Financial Information Exchange (FIX). Binary protocols are built for performance with no regard to a human operator if something goes wrong. FIX, by contrast, is all strings, easy to read and search, and fast enough for most uses.
Binary protocols have been adopted since 2005 by the world's exchanges to cater to the most volume-driven strategies. Exchanges are very eager to work with high volume because of the revenue potential. It is true in the USA in equities, options, and futures. It is true in London, Europe, and other places. But FIX is widely adopted by the buy side, sell side, exchanges, networks, and dark pools.
Going back to 1993, the FIX protocol was designed by the buy side to talk to the sell side. Over the last decade, savvy dark pools, ATSs, and exchanges that wanted to tap into the buy side have directly supported FIX. Many buy-side OMS vendors like Charles River Development, Eze Castle, and Bloomberg TOMS only send trades using FIX.
Some exchanges such as Nasdaq support both the binary protocol OUCH and FIX. Any trader will tell you that OUCH is better for low-latency trading than FIX. OUCH's fields are in fixed positions, and numbers like quantities and prices are native, not represented as strings, as they are in FIX. It is much easier for a CPU to read a message and interpret it into a computer language like C++ or Java. FIX needs to be parsed one field at a time, searching for delimiters that mark the end of data fields. And then numbers like a floating-point price need to be converted from a string -- an expensive operation that takes up CPU cycles. Because of this, the overhead of FIX carries more than double the latency and throughput of OUCH.
Why is there a cottage industry built around FIX engines, but no OUCH engines? Well, for the most part, OUCH is much easier to implement than FIX. FIX is designed to be all things to all people -- multi-asset, multi-currency, pre-trade through post-trade workflows -- so it takes a lot more care to build a FIX engine to cover all the cases. OUCH was purpose built for equities trading (and much later ported to support equity options). It's much easier for programmers to build high-speed implementations of OUCH than FIX.
For the most demanding traders and market makers, the last connection into the exchange needs to be really robust. Exchanges often listen to their most demanding customers, and this means implementing binary protocols like OUCH. Binary protocols are simpler for programmers to implement, easier to scale, and better on bandwidth and CPU than FIX. Jamming in more messages in a shorter amount of time to the exchange is really important to many successful strategies.
Is FIX use declining? Well, not yet, and probably not for a long time. Where low latency is important, there is robust growth in binary protocols driven by the world's exchanges and high-volume traders. Where the market community is catering to systematic, algorithmic trading, FIX continues to grow.
Meanwhile, new protocols like Bit Protocol for crypto currencies are based on easy-to-implement, low-latency technologies based on JavaScript Object Notation, which gives you the flexibility of FIX and the ease of implementation and low latency of OUCH.
The new Bit Protocol is known to elite speed traders and, of course, to exchanges, but not necessarily to all buy-side and sell-side firms. This is part of the debate around HFT that not all plumbing is explained. But exchanges are driving this innovation, and Bitcoin/crypo currencies will drive it further. Let's see how quickly these new protocols are adopted and how the landscape changes in the next few years.
George Kledaras is the founder and Chairman of FIX Flyer, a financial technology company in New York City. He is also the author of numerous articles about the FIX protocol and electronic trading standards, and a frequent speaker on the major technology issues of our ... View Full Bio
Tweet This