Loyola Virtual Exchange


we research and share

The Tail of Low Latency and FIX Engines

In our project, we decided to use QuickFIX/J.

[What is FIX Protocol? – It’s an electronic communications protocol that allows market participants to communicate for the purpose of trading, reporting, regulation, and other. It is used between exchanges and brokers/institutions, as well as used by many agents internally.]

There are different opinions whether QuickFIX/J is a good choice for a trading application. It is definitely not the fastest fix engine. Just think about all this overhead – nested functions, temporary objects, temporary strings – in addition, to be in Java. At the same time, it’s free and quite good.

Here is a link to QuickFIX/J where you can get all the info:


We are using FIX5, and so does London Stock Exchange.

[If interested to see real market requirements check here, http://www.londonstockexchange.com/products-and-services/millennium-exchange/technicalinformation/technicalinformation.htm].

So QuickFIX definitely suits us now because we are not trying to go super low latency just yet [one can dream].

The trick with low latency is that it depends on many factors. Let’s remind ourselves that low latency really means measuring your time in sub-microseconds. Even if you purchase/create the fastest FIX engine you may still experience some delay. First of all, you really need to use a very good machine and OS to minimize the noise. Secondly, the FIX engine would not get you anywhere if you have some issues with your architecture. And finally, get the finest server that would not interrupt your speed.

Also, keep in mind that the limit for QuickFIX would be around 50 microseconds [not tested by me, we will update].

Let’s say you get it all and still want to proceed with a custom [or just very cool] FIX engine. OK!

Option #1: Go C++ and FIX8

FIX8 claims to be the fastest open source fix. 

FIX8.org shows tests and on typical hardware, client NewOrderSingle encode latency is now 2.1µs, and ExecutionReport decode 3.2µs. Without the framework overhead, NewOrderSingle encode latency is 1.4µs.

Check their https://github.com/fix8/fix8

You can download Open Source ver 1.4.0 (community supported) in C++ here http://fix8.org/downloads.html  

If you want to stay with java (some may have reasons) they also have a commercial version (FIX8PRO) java bundle.

Option #2: Build your own

It is a ton of work and requires certain mastery. However, it is possible. Just search Github and you will find different variations. Try to inline your accessors for example. Use something else instead of strings. Be creative.

Check these people from Chronicle FIX at https://github.com/OpenHFT  

We will continue to investigate this topic and add more information about building your own FIX.