Delivering Reference Data over FIX SecurityList

TL;DR. In FIX, instrument reference data is delivered with the SecurityList message (MsgType 35=y), sent in response to a SecurityListRequest (35=x). Each instrument is carried inside the <Instrument> component block, where Symbol (55) and SecurityExchange (207) say what the instrument is and where it trades. The message and its fields are standardized — but every venue populates them differently, using different FIX versions, different symbol strings in tag 55, and different request semantics. A firm connecting to several venues therefore receives the same message shape carrying incompatible contents.

What SecurityList (35=y) is

SecurityList was added to the standard in FIX 4.3 and returns a list of securities matching the criteria in a SecurityListRequest. It is the FIX-native equivalent of a "list all tradable instruments and their trading parameters" endpoint.

The request and response pair works like this:

• The client sends SecurityListRequest (35=x) with a SecurityReqID (320) and a SecurityListRequestType (559) describing the query.
• The server replies with one or more SecurityList (35=y) messages, each echoing SecurityReqID (320), assigning a SecurityResponseID (322), and reporting a SecurityRequestResult (560).

In FIX 4.4, SecurityListRequestType (559) takes these values: 0 = Symbol (55), 1 = SecurityType (167) and/or CFICode (461), 2 = Product (460), 3 = TradingSessionID (336), 4 = All Securities.

Message structure and the key fields

Instrument identity lives in the <Instrument> component block, repeated under NoRelatedSym (146). The two fields that matter most for cross-venue identity are:

• Symbol (55) — the instrument's ticker string, as the venue writes it.
• SecurityExchange (207) — the market identifier that says where the instrument trades.

Alongside identity, a SecurityList entry commonly carries trading parameters such as Currency (15), RoundLot (561), MinTradeVol (562), TradingSessionID (336) and ExpirationCycle (827).

Fragmentation — why one request returns many messages

An instrument universe can be large, so the standard supports fragmenting the response. Three fields govern this: TotNoRelatedSym (393) (total count expected), NoRelatedSym (146) (count in this message), and LastFragment (893) (the flag marking the final fragment). A client reassembles the full list by reading until LastFragment = Y. In practice venues fragment aggressively — Axon Trade, for example, streams one instrument per message.

Discovering new instruments after the initial list

By itself, without an update message, the base FIX 4.3/4.4 SecurityList behaves as a point-in-time snapshot. Later protocol versions add a push mechanism, SecurityListUpdateReport (MsgType BK, introduced in FIX 4.4 and carried in FIX 5.0). Whether a venue supports proactive updates or requires the client to re-poll varies from venue to venue.

How real venues implement it — same message, different contents

This is where a standardized message stops being standardized in practice.

Divergences worth calling out individually:

• FIX version drift. Bullish and Cboe Digital sit on FIX 4.4; Polymarket US runs FIXT.1.1 with a FIX 5.0 SP2 application layer; Coinbase International ships a FIX 5.0-based market-data dictionary. A single FIX engine configuration does not cleanly span all of them.
• Symbol string. Bullish writes Bitcoin-vs-US-Dollar spot as Symbol (55) = BTCUSD — concatenated, no delimiter. Other venues use their own delimiters and suffixes in the same tag 55, which is exactly why tag 55 alone is not a portable identifier across venues.
• Message choice. Some venues answer with SecurityList (35=y), a bulk list; Coinbase International also exposes SecurityDefinition (35=d), a per-instrument definition. A cross-venue consumer must handle both patterns.
• Request-type support is a subset. The standard defines five SecurityListRequestType (559) values, but a venue may implement only some. Bullish's published FIX dictionary lists just 0 (SINGLE_SYMBOL) and 4 (ALL_SECURITIES).
• Result enums are customized. Bullish defines SecurityRequestResult (560) values 0 VALID_REQUEST, 1 INVALID_OR_UNSUPPORTED_REQUEST, and 2 INSTRUMENT_NOT_FOUND — its own labels layered on the standard field.
• Update model. Polymarket US documents that a proactive security-list update message is not supported, so clients must re-send SecurityListRequest (x) to pick up newly listed instruments.

The symbol-collision problem this creates

Because Symbol (55) is venue-authored, the same string can mean different assets on different venues. A documented example from a market-data vendor: GAS refers to Neo Gas on several venues but to Gas DAO on another, with both trading under an instrument such as gas_usdt. Reference data delivered without a normalizing layer therefore forces the consumer to keep a per-venue map of what each tag-55 string actually denotes. Amberdata addresses this with an open-source Asset Reference and Classification (ARC) scheme delivered alongside its FIX 4.4 market-data feed.

FAQ

What is FIX message 35=y
It is the SecurityList message used to return a list of instruments and their trading parameters in response to a SecurityListRequest 35=x.

What is the difference between SecurityList and SecurityListRequest
SecurityListRequest 35=x is the query a client sends. SecurityList 35=y is the response the venue returns.

Which FIX fields identify an instrument in a SecurityList
Symbol 55 gives the ticker string and SecurityExchange 207 gives the venue, both inside the Instrument component block.

How does a client know the SecurityList is complete
By reading TotNoRelatedSym 393 and the LastFragment 893 flag, since large lists are split across multiple messages.

Do all crypto venues use the same symbol format in tag 55
No. Bullish uses a concatenated form such as BTCUSD, and other venues use their own delimiters and suffixes, so tag 55 alone is not portable across venues.

How do I get instruments that were listed after my initial SecurityList
It depends on the venue. Some support a proactive update message while others, such as Polymarket US, require re-sending SecurityListRequest 35=x.

How Axon Trade fits

Axon Trade runs a connectivity and normalization layer in front of 30+ crypto venues, exposed through a single, slightly modified FIX 4.4 session. Instead of reconciling one dialect per venue, a client receives a single normalized SecurityList (35=y) in which:

• Symbol (55) uses one canonical slash form, for example ETH/USDT, identical across venues and identical for market data and execution.
• SecurityExchange (207) carries the venue, so the same normalized symbol stays disambiguated across markets.
• The list is streamed one instrument per message, with TotNoRelatedSym (393) and LastFragment (893) marking the end of transmission.
• Each entry includes price precision, minimum quantity and lot size for pre-validation, with unified enums for security types, order types and time in force.

Axon maintains this normalized symbol and asset database as a member of the FIX Trading Community, framing normalization as a stopgap pending a formal ISO crypto-naming standard. Matching and normalization run inside Equinix data centers (NY4, LD4, TY8) with roughly 35 microseconds of added software latency.

Sources

• FIX Dictionary, FIX 4.4 — SecurityList, SecurityListRequest, and the Instrument component block (OnixS)
• FIXimate, FIX Trading Community — SecurityList pedigree
• InfoReach FIX Dictionary — SecurityRequestResult and SecurityListUpdateReport
• Bullish FIX Protocol Specification and published FIX dictionary
• Polymarket US FIX documentation
• Coinbase International FIX changelog
• Cboe Digital FIX 4.4 Specification
• Amberdata Asset Reference and Classification (ARC)
• Axon Trade documentation (docs.axon.trade)