Exchange Market Data Protocols: ITCH vs FIX/FAST vs Binary Feeds

Market-data protocols determine how quickly and completely a trading system can see the book. The choice is rarely cosmetic. ITCH-style binary feeds, FIX/FAST compressed streams, and proprietary exchange binary protocols differ in encoding efficiency, message granularity, recovery mechanisms, and the residual latency they impose on the feed handler. Understanding those differences is essential when designing or selecting the market-data path for latency-sensitive strategies.

ITCH and native binary feeds minimize parsing and transmission overhead for full-depth order books, while FIX/FAST prioritizes standardization and bandwidth efficiency at the cost of additional decoding work; the right choice depends on the required depth, recovery model, and residual-latency budget.

ITCH: Order-by-Order Binary Multicast

ITCH (and its close relatives such as certain exchange-specific “ITCH-like” feeds) is a unidirectional, binary, multicast protocol originally popularized by Nasdaq and now used or adapted by multiple venues. Messages are fixed or near-fixed length, identified by a single message-type byte, and carry full order-level detail: add, modify, cancel, execute, and trade events with order reference numbers.

Because the format is compact and free of tag-value parsing, a well-written feed handler can decode messages with very low and deterministic CPU cost. Full order-book visibility is native; the handler reconstructs the book by applying the incremental events in sequence. Multicast delivery keeps the network path simple for co-located consumers, although sequence-gap detection and recovery (usually via a separate retransmission or snapshot service) remain mandatory.

The principal advantages are speed of decode, completeness of order-level data, and suitability for hardware acceleration. The principal costs are venue-specific variants, the need for robust gap handling, and the fact that the protocol is market-data only; order entry uses a companion binary protocol such as OUCH or an exchange-native order interface.

FIX/FAST: Standardized and Compressed

FIX remains the dominant standard for order routing and for many market-data sessions, especially outside pure co-location environments. Classic tag-value FIX is human-readable and flexible but verbose. FAST (FIX Adapted for STreaming) applies template-based compression and differential encoding to reduce bandwidth dramatically while preserving the FIX semantic model.

FAST market-data feeds are typically delivered over TCP or UDP and are widely supported by vendors and buy-side systems. The compression makes them efficient on constrained or shared networks, and the standardization eases multi-venue normalization. The trade-off appears in the decoder: template expansion, presence-map handling, and type conversion add measurable work compared with a pure binary fixed-layout parser. Residual latency is therefore higher than a well-optimized ITCH or native binary path, although still acceptable for many algorithmic and smart-order-routing use cases.

FIX/FAST also inherits FIX session semantics, sequence numbers, heartbeats, and gap-fill behavior, which simplify operational recovery at the expense of additional state management in the feed handler.

Native Exchange Binary Feeds

Many exchanges publish their own high-performance binary market-data protocols (examples include CME MDP, Eurex EMDI/EOBI-style feeds, and various Asian exchange binary formats). These feeds are purpose-built for the venue’s matching engine and often provide both incremental updates and periodic snapshots. Encoding is compact, fields are fixed or length-prefixed, and the message set is tailored to the products traded.

Like ITCH, these protocols favor low decode cost and high message rates. Book depth may be order-by-order or price-aggregated depending on the feed variant. Recovery is usually handled through snapshot channels, retransmission requests, or dual-site arbitration. Because each exchange defines its own layout, a multi-venue firm must maintain separate parsers or a highly configurable normalization layer.

Native binary feeds are the default choice for participants who co-locate and require the lowest possible residual latency from the exchange’s own dissemination point.

Latency and Parsing Cost Compared

On a residual-critical path, the dominant differences are:

• Decode complexity: fixed-layout binary (ITCH-style or native) requires the fewest instructions per message; FAST requires template-driven expansion; tag-value FIX is the most expensive.
• Network characteristics: multicast binary feeds avoid per-consumer TCP overhead; TCP-based FIX/FAST sessions provide reliable delivery but introduce head-of-line and acknowledgment costs.
• Book reconstruction: order-by-order feeds demand careful sequencing and gap handling; price-aggregated feeds are simpler but lose queue-position information.

FPGA and highly optimized software feed handlers can narrow the gap, yet the structural advantage of a compact binary format remains. When every nanosecond counts, the protocol that arrives already close to the internal book representation wins.

Recovery and Operational Behavior

All production feeds must handle loss. ITCH and most binary multicast feeds rely on sequence numbers plus a separate retransmission or snapshot service. FIX/FAST uses the FIX session layer (Resend Request, Sequence Reset). Dual-site or dual-channel A/B feeds add redundancy but require arbitration logic in the handler so that the book never goes backward or duplicates events.

The quality of recovery design often matters more than peak decode speed. A feed that loses sequence under burst conditions and cannot rebuild cleanly is unusable for trading regardless of its theoretical latency.

Hardware Acceleration and Protocol Choice

FPGA feed handlers excel when the protocol is regular, and the message set is stable. ITCH-style and native binary formats map cleanly onto streaming parsers and parallel book-update pipelines. FAST is still acceleratable, but the template logic consumes more fabric resources and introduces more conditional paths. Tag-value FIX is rarely the first candidate for full hardware decoding on the residual path.

ShengliSoft’s Extreme Feed Handler is built to process high-rate binary and exchange-native market-data streams in FPGA logic, delivering low and stable residual latency for Chinese equity and futures feeds. The same architectural principles, streaming decode, deterministic book construction, and clean gap handling, apply across ITCH-like, proprietary binary, and carefully accelerated FAST implementations.

Choosing the Right Feed for the Strategy

Order-by-order ITCH or native binary is the usual requirement for market-making, queue-position-sensitive strategies, and any system that must see every incremental change. Price-aggregated or FAST feeds can be sufficient for signal generation, slower algorithmic strategies, or multi-venue aggregation where bandwidth and operational simplicity outweigh the last nanoseconds.

Many firms consume both: a primary binary feed for the residual-critical path and a normalized FIX/FAST or consolidated feed for broader monitoring and research.

Protocol Structure Determines the Floor of Residual Latency

ITCH and exchange-native binary feeds minimize encoding and parsing overhead, making them the natural substrate for the lowest-latency book construction. FIX/FAST trades some of that efficiency for standardization, compression, and operational familiarity. The correct selection is driven by the depth of book required, the recovery model the venue supports, and the residual budget the strategy can tolerate.

Feed-handler design, software or FPGA, must respect the protocol’s strengths rather than fight them. When the protocol, the handler, and the strategy are aligned, market data ceases to be the hidden source of latency and becomes a predictable component of the trading path.

FAQ

1. What is the core advantage of ITCH-style feeds?

Compact, fixed-layout binary messages that carry full order-level detail and can be decoded with very low, deterministic cost.

2. How does FAST improve on classic FIX?

It applies template-based compression and differential encoding, substantially reducing bandwidth while retaining FIX semantics.

3. Why do native exchange binary feeds exist?

Exchanges optimize for their own matching engines and product sets, producing compact formats that minimize dissemination latency for co-located participants.

4. Which protocol is easiest to accelerate in FPGA?

Regular fixed-layout binary protocols (ITCH-style and most native binary feeds) map most cleanly onto streaming hardware parsers.

5. What recovery mechanisms are typical?

Sequence numbers plus retransmission or snapshot channels for multicast binary feeds; FIX session-layer gap fill for FIX/FAST.

6. When is FIX/FAST still the practical choice?

When multi-venue standardization, operational simplicity, or operation outside pure co-location outweighs the need for the absolute lowest residual latency.

7. How does ShengliSoft infrastructure fit?

The Extreme Feed Handler processes high-rate binary and exchange-native market-data streams in FPGA logic, providing the low-latency book construction required by residual-critical strategies on Chinese markets.

8. Does protocol choice affect book quality?

Yes. Order-by-order feeds preserve queue position and individual order identity; price-aggregated feeds lose that granularity and limit certain strategy types.

Disclaimer

This content is for informational purposes only and does not constitute investment advice. Financial markets and technology investments carry risk. Please conduct your own research before making investment or business decisions.