Low Latency Trading

As electronic markets have pushed deeper into microsecond-scale decision-making, the limiting factor is often not the trading logic but the plumbing: message size, encode/decode cost, and session overhead.

To stay relevant in these environments, FIX has evolved from a single “classic” implementation into a set of standards that can be composed to meet different performance and reliability trade-offs. The section that follows sets out the key building blocks of that approach and why they matter for modern low-latency architectures.

How FIX Standards Have Been Developed for Low Latency Requirements

A key design move for low latency has been treating FIX as a layered stack—business semantics (application) separated from encoding (presentation) and session/transport—so firms and venues can keep the same business meaning while swapping in faster encodings and lighter session behaviours. This layering is illustrated in FIX’s own technical standards overview, which explicitly places encodings (e.g., SBE, FAST) and sessions (e.g., FIXP) alongside the FIX Protocol (application layer). Basically, the FIX Protocol, though originally ‘bundled’ with its own encoding (tag-value) and session, can be used with any suitable encoding or session and there are many practical examples of this:

  • FIXML for clearing feeds and regulatory reporting.
  • SBE or FAST for exchange trading/market data interfaces.

Low Latency Encodings: FIX Simple Binary Encoding (SBE) and FAST

FAST and SBE are both FIX standards designed to make high‑volume trading data move faster. They solve slightly different problems:

  • FAST (FIX Adapted for STreaming) was developed to cope with exploding market‑data volumes by drastically reducing message size. It works by avoiding the repeated transmission of unchanged or predictable values, making it especially effective for high‑throughput market‑data streams where bandwidth efficiency matters most.
  • SBE (Simple Binary Encoding) is a deterministic, low‑latency binary encoding focused on minimising CPU overhead and delivering highly predictable encode/decode times; it uses fixed, schema‑defined layouts that allow systems to read data directly from the wire with minimal processing.

In simple terms, FAST is optimised for compressing very large, fast‑moving data feeds (e.g., market data), while SBE is optimised for low‑latency, high‑performance trading where consistency and speed of processing are critical.

Low Latency Session and Transport: FIX Performance Session Layer (FIXP)

The ‘classic’ FIX session provides many features (e.g., authentication, heartbeating, message recovery, checksum validation) that are either not required in certain low-latency scenarios, or are being performed at a lower (say, hardware) level. The second component to FIX’s low latency strategy therefore involves replacing/augmenting classic FIX session behaviours with lighter‑weight session protocols (FIXP and SOFH) designed for high message rates and low latency.

  • The FIX Performance Session Layer (FIXP) is a lightweight, high‑performance session protocol designed for low‑latency environments; unlike the traditional FIX session, it does not impose verbose headers on application messages and allows firms to choose appropriate delivery guarantees (for example, reliable outbound executions but fire‑and‑forget inbound orders), making it well suited to high‑speed order entry, executions and multicast market‑data scenarios where predictability and flexibility matter most.
  • Simple Open Framing Header (SOFH), by contrast, is a very small and simple framing mechanism used to delineate messages on the wire; it provides just enough structure to identify message boundaries without adding business or session logic, and is therefore commonly used alongside binary encodings and high‑performance sessions to keep parsing and transport overhead to an absolute minimum.

In short, FIXP addresses how parties manage and control high‑performance sessions, while SOFH addresses how individual messages are efficiently framed, and together they enable fast, clean, low‑latency message exchange in modern electronic markets.