Almost a year ago, the first version of http://fixparser.targetcompid.com was released. Then, as now, it was the most user friendly and beautiful way to quickly comprehend FIX messages. Since then, several features have been added, including a few in response to user requests.
A few minutes ago, a brand new version of the app was released. It is almost completely redesigned, front to back with complete focus on making your FIX life easier.
Let’s start with a non-feature. The new version adds a note “Your FIX data is never sent to any server, it stays private and local to your machine.” This was always true, just wasn’t posted. FIX parser is a completely client-side app. Once you’ve loaded the web page, you can even disconnect your computer from the internet and the app will continue to work.
On to the new stuff.
Timeline view now shows relevant details, such as symbol, side quantity and reject text right next to the event type itself. This feature alone doubles the utility of FIX Parser.
What’s the best way to double the usefulness once again? Show which events are related to each other. Click on a New Order and you will see fills related to it. Click on a session Reject and you will see the referenced event. Making simple, what used to be a pain.
The look and feel has been updated. The colors contrast better, there is less noise and the focus is squarely on the events. Use the app on your desktop, tablet or even your phone. It works beautifully.
Finally, a great deal of thought and love has been put into the code behind the app. The parsing logic has been completely rewritten to process data much more intelligently.
For the technically minded, the server side story is very interesting in its own right. There is no server side code! The app is served off Google’s cloud storage. Naturally, FIX messages can contain sensitive information, which is why no FIX data is ever sent outside your computer. There is no server to send it to!
The first version was also a labor of love and still lives at http://fixparser.targetcompid.com/v1.0 . This version improves usefulness by an order of magnitude.
There are several more ideas floating around in our heads. If you have an idea, a request or even a complaint, please send a note to email@example.com
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.
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.
FIX is a relatively simple text based protocol (2). Logically, it is just a collection of tags and values:
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.:
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
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:
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:
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.
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.
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.
A few days ago we released http://fixparser.targetcompid.com. It is a very simple tool to translate FIX protocol message tags to their English keywords.
Try it out, share it with your friends and family. Most of all, let us know how to improve it by dropping us a line at firstname.lastname@example.org