An open, plugin-based architecture for systematic trading.
Broker-agnostic. Risk-first. Built to add strategies without touching the core.
01 The three-layer model
The platform is organised in three horizontal layers. Each has a single responsibility. The layers are decoupled through uniform interfaces — not through leaky abstractions.
The common core owns market data ingestion, order routing, risk supervision, kill-switch enforcement, config-versioning (a database table called bot_epochs), P&L reconciliation from official broker fills, backtesting with measured-cost realism, and monitoring surfaces.
Broker adapters translate the core's uniform operations to each venue. Currently IBKR (four paper gateways) and Alpaca (three paper accounts). Adding a new broker is a bounded task — write one adapter — not a rewrite.
Strategy plugins implement a small, uniform interface. Signals in, orders out, risk-managed automatically by the core. The core does not need to know what any given strategy does. Currently plugged in: Undertow trio, Bot-C fleet, Donchian pair, Bot-ORB, Bot-Swing, with Bot-Donchian3 launching.
02 Five disciplines wired into the core
The value of the platform is not any single strategy. It is the set of disciplines the core enforces on every strategy that plugs in. Each of these is code, not policy.
Config-versioning
Every strategy config change is a dated epoch in a database (bot_epochs). P&L is attributed per epoch. No blending across parameter changes. Ever.
Kill-switch discipline
Per-bot and portfolio-level. Bots can flatten themselves, be flattened, or be paused for review — all logged. Every order path terminates in a known state, never orphaned.
Official-fills reconciliation
P&L is computed from broker fills, not from internal ledgers. Undertow already runs this against Alpaca fills. Nothing quoted on the site is invented.
Cost realism
A 1,044-fill audit produced a measured 40bps/leg slippage on open-fill bots. That's what backtests use. Not 5bps. Withdrawn numbers are marked as withdrawn.
Retirement discipline
Bots that don't perform get retired — publicly, with the reason. Bot-Bounce (retired 08-03, live-realized soft). Bot-DWide (decommissioned forever, "who buys falling knives"). Bot-C H2/H3/H5 (killed). Bot-ORB2 (repurposed). See the Track Record retirement log.
03 What this design enables
- Adding a new strategy is a self-contained development effort — typically days, not weeks. The core does the heavy lifting.
- Adding a new broker is a bounded adapter, not a rewrite. Every existing strategy inherits the new venue automatically.
- Running 11 concurrent strategies across 2 brokers requires the same operator attention as running 3. Discipline scales.
- Migration to institutional infrastructure — co-location, direct market data, potentially FPGA where relevant — is an infrastructure-layer swap. The strategies and risk-core stay intact.
- Every strategy inherits the same monitoring, kill-switch, attribution, and reconciliation properties. Nothing is bespoke where it shouldn't be.
04 What it doesn't (yet) do
True HFT. Even at ~10ms round-trip we are not competitive with venues where microseconds matter. That was a deliberate scoping decision after early measurement work — not a design failure. The strategies here are engineered to operate profitably at the platform's actual latency band, not at fictional one.
Given institutional infrastructure — the kind of tick data, colocation, and order routing that JP Morgan or Citadel operate — several of the strategies here would extend materially. The platform is designed to make that migration bounded. The strategies themselves would need only their assumptions updated; the core would not need to change.
05 How this differs from most systematic-trading builds
Most systematic trading systems start as one strategy in a script and grow into an unmanageable pile of one-off code. Adding a second strategy means duplicating infrastructure. Adding a third means the observability breaks. Adding a fourth means the risk framework is inconsistent across bots. By the fifth strategy, most solo builders quietly retire the earlier ones because there is no longer any way to reason about the whole.
Quanta Privé was designed from day one as a platform, not as a strategy. Every discipline listed above is enforced by the core, not by developer memory. That is why running 11 strategies is feasible with one operator, and why the number can grow.
06 Get in touch
For technology conversations, engineering partnerships, or platform-licensing discussions: contact@quantaprive.com.
For the story of who built this and why, see About. For real numbers, see Track Record.