A single FIX order message looks like this once you strip the framing: 35=D for a new order, 55=EURUSD for the instrument, 54=1 for buy, 38=100000 for quantity, 40=2 for a limit order, 44=1.0842 for the price. Fields are numbered tags, separated by an invisible byte, and the whole thing is under 200 characters. That is the Financial Information eXchange protocol, and it has been the wire format between banks, brokers and liquidity providers since the early 1990s.
Traders meet FIX in two situations. Either they have grown past what a retail terminal can do and want to submit orders programmatically at low latency, or they are building a firm and discover that every liquidity provider quotes their pricing over a FIX session rather than a friendly web API. Both cases reward understanding the mechanics rather than treating the connection as a black box.
Sessions, sequence numbers and why FIX is stateful
A REST API is stateless. You send a request, you get a response, nothing is remembered. FIX is the opposite. You open a TCP socket, send a Logon message (35=A), and from that moment both sides count every message. Message one, message two, message three. If your counterparty receives sequence 47 when it expected 45, it sends a Resend Request and the session repairs itself by replaying what was missed.
That design exists because orders must not be lost or silently duplicated. Heartbeats flow every 30 seconds by default, and a missed heartbeat triggers a Test Request before the session is considered dead. When a connection drops mid-day, the two sides reconnect and continue from the sequence they had, which means an execution report sent while you were offline still reaches you. At the start of each trading day the sequence resets to 1.
The practical consequence: a FIX client is not something you write in an afternoon. It has to persist sequence numbers to disk, handle resend logic, cope with the counterparty resetting sequences unilaterally, and reconnect without duplicating orders. Most firms use an existing engine rather than writing one, and even then the certification process with a liquidity provider takes days of message-by-message testing.
The message types that matter
FIX has hundreds of message types. In practice a trading connection uses six or seven. New Order Single (35=D) submits an order. Execution Report (35=8) is the only way you ever learn what happened to it, and you will receive several per order: acknowledged, partially filled, filled, or rejected. Order Cancel Request (35=F) and Order Cancel/Replace Request (35=G) modify a live order. Market Data Request (35=V) subscribes to prices, and Market Data Incremental Refresh (35=X) streams the updates.
The detail that catches people is that a cancel is a request, not a command. You send 35=F and you wait. The order may already have filled at the venue while your cancel was in flight, in which case you get a Cancel Reject and a fill, in that order or the reverse. Any position tracking built on the assumption that cancels always succeed will drift out of sync within a week. The same race condition explains most of what traders experience as requotes and execution oddities on retail platforms, which typically sit on top of a FIX session somewhere upstream.
Price feed and trade flow are usually two sessions
Liquidity providers almost always split the connection. One session carries market data, the other carries orders. They may run on different ports, sometimes different hosts, and they are certified separately. The reason is throughput: a streaming EURUSD book can produce thousands of updates a second, and you do not want that traffic sharing a socket with order acknowledgements.
Market data arrives as an incremental book. You receive a snapshot with the current bid and offer levels, then a stream of deltas: add this level, change that quantity, delete this entry. Your side rebuilds the book in memory. Get the delta handling wrong and your depth of market display drifts into fiction while the top of book still looks plausible, which is a nasty class of bug because it fails quietly.
FIX carries no risk logic. It will happily transmit an order that blows through your exposure limits. Pre-trade risk checks live in your own systems, before the message is sent, and building them is your responsibility rather than the protocol's.
FIX 4.2, 4.4 and why versions still fight
The protocol has versions, and the industry never converged on one. FIX 4.2 dates from 1998 and is still common in equities and with some older venues. FIX 4.4 from 2003 is the default for FX and CFDs and is what most liquidity providers in the retail-facing world will offer you. FIX 5.0 and FIXT separated the session layer from the application layer, which was technically sensible and commercially ignored by much of the market.
On top of the version sits a dictionary. Every counterparty adds custom tags in the 5000 to 9999 range for things the standard never covered, and every counterparty documents them differently. Connecting to three liquidity providers means three dictionaries, three sets of quirks, and three certification cycles. This is the real cost of a multi-LP setup, and it is why aggregating several liquidity providers is an engineering project rather than a configuration change.
Should a trader use FIX?
For most individual traders, no. A FIX connection is typically offered above a minimum monthly volume, requires a cross-connect or at least a VPS in the same data centre as the matching engine, and gives you no chart, no order ticket and no journal. You are writing all of that yourself. The gain is measured in single-digit milliseconds and in control over exactly how orders are routed.
The traders for whom it pays are running automated strategies where fill quality dominates returns and where a platform round trip is a meaningful share of the edge. If your strategy holds positions for hours, FIX buys you almost nothing that a well-built platform API does not. If you are testing whether latency matters to you, measure it first: log your intended price and your fill price for a few hundred trades and look at the distribution of the difference. That is slippage, and if it is small and symmetric, your bottleneck is elsewhere.
For firms the calculation is different. A broker without a FIX session to at least one liquidity provider has no way to pass risk to the market, which makes the connection a licence to operate rather than an optimisation. That is why the trading stack we build at SINGUARD treats FIX connectivity as infrastructure rather than a feature, and why the eTrader platform is designed to sit above whatever LP mix a firm ends up certifying against.
What FIX does not solve
People sometimes expect FIX to fix bad execution. It will not. If the liquidity behind the session is thin, or the provider applies last look with a long hold time, a faster protocol simply delivers the same rejection sooner. Message format and liquidity quality are separate problems, and the second one is decided by commercial terms, not by tags. Ask a prospective provider for reject rates and hold times in writing before you ask about their FIX specification.
Trading on any protocol carries a high risk of loss, and a low latency connection increases the speed at which mistakes are executed as much as it increases the speed of good decisions.
"People ask me for FIX access thinking it will fix their fills. Nine times out of ten their problem is the liquidity behind the session, not the milliseconds in front of it."
— Alex Onta, Executive Director, SINGUARD
Key Takeaways
- FIX is a stateful session protocol with sequence numbers, heartbeats and resend logic, so a client has to persist state and handle reconnects without duplicating orders.
- Only a handful of message types matter in practice: new order, execution report, cancel, cancel/replace, market data request and incremental refresh.
- Price and order flow normally run as two separate sessions, certified separately, and each liquidity provider brings its own custom tag dictionary.
- A FIX connection improves speed and control, not liquidity quality; check reject rates and hold times before comparing protocol specifications.
Frequently Asked Questions
Is FIX API faster than a REST API?
Usually yes, because FIX runs over a persistent TCP session with a compact binary-framed text format and no HTTP overhead per message. The gain is measured in milliseconds and only matters for strategies where fill quality drives returns.
Can a retail trader get a FIX connection?
Some brokers offer FIX to clients above a minimum monthly volume, often alongside a colocated server requirement. You receive no chart or order ticket, so you have to build the whole trading application yourself.
Which FIX version do FX and CFD firms use?
FIX 4.4 is the common default for FX and CFDs, with FIX 4.2 still present at older venues. Each counterparty also publishes custom tags, so every new connection needs its own certification cycle.
About the Author
Alex Onta is an Executive Director at SINGUARD. He built eTrader, the terminal, the mobile apps, eTrader Broker, Copytrading, Business and Community, along with the worldwide clustered-server infrastructure it all runs on, with his brother Roman Onta helping on the design, and he leads that division today. Together with Roman he builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals, and the two of them carry worldwide compliance, payment processing and international business structuring side by side. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.