FIX Protocol Explained: How Trades Really Travel in FX and Crypto

Imagine you run a small chai stall outside a busy railway station. Every morning, three suppliers deliver milk, sugar and tea leaves. Each one insists on a different system: one wants a phone call, one wants a handwritten note, one wants a WhatsApp voice message at 6am. You'd lose your mind before lunch.

That's roughly the problem institutional trading faced before 1992. Every broker had its own format for sending orders. Banks and asset managers had to build a separate connection for each counterparty, and if a message arrived garbled, someone might have shouted the details down a phone line. Then a small group of engineers at Fidelity Investments and Salomon Brothers wrote a shared standard called the Financial Information eXchange, or FIX. Think of it as everyone agreeing to speak the same language, so nobody has to learn twelve dialects before breakfast.

What FIX actually is

FIX is a messaging standard for communicating trading information in real time. It defines what business information gets exchanged and what it means — an order, an execution, a cancellation — rather than how it physically travels across a network. That distinction matters. The same FIX message can be carried over a plain internet connection, a private leased line, or a newer transport like WebSockets, and it can be encoded as traditional tag-value text, binary, or JSON. The meaning stays the same.

It's maintained by the FIX Trading Community, a non-profit body whose membership includes buy-side institutions, broker-dealers, exchanges, regulators and technology vendors across more than 50 countries. It's vendor-neutral and open, which is precisely why it spread.

Fields, tags and the anatomy of a message

At the ground level, FIX is built from fields — each a number paired with a value. A tag is the numeric label; the value is the data. Tag 55 is the instrument symbol, for example. Because every message carries its own labels, FIX messages are self-describing: any system that speaks FIX can read them without a separate decoder sheet.

Related fields are bundled into components, which represent a logical idea — parties to a trade, instrument details, allocations. Components get reused across many message types, which keeps the standard consistent and extensible. Messages themselves are grouped into categories: order handling, market data, trade reporting, post-trade processing.

A message has a header, a body and a trailer. The trailer's final field is a checksum — a three-digit number derived by summing the ASCII values of the characters in the message and taking the remainder after dividing by 256. FIX is nothing if not thorough about catching typos.

The most famous message type is New Order Single (type D), which submits an order to a broker for execution. Its counterpart is the Execution Report (type 8), which acknowledges, fills, rejects or cancels the order. Amendments use cancel/replace messages; cancellations use order cancel requests. A single equity trade typically produces a short back-and-forth of several of these before everyone agrees on what happened.

Two instruction fields are worth knowing. Handling instructions tell the broker how to treat the order on its own trading floor. Execution instructions give explicit directions about how the order should be executed. There's also a staleness check: the transaction time field lets the receiver apply business rules to judge whether an order has been sitting around too long during a communication problem.

Sessions: the handshake before the conversation

FIX runs on two layers, and conflating them is where newcomers get lost.

The session layer manages the connection. One side is the initiator, the other the acceptor. Before any orders flow, they exchange a Logon message. Then both sides send periodic Heartbeats — typically every 30 or 60 seconds — to confirm not just that the pipe is open but that the counterparty is still awake and processing. Miss a heartbeat, and a Test Request goes out. Silence after that means the session is considered lost.

The clever part is sequence numbers. Every message carries a number that increments by one. If the receiver spots a gap — say messages 4 through 11 never arrived — it sends a Resend Request for the missing range, and nothing after the gap is processed until it's filled. This is guaranteed delivery built into the protocol itself. In versions up to FIX 4.4, the session and application layers sit in one specification; FIX 5.0 split them so the business content could evolve independently.

The application layer carries the actual business content: orders, executions, market data, post-trade instructions. Session messages keep the line alive; application messages make money move.

Versions matter in practice. FIX 4.2 and 4.4 remain the most widely deployed in production, partly for proven stability and partly because of network effects — if your counterparties all speak it, so do you. There's no universal upgrade path; the version used on any given session depends on what both sides support, and it's negotiated during onboarding and certification.

What FIX means for FX specifically

FIX handles FX spot and forward trading comfortably, and FIX 4.4 is the version often chosen for more complex FX work. The standard includes fields for what are called forex accommodation trades, where a broker executes a currency trade alongside a securities trade — you flag the request and specify the intended settlement currency, and the broker reports the result back.

One detail traders notice: for FX limit orders, the price field should carry the all-in rate — the spot rate adjusted for forward points — rather than a raw spot number. Small thing, large consequences.

Straight forex trades can also be requested directly through the order message. In practice, FX brokers and prop firms validate header, trailer, session and order-routing fields during logon, replay, recovery and certification testing, and they confirm things like sender IDs, target IDs, symbol dictionaries and venue fields during technical onboarding. That onboarding step is where much of the real work lives.

Drop copies: the quiet safety net

Here's an idea that sounds almost too simple. A drop copy is a second stream of trading messages — orders, executions, cancellations — sent to a separate destination. It's the financial equivalent of cc-ing someone on an email, except the someone is usually a compliance team, a risk desk, or a back-office system.

Crucially, drop copy sessions are typically read-only. They cannot enter, modify or cancel orders. They just report. That makes them useful for reconciliation, real-time risk monitoring and building an audit trail.

Exchanges often run the drop copy service themselves: order messages headed to the matching engine are copied to a drop copy feed and delivered to permissioned recipients. Messages sent through drop copy can carry a marker field indicating they're copies of another message, so systems don't confuse them with the originals. On some venues, drop copy sessions don't count against the session limits allocated for order entry — a sensible bit of plumbing, since monitoring shouldn't compete with trading for capacity.

Configuration choices matter here. A drop copy session can be set to deliver compliance-oriented messages with high-precision timestamps, useful for regulatory reporting in jurisdictions like the EU. It can be scoped to a single participant, a clearing member, or a broader set. And it can be arranged to capture activity regardless of whether the original orders arrived via FIX or a REST API. One caveat worth flagging: message buffering while disconnected is often turned off by default for drop copy sessions, so a dropped connection can mean missed messages rather than a queue waiting patiently.

What it costs you to get this wrong

FIX exists to remove friction, but it doesn't remove the physical world. Messages travel over wide-area networks, and latency — how long a message takes — jitter — how much that time varies — and packet loss all affect execution quality. A system calibrated to expect an acknowledgement within a certain window behaves unpredictably when that window wobbles. Even occasional packet loss can trigger a cascade of resend requests that slows the whole flow.

Which is why certification testing exists. Counterparties run session establishment tests, message conformance checks and volume stress tests on dedicated environments before going live. Testing should include behaviour under packet loss and latency, because production networks surface assumptions that a tidy test environment never will.

Custom tags above the standard range let firms pass proprietary parameters — an algorithm name, an urgency level — alongside normal order fields. But any counterparty that needs to process them must explicitly support them, and certification usually covers exactly that.

The honest caveats

FIX isn't the only option. FAST handles high-volume market data with binary compression, and Simple Binary Encoding targets the most latency-sensitive environments where microseconds carry measurable cost. Many exchanges run FIX for institutional order entry alongside their own binary protocols for the exchange-facing leg. They're complements, not rivals.

Regulatory specifics — which drop copy fields are mandatory, which timestamps must be captured, which jurisdictions require what — vary by country and venue. The rules are not universal, and this article can't tell you what applies to your situation. Check with your counterparty, your compliance team, and the relevant regulator before assuming anything.

What FIX does offer is a shared vocabulary that has held up for more than three decades. It's not glamorous. It's the plumbing. But when the plumbing works, nobody notices — which is arguably the highest compliment infrastructure can receive.