X_QUANT: INSTITUTIONAL-GRADE QUANTITATIVE TRADING PLATFORM

Overview

X_Quant is a single-operator quantitative trading platform built around one frozen strategy — cfg_00 / MetaEnsemble v56, a long-only momentum system trained on ~15 years of hourly US-equity data. The strategy is locked (no live re-fitting); the engineering effort goes into validating it honestly and wrapping it in institutional-grade risk, compliance, and execution infrastructure.

Its defining trait is intellectual honesty about its own state. The codebase draws a hard line between the strategy that was validated and the strategy that is actually trading — and reports the gap rather than papering over it. It trades on an IBKR paper account today; live is gated behind account permissions and a certified-engine deploy.

The Honest Core: Validated ≠ Traded

Most trading systems present a backtest and imply it is what runs in production. X_Quant refuses to.

• The validated engine (cfg_00) lives in the CSCV harness: inverse-volatility sizing, a 5% position cap, a rolling beta-neutral SPY hedge, and vol-target / drawdown / crash overlays.
• The live daemon still executes a simpler LEGACY engine: top-≤98 signal-proportional weights, with no hedge, no cap, and no overlays.

So the current paper track record measures the legacy engine — not cfg_00 — and the CSCV certificate (PBO = 0.0108) does not certify what is in production. The remediation (porting production onto the certified engine) is an explicit, gated phase; when it deploys, the Phase-1 clock restarts from zero, because the pre-deploy paper data is a different regime. This is logged as Incident P-2 — one of a standing register of incidents the project keeps in the open.

Validation & the R1 Campaign

The strategy is defended against overfitting the way a hedge fund defends external capital:

• CSCV — Combinatorial Symmetric Cross-Validation with a canonical power test.
• PBO — Probability of Backtest Overfitting: 0.0108 for cfg_00 (Sharpe 5.24 out-of-sample, through COVID).
• Pre-registration — every validation campaign is committed before it runs; a FAIL is a legal outcome.

The latest campaign, R1, just completed (2026-07-22) — re-validating cfg_00 on the live-tradable universe. The raw result: PBO = 0.0000 (0 of 462 overfit configurations at both k=5 and k=6). But the campaign flagged its own fragility caveat — a leave-one-out PBO swing of 0.1126 (> 0.10), meaning the result leans on a single configuration. Per the project's own rule, no PASS is declared until the formal wrap-up report is written — so the verdict is deliberately still pending. Reporting the caveat and withholding the verdict is the discipline working as intended.

Universe & Constraints

The live-tradable universe is 424 instruments (∪ SPY) — 590 candidates minus 159 PRIIPS-blocked US ETFs (no EU-retail KID) minus 7 delisted. Different pipeline stages legitimately use different counts (529 legacy-prod, 619 / 615 / 562 in validation at different history thresholds), and a reconciliation report tracks each — including flagging a stale "534" left in older docs. Code is the source of truth over documentation.

Effective Risk Controls (code = truth)

The system audits what the code actually enforces, not what the docs claim:

• Position cap = 5% effective (a config-declared 4% is a dead value, floored to 5%); the legacy engine has no cap at all.
• Kill switches — daily −3% / weekly −5% / max-drawdown −10% (tightened from an aspirational 15% down to the backtest's 6.59% envelope), wired into the money-path.
• VIX ≥ 60 = alert-only — an auto-flatten path exists but is deliberately gated dormant, after a history of feedback-loop bugs.
• Deadman + launchd KeepAlive — a 300s deadman switch plus process respawn; recovery after an alert is deliberately manual, not automatic.

Aladdin-Grade Layers

The platform is being built toward the institutional risk/compliance stack that systems like BlackRock's Aladdin provide — mapped deliberately, with an explicit anti-roadmap for what a single-operator system should not build:

Institutional function	X_Quant equivalent	Status
Risk analytics (ex-ante VaR)	VaR backtest — Kupiec POF, Christoffersen, Basel traffic-light	deploy-ready (behind flag)
Compliance engine	Rulebook + advisory rule-engine (codifies existing limits, adds none)	deploy-ready (behind flag)
Factor model	Fama-French factor risk decomposition	planned
Pre-trade what-if	Calls the certified core, not a separate engine	planned
Cost model / TCA	Transaction-cost analyzer + TCA loop	planned
Book of record (IBOR)	journal.db (trades, snapshots, signals)	live
Front-to-back	One certified core consumed by research and production	pending deploy

The risk and compliance layers pass 19/19 independent + 12 baseline verification checks; both ship disabled behind flags, and compliance runs advisory-only (it logs would-block events, it never blocks) until the certified engine has cleared multiple clean rebalances.

Anti-roadmap — consciously not built: multi-asset, an accounting book-of-record, multi-tenancy, and a meta capital-allocator (which only makes sense across many strategies; cfg_00 is one).

What It Has That Aladdin Doesn't

• Campaign pre-registration — commitments locked before a run; a documented FAIL is legal.
• PBO / DSR / canonical CSCV power test — an explicit, quantified defense against overfitting.
• A public incident register — P-1 (config-as-deploy), P-2 (validated ≠ traded), P-3 (money-path outside version control), P-4 (private-repo journal exposure) — each with an evidence class and a status, closed or in remediation.

Production Notes

• Operations — a nightly coordinator (23:40 CEST) does a clean IBKR bootout → reset → bootstrap; rebalance, snapshot, and daily-report run on fixed slots. Deploys go only through the nightly window to avoid wedging the IBKR Gateway API.
• Evidence discipline — every claim in the system briefing carries an evidence class: [VERIFIED-smoke] (actually run), [VERIFIED-static] (code-verified with file:line), [DORMANT], [PENDING-DEPLOY]. Documentation that drifts from the code is flagged, not trusted.
• Trading — IBKR paper account (Gateway port 4002); the live account waits on permissions and the certified-engine deploy.

Tech Stack

Python, NumPy, Pandas, a CSCV / PBO / DSR validation harness, Interactive Brokers API (IBKR Gateway), inverse-volatility sizing, beta-neutral hedging, VaR (Kupiec / Christoffersen / Basel), macOS launchd services, SQLite (journal.db as IBOR), git-tagged pre-registration.

Evolution

X_Quant began as a classical ML-driven signal pipeline (v1: ~30 alphas, a 6-model XGBoost / LightGBM / CatBoost ensemble, CPCV validation) and consolidated over time into the single frozen MetaEnsemble v56 strategy it validates and trades today. The through-line across every version is the same: validate honestly, then defend the validation.