Binance Spot FIX API

TL;DR

Binance runs a first-party FIX 4.4 API for its Spot exchange, and the Spot FIX API is scoped to Spot alone. It exposes three FIX session types — Order Entry, Drop Copy, and Market Data — each on its own TCP+TLS endpoint. The session layer is standard FIX 4.4 with four absences that catch integrators off guard: no resend requests, no order status query, no fixed maintenance window, and no key type other than Ed25519.

Binance Spot FIX at a glance

Binance is one of a limited set of crypto venues with a first-party FIX API. For how it compares across the market — protocol versions, session models, and venue-specific quirks — see which crypto exchanges support FIX.

What Binance's FIX API covers

At Binance, FIX support means three session types — Order Entry, Drop Copy, and Market Data — each on a separate endpoint and gated by API-key permission. Every session is a native TCP + TLS connection (or a local TLS proxy such as stunnel), and Binance instructs clients to send SNI during the handshake and validate the certificate against the hostname — a client that does not may receive an unexpected certificate and fail the handshake. Requests carry a 10-second processing timeout (-1007 TIMEOUT); a timeout does not confirm failure, so the order status should be queried rather than assumed.

A binary alternative, FIX SBE (Simple Binary Encoding), is offered by all three services on two additional ports (schema versions rotate on a deprecation cycle, so check the live schema before building against one): on 9001 the client sends ordinary FIX and receives SBE responses, and on 9002 SBE is used in both directions.

Where Binance FIX departs from the standard

A FIX engine written against the 4.4 specification will connect to Binance, and then fail in ways the specification does not predict.

The recovery row is the one that reshapes an architecture.

Session recovery on Binance Spot FIX is reconnect-and-reconcile, not gap-fill. Because there is no OrderStatusRequest (H) in the FIX message set, the reconciliation step always leaves the order-entry session.

Authentication — Ed25519 only

The single most distinctive rule: FIX sessions accept Ed25519 keys only. Unlike Binance's REST and WebSocket APIs, which also accept other key types, FIX requires an Ed25519 key provisioned with the FIX permission — an existing key of another type will not work.

The Logon (A) message must be the first message the client sends, and it can be sent only once per session. Username (553) carries the API key and RawData (96) carries the signature. The signed payload is the SOH-joined concatenation, in this order, of MsgType (35), SenderCompID (49), TargetCompID (56), MsgSeqNum (34), and SendingTime (52); sign it with the Ed25519 private key and base64-encode the result. On messages from the client, TargetCompID (56) must be SPOT.

Both SenderCompID (49) and TargetCompID (56) are capped at 8 characters by the regex ^[a-zA-Z0-9-_]{1,8}$, and SenderCompID must be unique across the account's active sessions. Client-supplied identifiers are more generous: ClOrdID (11), OrigClOrdID (41), MDReqID (262), ClListID (25014), and OrigClListID (25015) follow ^[a-zA-Z0-9-_]{1,36}$.

Session mechanics in detail

The exact values and tags behind those departures:

• Heartbeat: HeartBtInt (108) is negotiated during logon, with accepted values between 5 and 60 seconds.
• Sequence numbers: MsgSeqNum (34) must increase by exactly 1 — any value that would create a gap is rejected. SEQNUM is a 32-bit unsigned integer that rolls over to 0 after 4,294,967,295.
• A clean logout matters: if the client does not send Logout (5) before disconnecting, its SenderCompID (49) cannot be used to establish a new session for twice the HeartBtInt interval. The connection-attempt counter is released on a similar delay, so an aggressive reconnect loop can lock itself out of the venue it is trying to reach.
• Maintenance: a News (B) message arrives every 10 seconds carrying a countdown to disconnection. Binance removed every mention of a fixed interval before shutdown from its documentation in June 2026, so the countdown is the only warning a client gets.
• Message ordering: MessageHandling (25035) selects UNORDERED (1) or SEQUENTIAL (2) processing by the matching engine.
• Account-wide fan-out: by default, every order-entry session receives all of the account's ExecutionReport (8) and ListStatus (N) messages, including those from other sessions and non-FIX APIs. ResponseMode (25036) changes this: EVERYTHING (1) is the default, and ONLY_ACKS (2) turns the ExecutionReport push off entirely.
• Timestamps: UTCTIMESTAMP accepts second, millisecond, or microsecond precision from the client, but messages from the exchange always carry microseconds.
• Rejects: malformed or unknown-symbol messages receive a Reject (3) with the reason in Text (58) and ErrorCode (25016).

Symbology on Binance FIX

Binance expresses instruments as concatenated symbols with no separator — Symbol (55) is, for example, BTCUSDT or LTCBNB. Any integration that normalizes across venues has to reconcile this against a delimited canonical form (such as BTC/USDT).

Order types and time-in-force over FIX

At the FIX-tag level, OrdType (40) has five values — MARKET (1), LIMIT (2), STOP (3), STOP_LIMIT (4), PEGGED (P). The same value 3 appears as STOP in NewOrderSingle and as STOP_LOSS in ExecutionReport. Binance's own order types are expressed by combining OrdType with trigger fields:

• Order types (the canonical Binance list): MARKET, LIMIT, LIMIT_MAKER, STOP_LOSS, STOP_LOSS_LIMIT, TAKE_PROFIT, TAKE_PROFIT_LIMIT.
• LIMIT_MAKER has noOrdTypeof its own: it is 40=2 plus ExecInst (18) = 6, which the FIX specification calls PARTICIPATE_DONT_INITIATE.
• Trailing variants of the stop and take-profit types are built with TriggerTrailingDeltaBips (25009) alongside the trigger-type fields, rather than with a separate order type.
• Pegged orders sit outside the canonical list: over FIX they are a distinct OrdType value (P), while over REST a peg is set with parameters layered onto an ordinary order.
• Time-in-force (TimeInForce (59)): GTC (1), IOC (3), FOK (4).

One status does not survive the translation into FIX. EXPIRED_IN_MATCH, which Binance reports elsewhere, has no FIX equivalent and arrives as EXPIRED in OrdStatus (39). Reconciliation logic that distinguishes the two on REST will collapse them on FIX.

Order lists are supported over FIX through NewOrderList (E): OCO, OTO, OTOCO, OPO, OPOCO. FIX order entry also includes mass cancel (OrderMassCancelRequest, q), atomic cancel-replace (XCN), and amend-keep-priority (XAK).

Self-trade prevention (STP)

STP is set per order via SelfTradePreventionMode (25001). As of September 2026 Binance Spot documents six modes: NONE, EXPIRE_TAKER, EXPIRE_MAKER, EXPIRE_BOTH, DECREMENT, TRANSFER. Both the FIX message definitions and the enums reference list all six, including TRANSFER — though the STP FAQ still opens by saying there are five, then enumerates six immediately below.

Behaviour in brief: NONE exempts the order; EXPIRE_TAKER, EXPIRE_MAKER, and EXPIRE_BOTH expire the taker, the maker, or both remaining quantities; DECREMENT reduces both orders by the prevented quantity (the smaller order expires, or both if equal); TRANSFER behaves like DECREMENT within one account and, across accounts sharing a tradeGroupId, additionally transfers the last prevented quantity and its notional between them.

Rate limits and delivery

The shape of these limits is stable even when the numbers move: order entry is provisioned two orders of magnitude more generously than drop copy, and market data sits between them. Current values (snapshot, September 2026 — re-check against live docs, as these change):

• Order Entry: 10,000 messages / 10 seconds.
• Drop Copy: 60 messages / 60 seconds.
• Market Data: 2,000 messages / 60 seconds; a single connection may subscribe to at most 1,000 streams.
• Connection limits: market data is provisioned for many more connections than order flow. Order Entry and Drop Copy — 15 connection attempts / 30 seconds, maximum 10 concurrent TCP connections per account; Market Data — 300 attempts / 300 seconds, maximum 100 concurrent.
• Breaching the message limit triggers an immediate Logout (5) and disconnection. The limit counts client messages only; what the server sends does not consume it.
• Drop Copy data is delayed by 1 second.
• Unfilled order count is tracked per account; exceeding it causes further orders to be rejected. Orders that fill do not accumulate against it, so a consistently filled flow can run continuously.
• Reading your own limits: LimitQuery (XLQ) returns a LimitResponse (XLR) carrying order rate, unfilled order count, and message limit usage. It is the only way to see current consumption from inside the session.
• Timing security: RecvWindow (25000) defaults to 5000 ms on Logon (max 60000 ms); a request whose SendingTime (52) is beyond serverTime + 1 second is rejected.

What catches integrators out

1. The Spot FIX API stops at Spot. Its scope is the Spot exchange, so derivatives and options are reached through their own APIs rather than through this session.
2. The key comes first. Provision a fresh Ed25519 key with the FIX permission before anything else — no other key type will log on.
3. Design for reconcile, not replay. No gap-fill and no order status request means a dropped session is rebuilt from Drop Copy or REST.
4. A dirty disconnect locks your session name. Skipping Logout (5) makes the SenderCompID unusable for twice the heartbeat interval, so an aggressive reconnect loop becomes self-inflicted downtime.
5. Reconnect on events, not on a timer. Maintenance arrives as a News (B) countdown with no documented lead time.
6. Session names are eight characters. Far below what most naming conventions assume.
7. Send SNI. Binance names Node.js raw TLS sockets as the case where it is off by default; without it the client may get an unexpected certificate.
8. Narrow the fan-out if you need to. Every order-entry session sees the whole account's reports by default, including orders placed over non-FIX APIs.

FAQ

Does Binance have a FIX API? Yes. Binance provides a first-party FIX API for its Spot exchange, with separate Order Entry, Drop Copy, and Market Data sessions.

Does Binance support FIX for Futures? The Binance Spot FIX API can only be used with the Spot exchange.

What FIX version does Binance use? Binance Spot FIX runs on FIX 4.4.

What authentication does Binance FIX require? FIX sessions accept Ed25519 API keys only, so an Ed25519 key with the FIX permission must be created.

Does Binance FIX support resend requests? No. Binance documents resend requests as not currently supported, so recovery is done by reconnecting rather than by FIX message retransmission.

How do I query order status on Binance FIX? You cannot. The FIX order entry session has no order status request message, so order state is read from the Drop Copy session or from the REST API.

What are the Binance FIX rate limits? Order Entry allows 10000 messages per 10 seconds, Drop Copy 60 messages per 60 seconds, and Market Data 2000 messages per 60 seconds with at most 1000 streams per connection.

Why does my Binance FIX logon fail? The most common causes are a key that is not Ed25519, a missing FIX permission on the key, a SenderCompID longer than 8 characters, and a reconnect attempted within twice the heartbeat interval after a disconnect without Logout.

How many self-trade prevention modes does Binance Spot support? Binance Spot documents six modes NONE EXPIRE_TAKER EXPIRE_MAKER EXPIRE_BOTH DECREMENT and TRANSFER.

How Axon Trade fits in

Axon Trade approaches multi-venue FIX from the other side. It provides advanced trading infrastructure for institutional and professional traders — high-performance FIX API connectivity, real-time market data, and smart order execution — so that instead of a Binance-specific FIX integration (Ed25519 keys, three endpoints, reconnect-based recovery), a client connects through a single, slightly modified FIX 4.4 session that reaches 30+ exchanges. That coverage reaches well beyond the handful of venues that run a FIX gateway of their own, so FIX access through Axon is not confined to exchanges that host FIX themselves. Symbols are normalized to one canonical slash format (e.g. ETH/USDT), identical for market data and execution across venues, and normalized reference data is delivered over FIX via SecurityList (35=y) with Symbol (55) and SecurityExchange (207).

Sources

Facts verified as of September 2026 against Binance's official Spot API documentation. FIX versions, endpoints, and limits change; re-check against live docs before reuse. Vanilla behaviour in the comparison table is per the FIX 4.4 specification.

• Binance Spot FIX API — github.com/binance/binance-spot-api-docs/blob/master/fix-api.md
• Binance Spot enums (order types, time in force, STP modes) — github.com/binance/binance-spot-api-docs/blob/master/enums.md
• Binance Spot self-trade prevention FAQ — github.com/binance/binance-spot-api-docs/blob/master/faqs/stp_faq.md
• Binance Spot API changelog — github.com/binance/binance-spot-api-docs/blob/master/CHANGELOG.md
• FIX 4.4 specification — fixtrading.org