Skip to content
All library documents

Choosing a FIX Engine for CME Futures Connectivity

Article Quant Q&A · Author: mcmillab
Read the original

Summary

The document compares using an existing FIX engine directly with adopting a commercial API to connect to CME futures markets. Its central operational point is that pre-certification of an engine does not remove the exchange certification work required of the firm. Nor does an engine provide a plug-and-play connection: it still needs to be integrated with the firm's order flow, and CME's broad set of features and order types may exceed what a particular system needs.

The response recommends judging an engine by how easily its API fits the existing system, as well as by throughput and allocation behavior when latency matters. This is practical integration guidance rather than a quantitative comparison: the exchange includes no benchmarks, cost estimates, or controlled assessment of particular products. The answer also contains a vendor developer's affiliation, so its product example should be read with that context in mind. The general lessons are to plan for certification and integration effort and to evaluate tools against the actual order flow and performance requirements.

Key ideas

  • A pre-certified FIX engine does not eliminate the firm's exchange certification requirement.
  • FIX connectivity still requires integration with the firm's order flow system.
  • Evaluate API usability against the features and order types the firm actually needs.
  • For latency-sensitive systems, throughput and memory allocation behavior can matter.
  • The document provides no benchmark or cost comparison, and its product example comes from a developer affiliated with that product.

Tags

FuturesExecutionMarket microstructureHigh-frequency trading
Full text
# Should I use QuickFix or a 3rd-party commercial API to connect to the CME


# Should I use QuickFix or a 3rd-party commercial API to connect to the CME












I already use QuickFixN to connect to FX ECNs, and am now looking to branch out into futures.

Googling it, it seems as if there are a lot of 3rd party APIs which are written to do this, but is there any reason I wouldn't just use QuickFix and connect directly to the exchange?

Obviously cost is one reason to use Quickfix, and from the looks of it some 3rd party APIs are "pre-certified", which may be a reason to use them.

How significant is this, and is there anything else I am missing?

## Answer by rdalmeida (score 2, accepted)

https://quant.stackexchange.com/a/14395

A pre-certified FIX engine won't spare you from doing the certification process yourself. This is a requirement for all serious exchanges. Moreover, CME is a good exchange with tons of features and many different order types from which you will probably just need a small subset. There is no such thing as a plug-and-play FIX engine. You will have to do some work to integrate the FIX engine with your order flow system. I believe that more important than choosing a pre-certified FIX engine is to choose one that offers a very intuitive API so you have no headaches integrating it with your systems. Also, if you are concerned with latency, you should choose one that produces no garbage (for .NET and Java environments) and has a good throughput. For an example of an intuitive FIX engine take a look on CoralFIX.

Disclaimer: I am one of the developers of CoralFIX.

Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)

This summary was written by Stratmill's research agent from the original; it is not a copy of the source.