The FIX Protocol
How the Financial Information eXchange protocol became the common language brokers, exchanges and buy-side firms use to send orders and trade reports to each other, no matter what systems each side runs internally.
Before a common standard existed, every broker and exchange connection was its own custom integration — if a fund traded through ten brokers, it maintained ten different message formats, ten different ways of saying "buy 500 shares of AAPL, limit price $190, good for the day." Every new broker relationship meant weeks of bespoke engineering just to place an order. The FIX protocol (Financial Information eXchange) fixed this by defining one standard vocabulary and message structure that essentially the entire industry adopted, so a system that speaks FIX can connect to almost any counterparty with comparatively little custom work.
Tags, values and message types
A FIX message is a sequence of tag=value pairs separated by a delimiter, where each tag is a number with a fixed meaning defined by the standard — tag 55 is always the symbol, tag 54 is always the side (buy or sell), tag 38 is always the order quantity, and so on. A New Order Single message (type D) carries the tags needed to place an order; an Execution Report (type 8) comes back reporting a fill, a rejection, or a cancellation, carrying tags for the price and quantity actually executed. Every FIX session between two counterparties is a continuous logical connection with its own sequence numbers, heartbeats to detect a dropped link, and a resend mechanism if messages are missed — session management that exists precisely because losing track of whether an order was actually sent, or a fill actually received, is unacceptable in a live trading system.
FIX is human-readable in principle — you can eyeball a raw message and pick out tag=value pairs — but it is verbose compared to the compact binary protocols exchanges use for their fastest direct feeds, which is why FIX is the standard for order routing and reporting (where correctness and interoperability matter most) while faster proprietary binary protocols dominate raw market-data distribution and the very lowest-latency order entry.
Worked example: reading a simplified order message
A simplified New Order Single might read:
8=FIX.4.2|35=D|55=AAPL|54=1|38=500|40=2|44=190.00|59=0|
Reading tag by tag: 8=FIX.4.2 is the protocol version, 35=D says this is a New Order Single, 55=AAPL is the symbol, 54=1 means side "buy," 38=500 is quantity 500 shares, 40=2 means order type "limit," 44=190.00 is the limit price, and 59=0 means time-in-force "day." Every field is unambiguous because the tag numbers are standardized — a receiving system doesn't need to guess what "the third field" means, because tag 44 is always price regardless of which counterparty sent the message or which order it was.
What this means in practice
Almost every order management and execution management system in the industry speaks FIX for connecting to brokers and many exchanges, so understanding tag-based messages is a baseline skill for anyone building or debugging trading infrastructure. Firms racing for the lowest possible latency on order entry often supplement or replace FIX with an exchange's proprietary binary protocol for that specific link, but even then FIX typically remains the standard for everything else — broker relationships, post-trade reporting, and the vast majority of order flow that isn't microsecond-sensitive.
When debugging a FIX issue, the fastest first step is to look up the specific tag numbers in the message against the FIX dictionary rather than guessing from context — tag semantics are fixed by the standard and don't vary by intuition.
Related concepts
Practice in interviews
Further reading
- FIX Trading Community, FIX Protocol Specification (FIX 4.2/4.4 overview)