Trading Systems & Market Infrastructure: The 2026 Engineering Guide

Building trading systems for institutional capital markets is fundamentally different from building general-purpose distributed systems. A market data feed that delivers prices 100 microseconds late is worthless to a market maker. An order management system that drops a single message during a volatility spike can trigger a regulatory investigation. This guide covers the architecture patterns, technology choices, and operational practices we have used to build trading infrastructure at HSBC, Credit Suisse, Deutsche Bank, and NatWest Markets.

The Trading System Stack

Modern trading infrastructure consists of five layers, each with distinct latency, throughput, and reliability requirements:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

┌─────────────────────────────────────────┐
│  ALGO / STRATEGY LAYER                  │
│  Sub-microsecond decisions              │
├─────────────────────────────────────────┤
│  OMS / EMS LAYER                        │
│  Order management, FIX routing, state   │
├─────────────────────────────────────────┤
│  MARKET DATA LAYER                      │
│  Normalisation, distribution, storage   │
├─────────────────────────────────────────┤
│  MESSAGING LAYER                        │
│  Aeron / Kafka / Solace / Chronicle     │
├─────────────────────────────────────────┤
│  RISK & COMPLIANCE LAYER                │
│  Pre-trade checks, position limits      │
└─────────────────────────────────────────┘

Each layer has different engineering requirements. Getting the boundaries wrong — for example, putting pre-trade risk checks on the same thread as order dispatch — can add latency that costs millions.

Messaging Infrastructure

The messaging layer carries every order, execution, and market data tick. The choice of messaging technology determines the latency floor for everything above it.

We have written extensively about the three dominant options:

• Aeron vs Kafka vs Chronicle Queue — Real P50/P99 benchmarks from production. Aeron delivers sub-10μs at P99 for exchange gateway connectivity. Kafka handles settlement and risk workflows at 2-10ms with durability guarantees. Chronicle Queue achieves sub-microsecond journaling for deterministic replay on the trading floor.

• Multi-Region Kafka — Running Kafka across London, New York, and Tokyo for global order routing. Covers stretch clusters, mirror-maker topologies, and the latency/consistency trade-offs for cross-region trading.

Key decision framework:

Market Data Infrastructure

Market data is the highest-volume workload in any trading system. A single options exchange can produce over 10 million messages per second during volatility events. The market data pipeline must normalise, filter, and distribute this firehose without adding latency.

Architecture patterns we use in production:

• Feed Handler → Normalisation → Distribution: Feed handlers connect directly to exchange gateways (typically via UDP multicast or TCP with kernel bypass). Normalisation converts exchange-specific formats (ITCH, OUCH, FIX/FAST) to a canonical internal format. Distribution uses Aeron or a message bus to fan out to downstream consumers.

• Entitlement-based filtering: Not every consumer needs every symbol. We implement symbol-level, exchange-level, and field-level filtering at the distribution layer to reduce bandwidth and consumer load.

• Tick-to-trade latency measurement: Production systems must measure end-to-end latency from exchange wire to order acknowledgement. We instrument at every hop with hardware timestamping (PTP, IEEE 1588) and correlate with exchange-provided timestamps.

OMS/EMS Architecture

The Order Management System (OMS) and Execution Management System (EMS) form the transactional core of the trading platform. In modern architectures, the distinction between OMS and EMS is blurring — both are stateful services managing order lifecycle.

Critical design decisions:

• Token Symbology in Modern OMS/EMS — As digital assets and tokenized securities enter institutional trading, OMS/EMS systems must handle both traditional symbology (ISIN, CUSIP, SEDOL, RIC) and on-chain identifiers (contract addresses, token IDs). The symbology layer becomes a critical integration point.

• FIX Protocol Best Practices — FIX remains the lingua franca of institutional trading. We cover FIX session management, message sequencing, gap fills, and the FIX 5.0 SP2 features that matter most in 2026.

• State machine design: Every order follows a deterministic state machine (New → PartiallyFilled → Filled / Cancelled). We implement this as an event-sourced aggregate, where every state transition is an immutable event. This provides full auditability and enables temporal queries (“what was the state of this order at 14:32:05?”).

Real-Time Risk Management

Pre-trade risk checks must execute in single-digit microseconds to avoid adding latency to the order path. Post-trade risk analytics must process millions of positions and market data updates to calculate VaR, Greeks, and stress scenarios.

• Real-Time Risk Engines: Architecture Patterns — How to build risk engines that combine streaming market data with position stores for sub-millisecond pre-trade checks and continuous intraday risk monitoring.

• Real-Time Risk Analytics with Apache Beam and Dataflow — Batch and streaming unification for risk calculations using Apache Beam. Covers the architectural patterns for computing Greeks, VaR, and stress tests across unified pipelines.

Exchange Connectivity & Co-Location

Exchange connectivity is the lowest layer of the stack and the one where mistakes are most expensive. A misconfigured FIX session or a firewall rule change can take a trading desk offline during market hours.

Production practices:

• Co-location architecture: Trading engines run in exchange data centres (Equinix NY4, LD4, TY3). Management and risk systems run in the firm’s own cloud or data centre. The WAN link between co-location and HQ carries only control traffic — orders and market data stay local.

• Redundant connectivity: Every exchange connection has a primary and secondary path, with automatic failover. We use BGP anycast for IP-based connections and FIX session-level redundancy for order sessions.

• Conformance testing: Every exchange has a conformance test suite. Changes to order routing logic must pass the full suite in a pre-prod environment before production deployment.

Infrastructure & Platform Engineering

Trading systems increasingly run on cloud-native infrastructure, but with requirements that general-purpose platforms don’t satisfy:

• Enterprise Kubernetes in Capital Markets — Rancher vs OpenShift vs Tanzu for running trading workloads on Kubernetes. Covers the platform requirements unique to capital markets: air-gapped deployments, FIPS 140-2 compliance, audit logging, and deterministic pod scheduling.

• eBPF for Trading Systems — Kernel-level observability using eBPF. Monitor system calls, network packets, and CPU scheduling without the overhead of traditional agents. Critical for debugging latency outliers in production.

• Chaos Engineering for Financial Infrastructure — How to run chaos experiments in regulated trading environments without violating compliance requirements or triggering exchange circuit breakers.

The Capital Markets Cloud Migration

The industry is moving trading infrastructure to the cloud, but the path is different from general enterprise migration:

• The Capital Markets Cloud Migration Playbook — A 5-phase framework for migrating trading systems to cloud: Assessment, Foundation, Migration, Optimization, and Continuous Evolution. Based on real migrations at tier-one institutions.

• Cloud-Native Trading Systems — Design patterns for achieving sub-millisecond latency on cloud infrastructure, including kernel bypass networking (DPDK, XDP), NUMA-aware scheduling, and instance selection for deterministic performance.

Build vs Buy: The Platform Decision

One of the most consequential decisions in trading technology is whether to build or buy each component:

• Build vs Buy Decision Framework for Fintech Founders — A structured framework for evaluating build vs buy across the trading stack, including total cost of ownership models for OMS, EMS, market data, and risk systems.

The short version: build where latency or differentiation matters (market data distribution, algo engines, risk models). Buy where standardisation reduces operational burden (FIX gateways, reference data, regulatory reporting).

Operational Excellence

Trading systems require operational practices that go beyond standard SRE:

• Deterministic deployments: Trading system deployments must be deterministic and reversible. Every deployment includes a verified rollback plan with automated validation that the rollback actually works.

• Circuit breakers: Trading systems must include automatic circuit breakers that halt trading when anomalous conditions are detected — duplicate order detection, latency spikes, position limit breaches, or exchange connectivity loss.

• Regulatory audit readiness: Every order, cancellation, and execution must be traceable to a specific trader, algorithm, and timestamp. The audit trail must be immutable and queryable for at least seven years (MiFID II requirement).

Getting Started

If you are building or modernising a trading platform, the most important decision is the messaging layer — it sets the latency floor for everything above it. Start with the Aeron vs Kafka vs Chronicle Queue comparison to understand your options, then work up the stack.

For hands-on help architecting trading infrastructure, see our trading systems consulting practice.