The Electronic
Trading Manual

The matching engine is the heart of the venue: every order, cancel, and replace is processed in strict sequence, and every trade and book update the market sees is an output of that process. It is engineered for deterministic behavior under extreme message rates, because fairness depends on handling orders exactly in the order they arrive. Understanding how a venue's engine sequences, matches, and publishes events is the starting point for any latency-sensitive strategy.

Within a price level the queue is strictly FIFO: the first order to arrive is the first to be filled, which makes queue position a tradable asset in itself. Arriving a few microseconds earlier can mean capturing a favorable fill instead of watching it happen. Some venues and instruments use alternatives such as pro-rata allocation, but price-time is the dominant model on equity and futures markets like B3.

Feeds are typically distributed as incremental updates, where each message describes a change to the book rather than the full state. Consuming a feed correctly means tracking sequence numbers, handling gaps, and applying updates in exact order. On B3, market data is distributed through UMDF over UDP multicast; the feed is the raw input from which every trading decision downstream is derived.

A feed handler arbitrates between the redundant A and B feeds, detects gaps, decodes the venue's wire format, and maintains the local order book. It sits directly on the hot path: every microsecond spent decoding is added to the tick-to-trade of every strategy behind it. Production handlers are written in aggressively optimized C++ or offloaded entirely to FPGAs.

Each message on a channel carries the next number in the sequence, so a receiver can prove it has seen everything simply by checking continuity. Both market data channels and order-entry sessions rely on this mechanism; a jump in the sequence is the signal that triggers gap handling, and a persistent mismatch on a trading session forces a resynchronization before trading can safely continue.

Because market data travels over UDP, the network offers no delivery guarantee: a dropped packet becomes a hole in the sequence. Trading on a book with an unresolved gap is dangerous, since the local view may be stale precisely when the market is moving fastest. Detecting gaps within microseconds and deciding how to recover is one of the core design problems of feed processing.

The book is organized in price levels, bids on one side and asks on the other; its top defines the best bid and offer and therefore the spread. Participants rebuild it locally by applying incremental feed updates, and its shape (depth, imbalance, queue sizes) feeds most microstructure signals. An efficient book data structure is one of the most performance-critical components of a trading system.

Snapshots exist to bootstrap: a participant joining mid-session, or recovering from a large gap, loads a snapshot and then applies incremental updates starting from the sequence number the snapshot declares. Venues typically publish them on a separate channel that cycles through all instruments, so recovery time depends on where in the cycle you start listening.

Venues offer retransmission services on dedicated channels where a participant requests the missing sequence range. The engineering trade-off is time: waiting for retransmission preserves full continuity but leaves the book stale, while falling back to a snapshot resynchronizes faster at the cost of discarding state. Fast systems automate this decision and measure how often each path is taken.

The exchange sends each packet once and the network replicates it to every subscriber of the multicast group. This is both efficient and fair: all colocated participants receive the same packet at essentially the same moment. Feeds are normally published as redundant A and B groups over separate paths, so a single loss event rarely turns into an actual gap for a well-built consumer.

Gateways terminate trading sessions, enforce pre-trade risk limits and throughput throttles, and forward valid messages to the matching engine. Their location and load matter: the path from your server to your assigned gateway is part of every order's latency, and a congested gateway adds jitter that no amount of server tuning can remove.

FIX encodes messages as tag=value pairs and defines both a session layer (logon, heartbeats, sequence management) and an application layer (orders, executions, allocations). It is the lingua franca of order routing, drop copy, and buy-side connectivity. Its verbosity makes it more expensive to parse than binary encodings, which is why latency-critical paths tend to use the venue's native protocol instead.

Fixed layouts and compact binary encodings (such as SBE, used by B3) make messages cheap to encode and decode, cutting per-message CPU cost dramatically compared to FIX. The price is specificity: each venue's native protocol is different, must be implemented and certified separately, and changes with every venue upgrade cycle.

A new order places or takes liquidity; a cancel withdraws a resting order; a cancel/replace atomically modifies price or quantity. The semantics matter: on most venues, raising quantity or changing price sends the order to the back of the queue, while reducing quantity preserves queue position. All three operations race against the market itself: a cancel can arrive too late and lose to an incoming fill.

Every acknowledgement, rejection, modification, fill, and expiry arrives as an execution report, making it the authoritative record of an order's state machine. Trading systems reconcile their internal state against these reports continuously; a divergence between what the system believes and what the reports say is an incident, not a detail.

A partial fill executes part of the quantity and leaves the remainder working in the book, so a single order can produce many fills at potentially different prices. Position keeping, average-price calculation, and risk checks all have to handle partials correctly, including fills interleaving with cancels and replaces on the same order.

A session is established with a logon, kept alive with heartbeats, and protected by sequence numbers in both directions. After a disconnect, recovery rules define how both sides resynchronize and which in-flight messages get retransmitted. What happens to resting orders when the session drops, such as cancel-on-disconnect, is a configuration every trading desk should know by heart.

Because it is delivered over a separate session, drop copy provides a view of trading activity that does not depend on the health of the trading connection itself. Risk departments consume it for real-time exposure monitoring across all sessions of a firm, and back offices use it for reconciliation and audit.

Inside the venue's data center, the distance to the matching engine drops from milliseconds over metro links to microseconds over a cross-connect, and venues typically equalize cable lengths within the colo so that no rack is closer than another. Colocation is the baseline for latency-sensitive trading; nearly everything else in this manual assumes you are already there.

Typically a fiber pair patched through the facility's meet-me room, a cross-connect provides a private, predictable-latency path to the exchange, a carrier, or a counterparty without touching any shared network fabric. Ordering, redundancy planning, and documentation of cross-connects is unglamorous work that ends up deciding how fast and how resilient your connectivity really is.

In trading infrastructure the NIC is not a commodity part. Low-latency NICs offer hardware timestamping, kernel-bypass APIs, and microsecond-class latency under sustained load. Driver choice, interrupt configuration, and the card's PCIe placement relative to the CPU all change the measured numbers.

SmartNICs move work from the host CPU into the card itself: packet filtering, protocol processing, timestamping, and on FPGA-based cards even parts of the trading logic. The result is lower and more deterministic latency and a freed-up host CPU, in exchange for a more specialized development and operations model.

Stamping in hardware removes the operating system from the measurement: the timestamp reflects when the packet actually touched the wire, not when software got around to observing it. Combined with synchronized clocks, hardware timestamps make one-way latency measurement trustworthy and provide regulatory-grade audit trails.

User-space networking frameworks let the application talk almost directly to the NIC, eliminating system calls, context switches, and buffer copies from the packet path. Savings of several microseconds per message are typical compared to the standard kernel path, which is why virtually every serious low-latency system runs some form of bypass.

Logic implemented in an FPGA runs in fixed clock cycles with no operating system, no scheduler, and no cache surprises, delivering nanosecond-scale determinism. In trading, FPGAs appear in feed handlers, pre-trade risk gates, and full tick-to-trade pipelines. The trade-off is engineering cost: hardware description languages, long build cycles, and harder debugging.

Capturing traffic at a tap or a switch mirror port, ideally with hardware timestamps, produces the ground truth of what actually crossed the wire and when. PCAPs drive latency analysis, incident forensics, and realistic replay testing: replaying yesterday's captured feed against a new build of a feed handler is one of the most effective regression tests in trading.

The number only means something when the two reference points are explicit: wire-to-wire, application-to-application, and venue-reported latencies are different measurements. Serious analysis reports distributions rather than averages, because the shape of the distribution, and especially its tail, is where the risk actually lives.

Tick-to-trade is the canonical end-to-end metric of a trading system, encompassing feed decode, book update, strategy decision, and order encode. Measured wire-to-wire with hardware timestamps, it allows honest comparison between systems; the fastest FPGA pipelines put it well under a microsecond, while software systems typically live in the single-digit microseconds.

Order-to-acknowledgement RTT is the most watched example: it includes both network directions plus the venue's processing time. RTT is convenient because it requires no clock synchronization between endpoints, but it hides asymmetry: a slow outbound path with a fast return looks identical to the reverse, and only one of them delays your orders.

Two systems with the same median latency can behave very differently if one of them occasionally stalls. Common sources are interrupts, scheduler preemption, garbage collection, cache misses, and network queuing. Low-jitter engineering, through core isolation, busy polling, and preallocation, is what turns a fast system into a predictable one.

Tails matter because the slowest moments cluster exactly when the market is busiest, and that is where the money is decided. A system with a 5 µs median and a 500 µs p99.9 is not fast where it counts. Histogram-based measurement, rather than averages, is the only honest way to see the tail; it is the same analysis shown in the latency histogram on our home page.

One-way latency measurement, cross-system event correlation, and regulatory timestamping all require devices to agree on the time to within microseconds or better. In practice this is a discipline chain: GNSS at the top, a grandmaster clock, PTP distribution through the network, and hardware timestamping at the edges.

PTP (IEEE 1588) exchanges timestamped messages to estimate and correct the offset between clocks, reaching sub-microsecond accuracy when switches and NICs timestamp in hardware. Boundary and transparent clocks along the network path preserve that accuracy at scale. TOOQ offers PTP and time sync as a managed service inside Tooq Cloud.

A GNSS receiver with a roof antenna disciplines the local grandmaster to UTC with nanosecond-class accuracy, providing the traceability that regulators and auditors expect. Reception quality, antenna placement, cable delay calibration, and holdover behavior during signal loss are the operational concerns that decide real-world performance.

The rising edge of the pulse marks the exact boundary of each second, letting a device align its clock to a reference with very high precision over a simple coaxial connection. PPS is commonly used both to discipline equipment and to independently verify what PTP claims: if the pulse and the protocol disagree, something in the chain is wrong.

Every oscillator runs at a slightly different rate, and that rate itself changes with temperature and age, so two clocks that agree now will disagree later without continuous correction. Drift determines holdover quality: how long a clock remains within tolerance after losing its reference, and therefore how much time you have to fix a broken sync chain.

Usually disciplined by GNSS, the grandmaster is elected through the Best Master Clock Algorithm, and every downstream device is measured relative to it. Serious deployments run redundant grandmasters and monitor failover closely, because a misbehaving grandmaster silently corrupts every timestamp in the network while everything appears to be synchronized.

Instead of sleeping and being woken by the scheduler (a path that costs microseconds and adds jitter), the thread burns a dedicated core checking for work in a tight loop. Combined with core isolation and CPU pinning, busy polling delivers the lowest and most consistent reaction latency available in software, at the price of a core running at 100% by design.

On multi-socket servers, memory attached to the local socket is significantly faster to reach than memory across the inter-socket link. Latency-sensitive processes are pinned so that the thread, its memory, and the NIC's PCIe slot all live on the same NUMA node; getting this wrong quietly costs hundreds of nanoseconds on every access.

The hot path is the code that runs for every market event and every order: decode, book update, decision, encode, send. Hot-path discipline means no allocation, no locks, no logging, no blocking calls, and cache-friendly data layouts, with everything else moved onto other threads. Optimizing anything off the hot path is effort spent where it cannot be measured.

A deterministic system has a bounded worst case, not just a good average. It is achieved by removing sources of variance: preallocated memory, lock-free structures, isolated cores, and, at the extreme, FPGA implementations. In trading, determinism is a form of risk control: you know how your system behaves in its worst moment, which is exactly when it matters.

Order entry sessions run over TCP because losing or reordering an order message is unacceptable. Reliability has a cost: retransmissions and head-of-line blocking create latency tails, so low-latency deployments tune the stack aggressively or replace it with kernel-bypass TCP implementations that keep the same semantics on a faster path.

UDP sends independent datagrams with no delivery guarantee, no ordering, and no flow control, which is precisely what makes it fast and multicast-friendly. The reliability burden moves up to the application layer: sequence numbers, gap detection, and recovery channels exist because market data rides on UDP by design.