WHY IS FIX PROTOCOL NEEDED?
FIX protocol is the blood which flows through the veins of the financial industry.
Say you go to your broker’s website and enter two orders:
buy 100 shares of Google
buy 100 shares of Toyota
Your broker finds that Google trades on NASDAQ and sends your order to KCG, a NASDAQ market maker. KCG finds that GS is offering a better price and, as forced by best execution rules, forwards the order to them. GS fills the order and sends a notification back to KCG, which routes the notification back to your broker.
In parallel, your broker found that Toyota trades in Japan. Since your broker is a very small company, they use a third-party to route international orders. Your Toyota order was forwarded to MPN, which sent the order to a Japanese broker who then sent your order to Tokyo Stock Exchange. When your order is filled, that notification hops through all these companies (and continents) until it comes back to you. All this happens in less than a second.
These two orders touched six different companies. If you enter the exact pair of orders one minute later, it is possible that a different set of companies see your orders.
Every second of the day, financial companies(1) in almost every country communicate with each other. FIX protocol is the language used by all these companies to communicate trading information among themselves.
WHAT IS FIX PROTOCOL?
FIX protocol is a collection of standardized messages, exchanged between two parties.
In order to understand why FIX protocol is the way it is, you have to remember that actual money is exchanging hands and assets are being moved around using this encoding. Great care must be taken to make sure that messages are not intercepted and tampered with. Each transaction must be recorded and must be available on request. If server and client lose their connection, they must be able to re-connect and re-synchronize their state. Exact time of each transaction must be recorded. There must be a mechanism of finding out if one of the parties is no longer responsive. FIX protocol handles all these requirements.
A FIX session generally consists of a server, which listens to incoming connections and a client, which initiates the connection. If you run a trading program on your machine, your program probably contains a FIX client, which connects to a FIX server run by your broker. Your broker, in turn, probably has many FIX clients which connect to servers at various exchanges or other brokers.
A typical session generally looks like this:
Client connects to server and sends logon message. Server responds with a logon acknowledgement. Both parties now consider logon to be successful and start sending each other heartbeats. Client may send a new order request. The server responds with an acknowledgement that the order was received and is now considered “open” and in the market. If the order executes, the server sends notifications of fills. Before the order has finished trading, client can send a request to cancel the order or modify it. If possible, the server will accept and acknowledge this request to cancel or modify the order. Otherwise, this request will be rejected.
WHAT DOES FIX PROTOCOL LOOK LIKE?
FIX is a relatively simple text based protocol (2). Logically, it is just a collection of tags and values:
side=buy|symbol=GOOG|qty=100
Along with business information, these messages also contain infrastructure or logistics information, such as protocol version, total size of the message,id of the client, id of the target, message number, timestamp, error checking checksum, etc.:
version=FIX.4.2|size=118|senderid=CLIENT|targetid=SERVER|side=buy|symbol=GOOG|qty=100|timestamp=10:52am|checksum=123|
To make the specification more modular, the message is divided into three parts: the header, the body and the footer.
The header contains generic information such as fix version, length of message, type of message, sender id, target id, message sequence number, sending time. This information is required. The header may also contain optional information about encryption, routing, flags indicating attempts to resend information, etc.
The trailer is much simpler and generally only contains a checksum value. This checksum is calculated through a standard algorithm and is used to make sure there was no encoding error, either when the message was generated or while it was being transmitted.
The body contains business specific information: order quantities, symbol names, reference ids of orders to be canceled, etc.
You can look at FIX messages and parse them into an easy to understand format at http://fixparser.targetcompid.com
WHAT DOES FIX PROTOCOL REALLY LOOK LIKE?
FIX messages, as they are processed by programs look slightly different from what you saw earlier. Tags are actually numeric values, rather than text descriptions. In other words, an actual FIX message is looks a little more like this:
8=FIX.4.1|9=61|35=A|34=1|49=EXEC|52=20121105-23:24:06|56=BANZAI|98=0|108=30|10=003|
FIX specifications map tags to their descriptions. http://fixparser.targetcompid.com has a handy utility to convert tag numbers to their text descriptions.
There is one minor difference between what is shown here and what FIX messages actually look like. In real FIX messages, the tag/value pairs are separated by special ASCII character ‘\01’ or SOH (which is a non-displaying character), not ‘|’ or pipe:
8=FIX.4.19=6135=A34=149=EXEC52=20121105-23:24:0656=BANZAI98=0108=3010=003
WHAT ELSE?
FIX is good at re-synchronization of state (recovering from disconnects, corrupt data, etc.). Each outgoing message is tagged with a sequence number. When a message is received, the sequence number of the message is checked against the expected sequence number. If the numbers don’t match, the missing messages can be requested again. The party responsible for re-sending messages can chose to send an ‘ignore’ command so time-sensitive messages aren’t transmitted again.
Notice how this differs from some protocols which require an acknowledgement of each message. In FIX, acknowledgements are limited to business level requests, such as new orders, cancel and modify requests.
HOW CAN I LEARN THE DETAILS?
http://www.fixprotocol.org/ provides all the specs and a fairly active forum. Membership to the website is free and the forum members are very helpful to newcomers. http://quickfixj.com/ (java) and http://www.quickfixengine.org/ (C++ with bindings for python, ruby, C#, etc.) are production quality open source implementations of FIX and are used by many companies in the industry.
https://github.com/falconair/fix.js (javascript-node.js) and https://github.com/falconair/lowlevelfix (java) are two FIX implementations by the author. These are certainly not to be used in production, but will prove helpful understanding how FIX can be implemented in code.
Realistically, such detailed knowledge of FIX is not required by most practitioners.
(1) Currently FIX is used to mainly trade Equities (stocks). Slowly other instruments are also being traded with it.
(2) Latest versions of FIX introduce non-ascii encodings. However, most of the street is still on version 4.0 to 4.4, which are text based.