Building a trading system

Feed handler, book builder, strategy, order manager, risk gate. The components are the same whether you run from a laptop or a colo rack; only the latency budget changes.

The idea

What are the components of a trading system, in order?

A trading system is a chain. Gateways connect to the venue; a feed handler decodes market data; a book builder reconstructs the order book; a strategy computes a signal and decides; an OMS/EMS tracks and routes the orders; a risk gate enforces limits and can kill everything; and the order gateway puts orders on the wire. Each stage consumes the previous stage's output, which is why the diagram above reads strictly left to right from market data in to orders out.

Walking the pipeline in order: connectivity / gateways are the sessions to the venue: an inbound multicast feed subscription and an outbound order-entry session, two channels and two protocols. The feed handler decodes the venue's wire protocol (FIX/ITCH/SBE), handles sequencing and gap recovery, and emits normalised internal events, the first and most latency-sensitive stage. The book builder applies those incremental events to reconstruct the limit order book in memory: the system's live view of the market. The strategy / signal reads the book and the tape, computes a signal (a microprice, an order-flow imbalance, a stat-arb spread) and decides whether and what to trade. This is where the edge lives; everything else is plumbing that must not lose money.

Then the downstream half. The OMS / EMS splits in principle into the Order Management System, which tracks the lifecycle and state of every order (working, partially filled, cancelled) and your positions, and the Execution Management System, which decides how to work an order across venues: the routing and execution-algorithm layer; in a small system they merge, but conceptually they are distinct (state-keeping versus execution policy). The risk gate sits between the strategy's decision and the wire, running pre-trade checks in-line (max order size, max position, price collars, message-rate limits) plus a kill switch; it is mandatory, not optional (SEC Rule 15c3-5, the US market-access rule, and MiFID II RTS 6 in the EU). Finally the order gateway encodes the order in the venue's order-entry protocol and sends it, the other end of the loop that began at the feed handler, and together with it the bound on tick-to-trade.

What is the model-development lifecycle, from idea to live?

A strategy moves through four gated stages: idea (a hypothesis about an inefficiency), backtest (test it honestly on historical data), paper trade (run it live against the real market but with no real money), and live (real capital, small, scaling only on evidence). Each gate kills most candidates, and the arrows in the lifecycle loop above also point backwards: live feedback refines the idea.

1. Idea / hypothesis. A specific, falsifiable claim ("order-flow imbalance predicts the next move at this horizon on this venue") because vague ideas cannot be tested or killed; grounded in the microstructure, data and strategy sections. 2. Backtest. Test the idea on historical data, and this is where most strategies should die. The backtesting page is entirely about how a backtest lies (look-ahead, survivorship, optimistic fills, overfitting) and how to make it honest; a strategy that only works with a dishonest backtest is not a strategy, so do not skip this gate.

3. Paper trade (forward test). Run the strategy live against the real, moving market (real feed, real latency, real adverse selection) but routing orders to a simulator or a paper account, not the matching engine. This catches what a backtest cannot: real-time data issues, infrastructure bugs, your own latency, and whether the edge survives contact with a market that did not exist when your historical sample was recorded. 4. Live, small, scaling on evidence. Start with minimal capital and tight risk limits, measure realised performance against the backtest and paper-trade expectation, and scale up only as live results confirm the edge, watching for capacity and alpha decay as size grows. Most of the "edge" found in backtest is gone by here; the survivors are the business.

The point is that it is a loop, not a line: live results feed back into the idea: refine the signal, re-parameterise, retire it when it decays. This is the research-to-production pipeline seen as a cycle, and the discipline that separates a desk from a gambler.

What is the difference between an OMS and an EMS?

An OMS (Order Management System) keeps the state: the authoritative record of every order's lifecycle and your current positions and exposures. An EMS (Execution Management System) makes the execution decisions: how to slice, time and route an order across venues to minimise cost. The OMS is the ledger; the EMS is the execution brain. Small systems combine them; the roles stay distinct.

The OMS tracks each order through its states (sent, acknowledged, working, partially filled, filled, cancelled, rejected), reconciles against execution reports, maintains positions and P&L, and is the source of truth the risk layer reads. If your OMS state diverges from the venue's, you are flying blind; reconciliation is a core, unglamorous correctness problem. The EMS, given a parent order, decides how to execute it: which venue(s) (smart order routing), on what schedule, how aggressively, to minimise market impact and slippage; this is where the execution-algorithms pages live.

In an HFT market-making system the line blurs (the "strategy" is its own execution) but in any system trading meaningful size the distinction matters: one component owns truth, another owns policy.

How do you build this as one person in 2026?

You buy or rent everything that is undifferentiated and build only the edge. Cloud rents the compute (research, backtest, and live for non-speed strategies); open data (crypto, Polymarket, buyable equities/futures) removes the data moat; AI-assisted development writes the feed handlers, the OMS state machine, the backtest harness and the glue. You spend your scarce human judgement on the strategy and on validation.

Concretely: pick a game where speed is not the edge (the colocation/FPGA page's honest conclusion) meaning stat-arb, slower market making, cross-venue, crypto, Polymarket; the microsecond-and-slower band is contestable by one engineer, the nanosecond frontier is not. Rent the compute: cloud VMs run research and backtests, and for a non-speed strategy they can run live too, with the latency trade-off made explicit: no capex, no server room, the single biggest economic change versus a decade ago. Use open/cheap data: crypto venues stream full L2/L3 over public APIs, prediction markets are open, equities/futures history is buyable (the data pages cover what you get and its pitfalls).

Then let AI write the plumbing: an LLM assistant scaffolds a feed-handler parser from a protocol spec, the OMS state machine, a backtest harness, test fixtures and the glue, collapsing the engineering time that used to require a team (see what AI changes for HFT). But keep the judgement human: what to build, whether a backtested edge is real, how to validate fills, when to scale, when to pull the kill switch. None of that is automatable, and getting it wrong loses money fast: the AI does the typing, you do the thinking. The honest caveat is that this works below the speed tier only; a solo builder cannot win the nanosecond race, and the full thesis is on going independent in 2026.

What is the minimum viable build order?

Build the read path before the write path, and the simulator before the live connection. A sensible order: (1) connect a feed and build the book; (2) record and replay it; (3) build the backtest/simulation harness; (4) write the strategy and prove it in backtest; (5) add the OMS/EMS and risk gate; (6) paper trade; (7) go live small.

Step by step: (1) Feed + book builder: subscribe to the venue, decode it, reconstruct the order book, and confirm it matches reality, because nothing works without a correct book. (2) Record + replay: capture the message tape so you can replay deterministically, the foundation of both debugging and backtesting. (3) Backtest / simulation harness: build the honest backtester (market replay, queue/fill modelling) before you have a strategy, so the strategy is tested honestly from day one. (4) Strategy: now write the signal and prove (or kill) it in backtest; most ideas die here, which is the harness working.

And the downstream half: (5) OMS/EMS + risk gate: order state, routing, and the mandatory pre-trade risk and kill switch, built before any order can reach a live venue. (6) Paper trade: run live against the real market with simulated execution, catching the things only reality reveals. (7) Live, small: real capital, tight limits, scale on evidence. The ordering principle is blunt: you can lose money the instant the write path is live, so everything that validates and constrains comes first. Build the parts that can only teach you (feed, book, backtest, paper) before the parts that can cost you.

Worked example

Take a concrete, dated sketch of a one-person crypto market-making system built in 2026, illustrative, to make the architecture and lifecycle tangible (not a recommendation; educational only). It exercises every block in the diagram above, but at millisecond latency rather than the speed tier.

Components. A feed handler decoding a single crypto venue's WebSocket snapshot-plus-diff feed; a book builder maintaining one symbol's L2 book; a microprice-and-inventory strategy (Avellaneda–Stoikov-style); a combined OMS/EMS placing and amending two-sided quotes; a risk gate with a max-position limit and a kill switch; and an order gateway over the venue's REST/WebSocket order API. Infrastructure: a single cloud VM near the venue's region (millisecond latency, fine for slower market making, hopeless for latency arbitrage) with no colocation, no FPGA, no capex.

Lifecycle. The idea is to quote around the microprice and skew on inventory. The backtest replays a month of recorded book data through the honest harness with realistic queue/fill and fees; kill it if the "edge" is just ignored costs. The paper stage runs live quoting into a simulator for two weeks, measuring realised spread captured against adverse selection paid. The live stage uses tiny size and tight limits, scaling only as realised P&L tracks expectation, watching capacity and decay.

Where the time went tells the whole story. With AI-assisted development the plumbing (feed handler, book, OMS, harness scaffolding) is days, not months; the real work, validating that the backtested edge survives paper trading and live fees, is where the weeks go. That ratio is the 2026 shift, and it is the same lesson the going-independent thesis turns on. Figures and venue mechanics are illustrative and change; verify the specific venue's API, fee schedule and limits as of 2026. Educational only, not investment advice; no performance is implied.