FIXSIM

The Financial Information Exchange (FIX) protocol was developed in the 1990's as a public specification.   As a global standard, the 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 solution, but only provide the specification do so.

In those early days, the only way to use FIX 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 FIX 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 and other open source solutions are a great place to start.  If you have much more scalable needs, vendors can provide a paid solution.

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 engine must be able to send, receive, and also replay messages sent in the past.   FIX by nature is a sequential and ordered message standard, ensure messages are processed in the order they are intended to be received.  The 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 an 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 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.