FIX Protocol Tutorial

The FIX Protocol dates back to 1992, with the intended purpose of electronically communicating equity trades between an investment manager (buy side) and execution broker (sell side). Prior to FIX, trade details were communicated via telephone or a custom file format which was unique to each broker.

It's important to note that FIX predates many technical specifications and events, such as XML (1998) and the founding of Google (1998). Those new to FIX might question why isn't it XML based (there is a version that is!) and why are there different versions defined, but only a few in actual use? We'll explain, but if you would like more information on history check the wikipedia entry or the official FIX Protocol website.

One of the most important features of FIX is the combination of both the message specification and the underlying session protocol. Starting with FIX.5.0, FIX allowed the separation of of the transport layer and the message layer, however in practice most production FIX sessions use the built in TCP/IP session layer. More on FIX versioning next.

Using the standard FIX transport layer, a FIX session establishes a point to point socket (TCP/IP). Between 2 FIX sessions, one is specified as the Initiator and one is the Acceptor. In a traditional connection, this usually equates to an investment firm being an Initiator and a Broker/Dealer/Trading Platform acting as the Acceptor. Before any FIX traffic can be exchanged, end to end connectivity must be supported. A "telnet" session can be used to verify the endpoint can be reached.

Transport layer connections can be:

• Local Machine (Loopback)
• LAN / Intranet
• Internet / SSL
• Private Lines (Many large institutions implement private secure lines)

Production FIX versions today start with version 4.0 (previous versions have been deprecated). Choice of a FIX version is dependent on what the Business/Application supports. While there is no official delineation of versions and asset classes, a pattern has emerged in the industry. The following descriptions are based on trading message flow.

FIX 4.0 - 1998

Declining in usage, FIX 4.0 is used for legacy equity (Common Stock) trading. A number of implementation challenges exist due to interpretation of Order Cancel / Correct workflows.

FIX 4.2 - 2000

FIX 4.2 is the predominate version of FIX used for Equity and Equity Derivatives (Futures/Options). In addition to well defined Order workflows, Order Cancel and Corrections have been clearly defined in the specification.

There is also some use of Foreign Exchange (FX/Currency) trading, mostly for simple Spot and Forward trading (not currency swaps).

FIX 4.4 - 2003

FIX 4.4 is the version of choice for Fixed Income trading and also more complex Foreign Exchange (FX) as well as equity.

FIX 5.0 - 2006

FIX 5.0 introduced the ability to separate the transport layer from the application layer, and allow you to send any FIX version message on the same session. For example, you could use a messaging queue (such as MQSeries) to send FIX messages.

FIX 5.0 and it's service packs are being used for Over-The-Counter trades, such as Credit Defaul Swaps (CDS) and Interest Rate Swaps (IRS).

After a socket connection has been established, the Initiator will send a FIX Logon (Message Type A) to the Acceptor. The Acceptor will determine the senders identity (SenderCompId, tag 49) and verify the Msg Sequence Number received. If the Logon message is accepted, the Accpetor will respond with a Logon Message as confirmation. If the Logon is not accepted, usually the acceptor will terminate the socket.

Once a valid logon exchange has occurred, both sides of the FIX session will send periodic Heartbeat (Message Type 0) with a frequency as defined in the initiators Logon message (usually every 60 seconds). The hearbeats allow each side to know that not only is the socket active, but each side is processing messages efficiently.

Through the use of FIX sequence numbers, the FIX Protocol has a built in message delivery and session recovery feature. Each FIX message has a sequential number associated with it. For example, at the start of day a connection sequence number will be 1 for the initial Logon. Each message sent thereafter increments the sequence number (e.g. 2=Heartbeat, 3=Heartbeat, 4=Order, ...).

Likewise on the receiving side, FIX expects messages in sequential order. If either side detects a gap of missing sequence numbers, the session will begin a Resend Request to request messages it may have missed. For example, as session receives the following sequence numbers: 1, 2, 3, 12: In this case messages 4-11 were not received or processed. The receiving session would issue a resend request from 4 to 11, and not process any subsequent messages until all sequential messages have ben processed.

There are a number of messages for supporting an stable underlying transport protocol. For business level messages, there are now dozens of pre-defined message types. Common use message types include:

• New Order Single (35=D) - Submitted an order to be executed.
• Execution Report (35=8) - Acknowledging, executing an order
• Cancel Request (35=F) - Request to cancel order or remaining order qty
• Cancel/Correct Request (35=G) - Used to modify original order submission
• New Order MultLeg (35=AB) - For more complex trades with more than one leg
• Allocation Report (35=AS) - Post trade breakdown of account allocations.
• many more...

Many firms often use custom FIX tags to enhance the messages with special values. While this is possible and not uncommon, customizations require clients to certify that they have adapted their FIX processing to account for these changes.

Broker/Dealers who offer their own Algorithmic Trading interfaces add the ability on order submission to use custom FIX tags to identify algorithm name and parameters.

When implementing a new FIX session or offering your clients connectivity via FIX, you often need to simulate the other side. In addition to supporting all versions of FIX and message types, FIXSIM helps you build out application layer functionality.

Another challenge when implementing FIX is testing out your application's ability to handle large volumes of FIX messages. Using FIXSIM, you can stress test your application and test for high volumes.