The FIX protocol (Financial Information eXchange) is an open messaging standard that lets trading firms, brokers, and exchanges send orders, quotes, executions, and post-trade data to each other in a common machine-readable format. It began in 1992 as a link between Fidelity Investments and Salomon Brothers, replacing equity orders that had been phoned in, and it is now maintained by the FIX Trading Community, a non-profit standards body.
​

Most explainers stop at the definition. This one walks through a real order message field by field, separates the session layer from the application layer, lays out which versions still matter, and compares FIX with the REST and WebSocket APIs that crypto venues also offer.
​

The FIX protocol is a vendor-neutral language for electronic trading. It defines standard message types for the full trade lifecycle, from market data and quote requests to orders, fills, allocations, and confirmations, so two firms can connect their systems once and trade across many asset classes without building a custom format for each counterparty.
​

According to the FIX Trading Community's protocol overview, messages fall into categories such as order handling, market data, trade reporting, and post-trade processing. Pre-trade messages cover market data, quoting, and liquidity discovery. Trade messages cover orders, executions, and RFQs. Post-trade messages cover allocations, confirmations, and settlement instructions. The same page notes that FIX supports regulatory reporting workflows for FINRA TRACE, the CFTC, the OCC, CIRO in Canada, and ASIC in Australia.
​

The standard is deliberately technology-neutral. The specification states that business messages can ride over TCP/IP, multicast, or WebSockets and can be encoded as classic tag-value text, binary, or JSON. In practice, when people say "FIX" they usually mean tag-value messages over a persistent TCP session, which is what the rest of this article describes.
​

A FIX message is a string of numbered fields written as tag=value pairs, each separated by an invisible control character. Every message has a header that identifies the version, type, sender, and sequence, a body carrying business data such as symbol and quantity, and a trailer ending in a checksum that lets the receiver detect corruption.
​

The separator is the SOH character, ASCII 0x01. Because it does not print, documentation usually shows it as a pipe (|) or ^A. The message is split into header, body, and trailer, and the last field is always tag 10, the checksum.
​

Below is an illustrative FIX 4.4 limit order to buy 500 shares of MSFT at 412.50, with SOH shown as |. The BodyLength and CheckSum values were computed for this exact string.
​

8=FIX.4.4|9=135|35=D|34=215|49=BUYSIDE01|52=20260926-14:30:05.123|56=BROKER01|11=ORD-10045|55=MSFT|54=1|60=20260926-14:30:05.120|38=500|40=2|44=412.50|10=048|
​

Tag names below come from the FIX 4.4 field dictionary; the list of required order fields comes from the NewOrderSingle definition.
​

The broker typically answers with an Execution Report, MsgType 8, first to acknowledge the order and then for each partial or full fill. To pull the order, the client sends an Order Cancel Request (35=F) or Cancel/Replace Request (35=G) that references the original ClOrdID. That request-and-report rhythm is most of what order-entry FIX traffic looks like.
​

Two details trip up newcomers. Tag order matters in the header, since BeginString, BodyLength, and MsgType must come first. And the checksum is computed over the raw bytes including SOH characters, so a message that looks correct after pipes are swapped in will fail validation if the real delimiter was lost in copy-paste.
​

The session layer keeps a connection alive and in order: logging on, exchanging heartbeats, numbering every message, and replaying anything missed. The application layer carries the business content, such as orders, fills, quotes, and market data. Separating them means a trading desk can trust delivery and ordering without every order message handling that logic.
​

The FIX 4.4 message catalog lists seven session-level (administrative) messages: Heartbeat (0), Test Request (1), Resend Request (2), Reject (3), Sequence Reset (4), Logout (5), and Logon (A). Application messages include New Order Single (D), Execution Report (8), Order Cancel Request (F), Market Data Request (V), Market Data Snapshot (W), Quote Request (R), and Quote (S).
​

A session opens with a Logon that sets the heartbeat interval, carried in HeartBtInt (tag 108), and can request a sequence reset through ResetSeqNumFlag (tag 141). After that, each side sends Heartbeats when idle. If a heartbeat goes missing, the counterparty sends a Test Request; silence after that ends the session.
​

Sequence numbers are the core of FIX reliability. Every message increments MsgSeqNum (tag 34). If a receiver sees 215 followed by 218, it issues a Resend Request for 216 and 217, and the sender either replays them or fills the gap with a Sequence Reset. Venues set their own rules around this. Kraken's spot FIX guide describes a daily logical rollover at 22:00 UTC, lasting about 30 seconds, after which trading and market data sequence numbers reset to zero. Coinbase Exchange's connectivity docs state that resend requests are not supported and that sessions reset on Saturdays at 1 PM ET.
​

Most production FIX traffic runs on FIX 4.2, FIX 4.4, or the 5.0 family now published as FIX Latest. Older 4.x versions bundled session and application rules into one specification. The 5.0 line split them, running application messages over a separate transport session called FIXT, so business content could evolve without changing the connection layer.
​

The FIX Trading Community says FIX 4.2 and 4.4 remain supported for legacy implementations, other older versions are archived, and the current standard is FIX Latest, updated incrementally through backward-compatible extension packs. Machine-readable definitions are published through the FIX Latest Orchestra repository.
​

A summary of FIX's evolution describes the move from a monolithic specification through 4.2 to a modular family, with FIXT 1.1 enabling multiple application versions over one session. Alongside tag-value, the family added FIXML (an XML encoding), FAST (a streaming format released in 2005 for multicast market data), and Simple Binary Encoding (SBE), a binary format built for lower latency than text. The FIX Trading Community also maintains FIXP, a high-performance session layer that supports WebSocket among other modes.
​

When onboarding with a counterparty, the version on paper rarely tells the whole story. Each venue publishes its own rules of engagement listing which tags it requires, which it ignores, and which custom tags it adds. Kraken, for example, documents a custom tag 7928 for order-level self-trade prevention. Coinbase publishes downloadable FIX dictionaries for the same reason.
​

FIX connects the buy side, the sell side, and trading venues. Asset managers and hedge funds use it to route orders to brokers, brokers use it to reach exchanges and alternative venues, and exchanges use it for order entry, drop copies, and market data. Technology vendors build order and execution management systems around it.
​

The protocol's standard role is pre-trade and trade communication between buy-side institutions such as mutual funds and sell-side participants such as brokers, exchanges, and ECNs. The FIX Trading Community names banks, asset managers, exchanges, and technology providers as the main users, with coverage spanning multiple asset classes rather than equities alone.
​

Crypto venues have adopted it to court the same institutions. Kraken's FIX 4.4 API is aimed at institutional and high-frequency clients, requires IP whitelisting, and is provisioned through an account manager with assigned CompIDs. Coinbase Exchange runs separate FIX endpoints for order entry, market data, and a dedicated drop copy, over TLS 1.2.
​

Order routing. A portfolio manager's order management system sends a New Order Single to a broker, which returns Execution Reports as the order works. This is the workflow the protocol was originally built for, and it remains the most common.
​

Request for quote. In markets without a continuous order book, such as many fixed income, FX, and OTC trades, the client sends a Quote Request (35=R) to one or more dealers and receives Quote messages (35=S) in return, per the FIX 4.4 message catalog. The FIX Trading Community lists RFQs among core trade messaging, which is why dealer-to-client desks can accept quote requests from many clients through one integration.
​

Market data and drop copy. A Market Data Request (35=V) subscribes to prices, and the venue replies with snapshots (35=W) and incremental updates. A drop copy session, like the one Coinbase Exchange offers on a dedicated endpoint, sends a duplicate stream of executions to a risk or back-office system so fills can be reconciled independently of the trading session that generated them. Compliance and operations teams often care more about the drop copy than the traders do.
​

FIX suits firms that already run FIX engines, need guaranteed message ordering, and trade at volume through a persistent session. REST suits occasional requests such as balances or one-off orders. WebSocket suits streaming prices and account updates to newer applications. Many venues offer all three, and larger desks often run FIX for execution alongside WebSocket for data.
​

The trade-offs are structural rather than about raw speed alone. A FIX session carries built-in sequencing and gap recovery, as the session message set shows. REST is stateless, so each call stands alone and the client must reconcile state itself. WebSocket keeps a connection open but each venue defines its own message schema. Kraken, for instance, markets REST, WebSocket, and FIX APIs side by side, with FIX access gated to institutional clients.
​

The strongest argument for FIX is reuse. A desk with an existing FIX engine can add a new broker or venue by mapping one more rules-of-engagement document, rather than writing a new JSON client. The strongest argument against it is setup cost: certification testing, CompID provisioning, and session management are real work for a team trading small volumes.
​

Getting started with FIX usually means picking a FIX engine library, obtaining the counterparty's rules of engagement and data dictionary, completing connectivity and certification tests in a sandbox, and only then going live. Most of the effort sits in mapping venue-specific tags and handling session edge cases, not in parsing messages.
​

Start with the counterparty's documentation. Coinbase publishes separate production and sandbox endpoints and specifies TLS 1.2 cipher suites. Kraken requires TLS 1.3 and supplies hostnames and ports during onboarding. From there, the practical checklist is:

Some institutional crypto and stablecoin desks now accept orders and RFQs over FIX as well as over chat or API. For how those execution channels compare, see OTC execution vs RFQ for stablecoins, the overview of stablecoin execution methods, and how institutional stablecoin RFQ works.
​