What is a FIX engine?

What is a FIX Engine

The Financial Information Exchange (FIX) protocol was developed in the 1990's as a public specification.   As a global standard, the FIX protocol was developed and documented so that firms could build interfaces in their technology stack of choice.   The governing group (FIX Protocol Ltd / FIX Trading Community) would not build and market a FIX engine, but only provide the specification to do so.

Origins of the FIX Engine

In those early days, the only way to use a FIX engine was to build a solution from scratch (with commercial versions arriving soon after).   The software component that could connect and communicate using the FIX protocol was dubbed a "FIX Engine".  In those early days, the specification left room for human interpretation and with so many building their own solution, implementation of a FIX engine could vary greatly.  There were disagreements when testing with a partner as to how to resend messages correctly or how to respond to correction messages.

Today the need to build your own FIX engine might only be relevant if you are trying to squeeze out every last bit of performance for high frequency trading.  For the vast majority of use cases, existing solutions will suffice.   The great open source movement of the 2000's produced the QuickFIX solution.  Originally written in c++, it has been ported to a number of languages like C# and Java.  If you are in need of FIX engine, QuickFIX engines and other open source solutions are a great place to start.  If you have much more scalable needs, vendors can provide a paid solution.

Breaking Down the FIX Protocol Engine

The FIX engine provides the low level communication ability as well as the encoding / decoding (parsing) of FIX messages.   The most popular communications link for FIX is using the TCP/IP protocol.   The FIX engine will either open a connection to a specific IP and port or listen locally on a port.   For a FIX session to be established, one side will be the "Initiator" and the other the "Acceptor".   Traditionally the investment manager (buy side) is the initiator and the broker/dealer (sell side) is the acceptor.  The FIX engine must be able to send, receive, and also replay messages sent in the past.   FIX protocol by nature is a sequential and ordered message standard, ensuring messages are processed in the order they are intended to be received.  The FIX engine must provide logic to recover from missing messages sent/received.

When you use an open source or a vendor solution, the technical/messaging layer is implemented for you.  Your responsibility is focused on the "Application Layer" in which business messages are sent and received.   For example, send a FIX New Order Single message and receive executions via the Execution Report message.

We use our FIXSIM testing platform to validate our FIX Protocol engine implementation for both the session layer and the application layer.   FIXSIM allows a full testing of your FIX protocol compliance as a web based solution.  Start a trial today!

What a FIX Engine Must Do

At minimum, a production-grade FIX engine handles:

• Session establishment and logout (Logon/Logoff, 35=A and 35=5)
• Heartbeat generation and monitoring (35=0 and 35=1)
• Sequential message numbering with gap detection
• Resend request handling (35=2) and message replay
• Message storage for session recovery across disconnects
• Encoding and decoding of FIX tag=value pairs
• Support for multiple concurrent sessions

The application layer -- order routing logic, execution handling, business rules -- sits on top of this and is your responsibility to build and test.

Open Source vs Commercial FIX Engines

QuickFIX is the dominant open source option, originally written in C++ and ported to C# (QuickFIX/n), Java (QuickFIX/J), Python, and Ruby. For most use cases it's a solid starting point and free to use.

Commercial FIX engines from vendors like FIXICC and Onix Solutions add managed support, certified implementations, and performance guarantees that matter at high volume. If you're processing millions of messages per day or need regulatory certification support, the commercial route is worth evaluating.

The practical split: firms building their own OMS or EMS tend to start with QuickFIX. Firms buying a platform usually get the FIX engine bundled with it.

How to Test a FIX Engine

Before connecting to a live broker, you need a counterparty to test against. Options:

• FIX simulator -- connects to your engine, responds to orders with configurable execution reports. FIXSIM runs in a browser, supports all FIX versions, and lets you test session recovery, order workflows, and edge cases without any broker involvement.
• Broker UAT environments -- most brokers provide a user acceptance testing environment, but access takes time to arrange and testing is constrained by their setup.
• FIXimulator -- a free open source Java tool. Functional but requires local setup and has limited configurability compared to a hosted simulator.

Testing should cover session layer scenarios (gap detection, resend requests, sequence resets) as well as application layer scenarios (order acknowledgement, partial fills, cancel/replace, rejections).