Quantitative Trading Platform
A low-latency, multi-timeframe execution framework in Rust. Deterministic indicators, unidirectional data flow, and capital-preserving risk gates — built to be auditable before it ever touches real money.
- Role
- Sole architect & engineer
- Timeline
- 2026 — Present
- Stack
- Rust · Tokio · Axum · TimescaleDB · PostgreSQL · WebSockets · rust_decimal
Why a quant platform?
Retail trading software usually falls into two traps: spaghetti code where every indicator reads and writes the same global state, or a fragile monolith where a bug in execution can corrupt the analytical pipeline. I wanted neither. The goal was an audit-grade system where signal validation, risk assessment, and capital execution are decoupled, deterministic, and easy to reason about under stress.
A two-dimensional framework.
The codebase is organized along two orthogonal axes. Horizontally, five decoupled engines each own one business domain (data ingest, market monitor, automation, portfolio, analytics) and never share memory — they communicate exclusively through typed, read-only message streams. Vertically, each engine breaks its logic into a stack of isolated layers; each layer consumes its parent's output and emits an immutable, versioned matrix.
Hot path math vs. cold path math.
A core tension in trading software is between raw floating-point performance for indicators and penny-perfect fixed-point accounting for ledgers. The system resolves this with a strict type-boundary handoff: the hot path uses cache-aligned, SIMD-friendly f64 buffers, while the cold path (order routing, position ledger) uses 128-bit fixed-point decimals. The handoff lives at one well-defined boundary, never silently across the system.
Unidirectional cascade with a fast-track veto.
Information flows forward: data → market monitor → automation → portfolio. Upstream engines are entirely blind to downstream state, which guarantees that an execution-layer bug can never poison signal generation. The only exception is the Portfolio Veto — a fast-track backward interrupt that, on a drawdown breach, instantly downgrades execution stances to AVOID or CLOSE_ONLY.
Pre-trade risk gates, every order.
Every order must pass a ladder of fail-closed gates before reaching the exchange: lifecycle check, stance check, exposure check, slippage review, and the PME safety veto. The gates are explicit, individually testable, and run synchronously on the critical path. The system is also intentionally staged: the analytical engines are in production under paper-trading conditions while the execution engines remain frozen blueprints — validated long before they touch real money.
What shipped, what I'd do next.
The data-ingestion and market-monitoring engines run in production today, processing live telemetry and publishing advisory signals across multiple timeframes. Position sizing and execution remain deliberately staged. Next steps I'd take in a v2: introduce a deterministic replay engine for back-testing, swap the custom message bus for a battle-tested one like NATS, and add formal property tests on every risk gate.