FIX API for Crypto Exchange Connectivity: A Practical Guide

FIX, REST or WebSocket: which interface for which job?

Crypto venues rarely offer one interface. Each one suits a different job, and most desks end up using two or three together. The FIX Trading Community maintains FIX, and FIX 4.4 remains the version most counterparties still speak.

The short rule: choose FIX where the other side of the connection is institutional software that already speaks it, choose WebSocket for live data and for crypto-native order flow, and keep REST for account actions. Whether a venue lets you mix them on one account is a fair question to ask before you sign. The wider picture of venues and connection types is in crypto venue connectivity.

How do FIX sessions work in a 24/7 market?

FIX runs over a session. Each side keeps numbered messages in both directions, and the numbering is how both sides know nothing was lost. The FIX session layer defines the rules. The pieces a desk meets in practice are:

• Logon and logout. The session opens with a Logon message (35=A) and ends with a Logout (35=5).
• Heartbeats. Each side sends a Heartbeat (35=0) at an agreed interval, and a Test Request (35=1) asks the other side to prove it is alive. A missed heartbeat is how a dropped connection is noticed.
• Sequence numbers. Every message carries a number. A gap triggers a Resend Request (35=2), and a Sequence Reset (35=4) is how both sides agree to move on.
• Rejects. A session-level Reject (35=3) means the message was malformed. A Business Message Reject (35=j) means it was well formed but could not be processed.

Equity venues usually reset sequence numbers at a daily boundary. Crypto trades continuously, so the question to ask each counterparty is what its reset and maintenance policy is, and how the desk should behave when the venue restarts. A desk that does not handle a reconnect cleanly can resend an order it thought was lost, which becomes a duplicate. Good practice is to store sequence numbers durably, resend only what the other side asks for, and treat a possible duplicate as a reconciliation problem, not a retry.

Which order types and messages matter?

The core of order entry is a small set of messages.

Orders carry a side, a quantity, an instrument, an order type, a price where relevant and a time in force. Crypto adds questions that equity FIX rarely raises. How is quantity expressed, in the base asset or the quote asset? How does the venue name its instruments? Which order flags, such as post-only, does it support, and does it use a custom tag for them? Is the account identified in the message, and does the venue hold balances per sub-account? Most venues document these as custom tags per counterparty, which is why the FIX Trading Community also publishes FIX Orchestra, a machine-readable way to describe how a venue uses the standard.

What is drop copy and do you need it?

Drop copy is a second FIX session that delivers a copy of execution reports for an account to another party, without that party being able to trade. It exists so that risk, compliance, operations or a prime broker can see activity as it happens, independent of the trading session.

You need it when someone other than the trader has to watch the account in real time: a risk team enforcing limits, a clearing or prime relationship, or an operations team that reconciles fills. You can often live without it if one system places the orders, sees the fills and does the reconciliation. It matters most when more than one system can trade the same account, since only an independent copy shows what actually happened. Ask each venue and each vendor whether drop copy is offered, for which accounts and with what message set.

What does FIX certification involve?

Before a counterparty lets you trade live over FIX, it normally tests your connection. The steps are broadly the same across venues, though each runs its own process and timeline.

1. Specification. The venue sends its FIX dialect: supported message types, required and custom tags, and order-type rules.
2. Test environment. You connect to a non-production session and send the scripted messages.
3. Scenarios. The venue checks that you handle logon, heartbeats, new orders, cancels, replaces, partial fills, rejects, and a forced disconnect and resend.
4. Rate and risk limits. Message limits and any pre-trade limits are agreed.
5. Go-live. Production credentials, IP allow-lists and contacts for incidents are exchanged.

The usual causes of delay are on the client side: sequence handling that fails the reconnect test, and unclear ownership of who answers a venue's call at 2 a.m. Ask each counterparty for its timeline in writing, since none is stated here, and plan certification as a project per venue, not a one-off. A platform that already holds the certified connections, so the desk integrates once, removes most of this repetition.

How do you connect an OMS or EMS over FIX?

Many desks already run an order management system or execution management system and want crypto to appear inside it, not in a separate screen. Buyers describe this as wanting to embed crypto order tickets into the OMS their team already uses. FIX is the usual bridge because most institutional OMS and EMS products already speak it.

There are three common patterns.

• OMS to a crypto platform over FIX. The OMS sends orders to the platform as it would to any broker, and receives execution reports back. The platform fans the order out to venues.
• Ticket embedded in the OMS. The OMS presents the platform's order ticket and market data inside its own screens, so a trader never leaves the system. This usually needs a vendor-to-vendor integration, not just a FIX session.
• OMS plus drop copy. The desk trades elsewhere and the OMS receives a drop copy so positions and compliance stay in one system.

Three things break these integrations: instrument identifiers that do not match, quantity conventions that differ between the OMS and the venue, and allocation, where one block fill must be split across several accounts after the fact. Test all three before go-live. For large clips, see crypto block trading, and for routing across venues behind the connection, see smart order routing in crypto.

What does a desk need for FIX connectivity?

• A FIX engine you can operate. Durable session state, clean reconnects and duplicate protection.
• A written dialect per counterparty. Tags, instruments and order-type rules, kept current.
• Certification capacity. People and test time for every new venue, or a platform that has done it.
• Risk checks before the message leaves. Balance, credit, size and region limits applied at the edge.
• Reconciliation. Fills compared against the venue's records, ideally through drop copy.
• Monitoring. Alerts on a missed heartbeat, a sequence gap or a reject spike.
• A single order model. FIX, REST and WebSocket should resolve to the same orders and positions, or the desk reconciles three versions of the truth.

How Liquid Mercury's stack does it

Liquid Mercury's materials describe a Mercury Pro API suite with FIX, Binary, REST and WebSocket interfaces for buy-side and sell-side workflow automation. The live glossary entry states that Mercury Pro exposes FIX 4.4 and 5.0 SP2, with custom tags documented per counterparty, and with FIX, REST and WebSocket bound to one canonical order model. The connection tier in the Liquid Mercury architecture takes orders over REST, WebSocket and FIX 4.4, covering order entry, RFQ and block-type workflows across spot, futures, perpetuals and options, with pre-trade checks on order size, price reasonability and rate limits before an order reaches the book. Orders pass through the Risk Engine, which can check available balance, available credit, region and size limits.

For an OTC desk, Mercury OTC puts RFQ, RFS and streaming quotes behind a white-label front end and connects custody, KYC and liquidity providers, so the desk does not build each adapter. Exchange and ECN operators can see the connection, order book and market data tiers on the exchanges and ECNs solution page. Trading desks can see the trader-facing side in Mercury Pro. The full venue and liquidity provider picture is in crypto venue connectivity.