The standard language for electronic trading communication.
FIX (Financial Information eXchange) is a messaging standard used by financial institutions to communicate trading information electronically. Developed in 1992 by Salomon Brothers and Fidelity Investments, FIX has become the dominant protocol for order routing, execution reporting, and market data distribution across equities, fixed income, derivatives, and foreign exchange markets.
For brokers, FIX is how you connect to institutional liquidity providers, exchanges, and professional clients. Understanding FIX is essential for anyone operating or evaluating multi-asset trading infrastructure.
FIX is a session-based protocol. Two systems establish a FIX session (a persistent connection), then exchange messages using a standardised format. Each message has a type (new order, execution report, market data snapshot) and a set of fields (tags) that carry the data.
Key message types: New Order Single (tag 35=D), Execution Report (35=8), Order Cancel Request (35=F), Market Data Request (35=V), and Market Data Snapshot (35=W). These cover the core of order lifecycle management.
Tag-value format: FIX messages are structured as tag=value pairs separated by delimiters. For example: 35=D|49=BROKER|56=LP|55=EUR/USD|54=1|38=100000|40=2|44=1.0950 — a limit buy order for 100,000 EUR/USD at 1.0950.
Every FIX message begins with three header tags: BeginString (Tag 8) declaring the protocol version, BodyLength (Tag 9), and MsgType (Tag 35) identifying the message type. MsgType determines which body tags are required and how the receiver processes the message.
NewOrderSingle (MsgType=D) is the workhorse of FIX trading. It carries the instrument (Tag 55, Symbol), side (Tag 54: 1=Buy, 2=Sell), order type (Tag 40: 1=Market, 2=Limit, 3=Stop), quantity (Tag 38, OrderQty), and a unique ClOrdID (Tag 11) that the client uses to track and reference the order in later messages.
ExecutionReport (MsgType=8) flows back from the broker. A single order typically produces several reports — one for the acknowledgement, one for each partial fill, one for the final state. The OrdStatus (Tag 39) and ExecType (Tag 150) fields together describe what just happened to the order.
MarketDataRequest (MsgType=V) and MarketDataSnapshotFullRefresh (MsgType=W) handle quote and order-book distribution. OrderCancelRequest (MsgType=F) and OrderCancelReplaceRequest (MsgType=G) handle cancels and modifications. TraderEvolution's FIX 4.4 implementation supports the full message set required for production order entry, market data, and post-trade reporting.
LP connectivity: Brokers use FIX to connect to liquidity providers. The order routing engine sends FIX messages to LPs and receives execution reports back. TraderEvolution's 80+ integrations include many FIX-based connections.
Institutional clients: Professional traders, hedge funds, and other brokers connect to your platform via FIX. They send orders from their OMS (Order Management System) directly to your back-end. TraderEvolution's FIX API supports inbound client connections.
Exchange connectivity: Some exchanges accept orders via FIX. The platform translates internal orders into FIX messages and routes them to the exchange for execution.
An Order Management System (OMS) is the system institutional clients use to manage orders across multiple brokers and venues. When a hedge-fund trader sends an order from Bloomberg AIM, Charles River, or Fidessa, the OMS routes it to the chosen broker over FIX.
For the broker, accepting OMS flow means running a FIX gateway that authenticates incoming sessions, validates orders against risk limits, routes them to the matching engine, and returns ExecutionReports as fills occur. DropCopy sessions — read-only FIX sessions that mirror execution data to a third system — are common for post-trade reconciliation, regulatory reporting, and parallel risk monitoring.
TraderEvolution's FIX API supports inbound OMS connections natively. Each institutional client receives a dedicated FIX session with its own credentials, instrument permissions, and per-session risk parameters. DropCopy is included for clients that feed executions to their own back-office, compliance, or analytics systems.
FIX is not the only option. Modern trading platforms support multiple connectivity protocols:
REST API: HTTP-based, request-response. Good for administrative operations, historical data, and integration with web services. TraderEvolution uses REST for the BackOffice API and parts of the Client API.
WebSocket: Full-duplex, real-time. Ideal for streaming market data and account events to front-ends. The Client API uses WebSocket for live data subscriptions.
MCP (Model Context Protocol): Structured tool access for AI agents. TraderEvolution's MCP Server provides 31 tools built on top of the Client API for AI-driven trading.
REST and FIX serve different roles in trading infrastructure. Most modern platforms use both, each handling the workload it suits best.
REST is request-response and stateless. The client sends a request, the server returns a response, and the connection closes. This fits administrative operations — fetching account balances, retrieving trade history, configuring instruments — where 50–200 ms latency is acceptable. It is simple to implement and supported by every modern language.
FIX is session-based and persistent. Two systems establish one session and exchange messages over it for hours or days. Sequence numbers track every message, missed messages can be replayed via Resend Request, and heartbeats keep the connection alive. The session overhead is paid once; subsequent messages process in microseconds rather than milliseconds.
For institutional order entry, market data distribution at scale, or any latency-sensitive workflow, FIX outperforms REST by an order of magnitude. For administrative tasks and integration with web services, REST is the more practical tool. TraderEvolution exposes both: FIX API for institutional connectivity, REST + WebSocket for the Client API and Back-Office API.