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 some of these questions, 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 allowed the separation of of the transport layer and the message definitions, 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 starts 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 activity can be accomplished, end to end connectivity must be supported. Usually a telnet session to make sure the endpoint is reachable is all you need.
Transport layer connections can be:
Production FIX versions today start with version 4.0 (previous versions has been deprecated). Choice of a FIX version is usually dependant on what the Business/Application will be doing. 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.
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 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 is the version of choice for Fixed Income trading and also more complex Foreign Exchange (FX).
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 Accpetor will determine the sender's 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, which is usually every 60 seconds. This heartbeating allows 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.
As we have seen, there are a number of messages for supporting an stable underlying transport protocol. For business level messages, there are now hundreds of pre-defined message types. Common use message types include:
Many firms often use custom FIX tags to enhance the messages that are pre-defined. While this is possible and not uncommon, concerns should be heeded as any customizations would require clients 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.com service, you can stress test quite easily.