Choosing an Order Entry Path: UDP vs TCP, and STEP/FIX vs Exchange Binary Protocols

TCP Reliability and UDP Transport in Low-Latency Order Entry

Order entry is the moment a trading decision becomes a firm commitment. The path that carries that order, from strategy logic to the exchange gateway, must be fast enough to matter and reliable enough that a lost or corrupted message does not create risk or operational failure. Two independent choices dominate the design: the transport (UDP versus TCP) and the application protocol (standard FIX or STEP versus exchange-native binary formats).

These choices are constrained by what exchanges actually offer. Most order-entry interfaces require a reliable stream; market-data feeds are usually multicast UDP. Within the reliable stream, firms still decide whether to speak a widely supported tag-value protocol or a compact binary dialect designed for the venue's matching engine.

Order-entry design prioritizes reliability first, almost always TCP, then selects the application protocol according to residual latency targets, multi-venue needs, and the operational cost of maintaining venue-specific code.

Transport Reality: Why Order Entry Is Almost Always TCP

UDP offers a simpler stack and lower per-packet overhead. It is the natural choice for market-data multicast, where a lost packet can be ignored or recovered from a secondary feed and where head-of-line blocking would be harmful. Order entry has different requirements. An order, a cancel, or a replace must arrive intact, in sequence, and must be acknowledged. TCP supplies connection-oriented delivery, retransmission, and ordered streams.

In practice, exchange order gateways and broker FIX or binary sessions are TCP-based. Attempts to push order entry over pure UDP are rare and usually limited to internal, tightly controlled segments that still implement application-level reliability. For the final hop to the venue, TCP remains the default because the cost of a lost or reordered order far exceeds the modest latency difference between a well-tuned TCP stack and UDP.

FPGA and kernel-bypass techniques can still keep TCP residual latency very low. Partial packet assembly in hardware, cut-through transmission, and careful socket tuning (TCP_NODELAY, appropriate buffering) reduce the software contribution without abandoning reliability.

FIX and STEP: Standardization and Reach

FIX (Financial Information eXchange) is the long-standing industry standard for order routing, execution reports, and post-trade messaging. It is tag-value, human-readable, and supported by virtually every broker, EMS, and multi-venue platform. STEP (the Chinese Securities Trading Exchange Protocol family) plays an analogous role in mainland Chinese markets, providing a standardized way to reach exchange gateways and broker systems.

The advantages are operational. A single FIX or STEP engine can talk to many destinations with well-understood session management, sequence numbers, gap recovery, and drop-copy support. Certification, logging, and support are simpler. For firms that route to multiple brokers or venues, or that value rapid onboarding of new destinations, the standard protocols reduce both development and ongoing maintenance cost.

The trade-off is encoding and parsing overhead. Tag-value messages are larger and require more CPU work to serialize and deserialize than compact binary layouts. Under moderate order rates, the difference is often acceptable; at the highest message rates and tightest residual budgets, it becomes measurable.

Exchange-Native Binary Protocols

Many exchanges also publish proprietary binary order-entry interfaces, CME iLink binary, Eurex T7 ETI, Cboe BOE, Nasdaq OUCH, various SBE-based sessions, and venue-specific formats in Asia. These protocols are engineered for the matching engine's internal structures. Fields are fixed or tightly packed, parsing can be zero-copy or near zero-copy, and the message set is limited to what the venue actually needs.

Binary interfaces typically deliver lower and more stable latency, especially under sustained high order rates. They also give the exchange tighter control over evolution: new order types or microstructure features can be introduced without the broader FIX committee process. The cost is fragmentation. Each venue requires its own encoder, session logic, certification, and monitoring. Multi-venue firms either maintain multiple native stacks or accept a FIX layer for some destinations and native binary for the most latency-sensitive ones.

Matching the Path to the Strategy

Latency-critical, single-venue or co-located strategies usually prefer the exchange binary path when it is available. The residual budget after market-data arrival is small; every microsecond of serialization and session overhead matters. Firms that already operate FPGA order-entry or risk paths often keep the final outbound message in the native binary format so that the hardware or tightly tuned software can emit it with minimal transformation.

Multi-venue routers, broker platforms, and strategies that value operational uniformity more than the last nanoseconds stay on FIX or STEP. The same session layer, the same recovery semantics, and the same monitoring tools work across destinations. Hybrid architectures are common: native binary to the primary venue, FIX or STEP to secondary venues or to the broker's smart order router.

Internal Paths and Hybrid Designs

Inside a trading system, the picture is more flexible. Components can exchange messages over shared memory, lock-free queues, or even UDP when the loss model is understood, and recovery is handled at the application layer. Once the order must leave the firm's infrastructure and enter the exchange or broker gateway, the external contract, almost always TCP plus FIX, STEP, or native binary, takes over.

FPGA platforms can accelerate both sides. A hardware feed handler normalizes market data; a hardware or hybrid risk-and-order path can emit a binary order message directly. The host software still needs a clean, low-jitter path to supply the decision and to handle session management, recovery, and non-critical messaging.

ShengliSoft Context in Chinese Markets

In mainland Chinese equity and futures environments, firms interact with exchange gateways that support both standardized protocols (including STEP family messages) and optimized low-latency paths. ShengliSoft's REM ultra-low-latency trading system provides the order-entry and risk layer for brokers and trading firms, with configurable TCP and UDP ports for the trading session. Their Extreme Feed Handler processes exchange market-data streams (including binary and STEP-related formats) in FPGA logic, while RiskGuard performs pre-trade checks in hardware.

The combination allows firms to keep the residual software path short while still satisfying exchange connectivity and risk requirements. The same design tension appears: standardized session protocols for operational reach and compliance, and tightly engineered binary or hardware-accelerated paths where residual latency is decisive.

Operational and Risk Considerations

Protocol choice affects more than speed. Session recovery, sequence gap handling, drop-copy reliability, and regulatory audit trails are easier to standardize with FIX or STEP. Binary interfaces require venue-specific recovery logic and careful certification. Error handling, kill switches, and pre-trade risk must work identically regardless of the wire format; the risk engine should not care whether the outbound message was built as FIX tags or as a binary struct.

Testing must cover both the happy path and failure modes, disconnects, sequence gaps, partial fills, and mass cancels under realistic message rates. Logging and replay tools need to understand every protocol in use so that incidents can be reconstructed.

Practical Selection Sequence

Start with the venues and the residual latency target. If the strategy is co-located and single-venue, evaluate the native binary interface first and measure end-to-end residual latency against a FIX or STEP baseline. If the firm routes to many destinations or values rapid onboarding, begin with FIX or STEP and introduce native binary only for the venues where the measured difference justifies the extra maintenance.

Keep transport and application protocol decisions separate. Transport is almost always TCP for order entry; the application protocol is chosen for latency versus operational reach. Measure both average and tail latency under production-like load before committing.

Reliability First, Then Latency: Matching Transport and Protocol to the Residual Budget

Order-entry design begins with the requirement that every order and cancel must arrive intact. That requirement selects TCP for the external path in nearly all cases. Within that reliable stream, FIX and STEP provide standardization and multi-venue reach; exchange-native binary protocols provide tighter encoding and lower residual latency for the most demanding strategies.

Firms that measure both the latency distribution and the operational cost of each option and that keep risk and recovery logic independent of the wire format end up with a path that is fast enough where it matters and robust enough everywhere else.

FAQ

1. Why is order entry almost always TCP rather than UDP?

Orders, cancellations, and replacements must be delivered reliably and in sequence. TCP provides connection-oriented delivery and retransmission; UDP does not. Market data can tolerate loss; order entry generally cannot.

2. When does UDP still appear in an order path?

Mainly on internal segments inside a firm's own infrastructure, or when an application-level reliability layer is implemented on top of UDP. The final hop to the exchange or broker gateway remains TCP in nearly all production systems.

3. What is the main advantage of FIX or STEP?

Standardization. One session layer, well-understood recovery, broad counterparty support, and simpler multi-venue or multi-broker connectivity.

4. What is the main advantage of exchange-native binary protocols?

Compact encoding, lower parsing overhead, and often tighter integration with the venue's matching engine, which translates into lower and more stable residual latency under high order rates.

5. Can a firm use both?

Yes. Many architectures use native binary for the primary, latency-sensitive venue and FIX or STEP for secondary venues or broker routing.

6. How do FPGA systems change the calculation?

They can accelerate both market-data handling and the final stages of order construction and risk checking, reducing the software contribution. The external session still follows the exchange's required transport and protocol.

7. Does ShengliSoft support these paths?

ShengliSoft's REM trading system provides low-latency order entry with configurable TCP and UDP session parameters for Chinese market connectivity, while their FPGA feed handlers and risk engines keep the residual path short.

8. What should be measured before choosing?

End-to-end residual latency (average and tail) under realistic order rates, recovery behavior under disconnects and gaps, and the ongoing cost of maintaining each protocol stack.

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.