Fintech & Algo Trading

How a Prop Trading Firm's Tech Stack Is Structured

At Enigma Securities, three engineers built a full HFT stack from scratch. No existing infrastructure to inherit. Five venues, a co-located rack at Euronext's Paris POP, sub-15ms tick-to-order on primary instruments. We hit the latency target in about eight months. What follows is how a prop trading firm's tech stack is actually structured, what each layer is responsible for, and what breaks first when you get any of them wrong.

The Four Layers

Every prop firm's stack splits into four layers. Each has a clear job, and each has different failure modes. The failures cascade: a bad market data layer means your strategy runs on stale prices, and your execution layer delivers bad orders to the exchange with excellent latency.

• Market data — feed handling, book building, and data distribution
• Strategy and signal — research environment, backtesting, and live signal computation
• Execution — OMS, EMS, FIX connectivity, and pre-trade risk
• Infrastructure and ops — co-location, monitoring, deployment, and the kill switch

Most engineering time concentrates in market data and execution. Those are performance-sensitive. Strategy and ops matter as much, but they're easier to iterate on without breaking live trading.

Market Data Infrastructure

Feed handling is where latency starts. Every microsecond lost here flows downstream into every order you submit.

At Enigma, we ran raw binary feeds for primary execution venues — Nasdaq ITCH, Euronext's binary protocol, SBE feeds from CME for derivative reference prices. Parsing in C++ directly off the NIC into a lock-free ring buffer: 3-4 microseconds from interrupt to book update. A normalized vendor feed over UDP multicast added 50-200 microseconds on top. That gap is the cost of abstraction. For HFT, you pay it in lost edge.

Book building is a separate process from feed handling. The feed handler parses messages and writes to the ring buffer. The book builder reads from the buffer and maintains the order book state: bid/ask levels, quantities, last trade. Two threads, one shared data structure with atomic access. Tight, simple, testable in isolation.

Feed redundancy matters more than most new teams expect. Exchanges drop packets. Connections reset. Your feed handler needs sequence number tracking, gap detection, and a clean reconnect that rebuilds book state correctly. A strategy running on a stale book after a missed gap fill trades on wrong prices. We ran two independent connections per primary venue, automatic failover in under 10 milliseconds.

Clock synchronization is non-optional. Without PTP hardware timestamping, your latency measurements are noise. A Cisco switch with PTP support and hardware NIC timestamps runs a few hundred dollars. Without it, you'll spend days debugging latency spikes that turn out to be measurement artifacts.

Strategy and Signal Infrastructure

The research environment and the production trading environment should be separate. They almost never are in small shops. That's a consistent source of alpha decay.

Research infrastructure is optimized for iteration: fast backtests, notebook-based exploration, vectorized operations on historical data. Python with pandas, numpy, and polars is standard. Custom backtesting engines are common because most open-source options handle fill logic too simplistically. The goal is speed of experimentation, not production reliability.

Production signal infrastructure is different. Minimal allocations. Deterministic execution times. No Python GC pauses on the hot path. If your signal is running in Python, it needs to be a tight asyncio loop — no blocking I/O, no dynamic object creation in the signal path. For sub-millisecond work, signal computation moves to C++.

The gap between research and production is where strategies die. I've seen 1.8 Sharpe in backtest become 0.3 Sharpe live, not because the signal was wrong, but because the live implementation computed a moving average on tick data instead of OHLCV bars. Bridge this gap by requiring that production signal code reproduce the same results on historical data as research code, before capital goes live.

Signal distribution from strategy to OMS should be fast and deterministic. At Enigma we used custom binary structs over shared memory on the critical path: no serialization round-trips, no heap allocation. For strategies with holding periods over a second, ZeroMQ over IPC is fast enough and far simpler to maintain.

Execution: OMS, EMS, and Pre-Trade Risk

The OMS is the state machine at the center of everything. It tracks every order's lifecycle — new, submitted, acknowledged, partially filled, filled, cancelled — and is the single source of truth for open orders and positions. Nothing else in the system should independently maintain position state. Two components tracking position is how you end up with a real net position of +100 contracts and a risk view of +50.

Our OMS state was an in-memory unordered_map with a custom slab allocator: order ID to order state struct, O(1) lookup. Persistence was async via write-ahead log on a dedicated thread. Recovery on restart replayed the log to rebuild state. SQLite with WAL mode works fine at moderate throughput; Kafka handles higher write rates.

The EMS wraps OMS orders in FIX messages and manages exchange connectivity. FIX 4.4 or 5.0 covers nearly every execution venue. We ran QuickFIX/n in C++ for primary venues, QuickFIX in Python for secondary connectivity used by the research desk. FIX session management — logon, heartbeat, reconnect — is handled by the library. Your ownership is the business logic layered on top.

Pre-trade risk runs synchronously on every order before it reaches the EMS:

• Position limit: does this push net position above the instrument cap?
• Notional cap: is the order value within single-order bounds?
• Fat finger: is the submitted price more than X% from market mid?
• Rate limit: have we exceeded N orders per second?
• Duplicate detection: is this order ID already in flight?

Each check is a single comparison against a pre-computed threshold. Our full pre-trade suite ran in under 2 microseconds. That's achievable in C++ with no dynamic allocation on the hot path. Every microsecond you add here is a microsecond removed from execution edge.

The kill switch is the most important component in the system. One function call: cancels all open orders, stops new submissions, optionally triggers position flattening. Build it on day one. Test it under load during market hours with real orders in flight. A kill switch you've tested once in staging is not a kill switch.

Infrastructure: Co-location, Monitoring, and Ops

Co-location puts your servers physically in the exchange's data center. Round-trip to the matching engine drops from 2-5ms over a cloud VM to sub-100 microseconds. At Enigma, we co-located at Euronext's POP in Paris for European equities and used a cross-connect to Deutsche Börse for German instruments. A cross-connect is a physical cable from your rack to the exchange's rack — no shared network, deterministic latency.

Co-location costs money. Rack space, power, cross-connect fees, and managed switches run $3,000-10,000/month depending on venue and configuration. The economics work only if you're competing on execution speed. If your holding period is minutes or longer, a well-connected cloud VM is fine. AWS us-east-1 for US equities, eu-west-1 for European venues — 1-5ms to the exchange, which is irrelevant for strategies holding over seconds.

Monitoring is not optional. We ran Prometheus collecting metrics from every component and Grafana dashboards for live P&L, order flow, fill rates, position by instrument, and risk check hit rates. Three alert levels: warning (check the board), critical (someone wake up), emergency (kill switch auto-triggers).

The emergency alert triggered the kill switch automatically when cumulative P&L dropped below a hard drawdown threshold. We set it at two times the average daily loss on a losing day. It triggered twice in two years. Both times, the system caught a runaway condition faster than any human would have.

Deployment discipline matters. We used blue-green deployment for production changes: new version deployed to a shadow environment, verified against live market data without order submission, then hot-swapped as the live system. Rollback meant flipping the environment pointer back. Rollback time: under 30 seconds.

Stack by Strategy Type

The right stack depends on your latency target and holding period. Here's how the key components differ across strategy types:

The C++ requirement is driven entirely by your latency target. Below 1ms, you're writing C++ and paying for co-location. Above 1 second, Python is fine and cloud infrastructure works. Most new teams over-engineer the bottom of the stack and under-engineer the kill switch and monitoring. Get the risk controls right first. The latency optimization can come later.

The most expensive mistakes in a prop firm's stack aren't crashes. They're silent wrong positions: a stale book, a missed fill confirmation, a risk check that passed when it shouldn't have. Build for observability from day one. A system you can inspect under pressure is worth more than a system that's fast but opaque.