Methodology

System Overview

This track record is produced by rob_system, a systematic futures trading strategy implemented in pysystemtrade—the open-source Python framework created by Rob Carver for designing, backtesting, and running systematic trading strategies.

The system is fully systematic: every trading decision is generated by rules and code. There are no discretionary overrides.

Key Parameters

Parameter	Value
System	rob_system (pysystemtrade)
Notional capital	USD 500,000
Annual volatility target	25%
Forecast cap	±20
Base currency	USD

Universe

The strategy trades 269 futures instruments across global asset classes: equity indices, government bonds, short-term interest rates, FX pairs, commodities, metals, energies, crypto, and volatility contracts. The universe expands gradually as new instruments pass data and validation gates — see the methodology event log for each change. This broad diversification is central to both risk management and return generation.

Trading Rules

Multiple uncorrelated trading rules generate raw forecasts for each instrument. The rule set is deliberately diversified across style factors:

Style	Rules
Trend-following	EWMAC variants (assettrend, normmom, momentum, breakout, accel)
Relative momentum	relmomentum
Mean reversion	mrinasset1000
Carry	carry, relcarry
Skew	skewabs, skewrv

Forecast Combination

Raw forecasts from each rule are combined using estimated forecast weights and a forecast diversification multiplier. The combined forecast is capped at ±20 before being passed to position sizing. This cap limits the maximum conviction any signal combination can express, reducing tail risk from extreme positioning.

Position Sizing

Positions are sized dynamically to target the portfolio’s annualised volatility goal. The system uses a mixed volatility estimator that blends a 35-day fast component with a 20-year slow component, balancing responsiveness to recent regime changes against long-run structural volatility. Positions are rounded to whole contract blocks.

Portfolio Construction

Instrument weights and an instrument diversification multiplier are estimated from historical correlations. The portfolio construction process allocates risk budget across instruments so that each contributes proportionally to the portfolio’s risk target, rather than naïvely equal-weighting notional exposure.

Risk Overlay

A risk overlay enforces hard limits on:

Total portfolio risk (annualised volatility relative to target)
Maximum leverage
Sum of absolute risk contributions across all positions

If any limit is breached, positions are proportionally reduced until the portfolio is back within bounds.

Execution & Costs

Forecast buffering is used to reduce unnecessary turnover: small changes in forecast that don’t cross a buffer threshold do not trigger trades. This significantly reduces transaction costs while preserving most of the strategy’s edge.

All performance figures on this site are reported net of all realised transaction costs: commission, slippage, and roll costs are embedded in the broker NAV series from which returns are derived (see “How returns are computed” below).

Contract Rolls

Futures positions are rolled forward before expiry on a per-instrument schedule driven by liquidity. For each instrument, pysystemtrade selects a held contract and a forward contract; when the configured roll calendar triggers, the system closes the held contract and opens an equivalent position in the forward.

Roll P&L is captured in the broker NAV on the day the legs execute, so it flows through the daily return series automatically — there is no separate “roll yield” adjustment. Rolls that execute over multiple days (because of liquidity or partial fills) are similarly captured day by day.

Track Record Period

The published return series begins 2025-11-04, the first day on which the live broker NAV series is clean enough to compute a verified daily TWR. Earlier live trading exists (the system has been running since late 2024 at smaller capital) but is not included in headline figures because the underlying NAV data has known gaps and is not independently verifiable. The methodology event log on /events/ documents the inception and universe-expansion events.

How returns are computed

All headline returns on this site are time-weighted returns (TWR) derived from the daily NAV series produced by Interactive Brokers’ Flex Query report (EquitySummaryByReportDateInBase). The broker NAV is the authoritative source — pysystemtrade’s internal capital series is used for live position sizing but is not used to compute published returns.

The daily return for day t is computed as:

daily_return_t = (NAV_t − NAV_t−1 − deposit_t) / NAV_t−1

and cumulative return is the chained product:

cumulative_return = ∏_t (1 + daily_return_t) − 1

Capital additions and withdrawals do not affect reported performance. On any day with a deposit or withdrawal, the corresponding cash flow is subtracted from the NAV change before computing the day’s return — so the deposit itself contributes 0% to that day’s TWR and the next day’s denominator is the post-deposit NAV. Step-ups in capital change position sizing going forward but never re-base the historical curve. Money-weighted (dollar) P&L is retained internally for audit but is not used in any published return number.

External capital movements are verified against IB Flex ChangeInNAV.depositsWithdrawals and removed from the return series. Where the amount is known it is netted out of that day’s account change, so the trading result that occurred alongside the movement is preserved. Three account-opening deposits — 2025-11-06, 2025-12-23 and 2026-01-13, together roughly USD 222k of personal capital — are instead recorded as flat days: each was larger than the account that received it, so no honest same-day return can be reconstructed from end-of-day values alone.

Restatement, 2026-08-07. Every day carrying a capital movement was previously recorded as flat. That kept the movement out of performance but also discarded the trading result underneath it, which can only flatter the record when the discarded day was a losing one. Switching to netting restated the since-inception return from +42.16% to +40.65% and year-to-date from +45.47% to +43.92%. The published figures are the corrected ones.

This is the same convention used by GIPS-compliant performance reporting and by Carver in Advanced Futures Trading Strategies; it is the only convention that makes returns comparable across capital regimes.

Independent verification. The chained TWR computed from the Flex NAV series matches IB’s own ChangeInNAV-based TWR to within 0.42%. The residual reflects intraday timing differences between the deposit timestamp and the end-of-day NAV snapshot, plus FX translation rounding; it is not a data error.

Backtest context [BACKTEST]

Everything above the dashboard is real fills. The two charts below are not. They show the current system configuration run over historical data (2000–2026) — a simulation, with all the usual reasons a backtest flatters itself: the instrument set was chosen with hindsight, several instruments didn’t trade or have data for much of this period, and costs are modelled rather than paid. I show it because seven live months can’t tell you how this system behaves in a trend-following drought, and these years can.

Return by calendar year

Every year in the window, good and bad. Trend following earns most of its return in a few strong years and gives some back in the long flat stretches between them — the shape matters more than any single bar. The early years are the least trustworthy: they ran on a fraction of today’s instruments, so the largest bars overstate what the current universe would have produced.

Drawdowns, with the hard stretches marked

The underwater curve — how far below the prior high-water mark the simulated book sat, day by day. The shaded windows are the deepest drawdowns in the period; they are where a real holder’s patience gets tested.

Backtested drawdown curve with stress windows marked

A backtest is the weakest evidence on this site, not the strongest. It is here for context on regime behaviour, not as a performance claim.

Trading-rule correlations [BACKTEST]

The system combines 40 trading rules. This grid is the correlation of each rule’s realized contribution to the book — not the raw signal, but the weighted P&L each rule actually produced after the risk and cost overlay. Red means two rules tend to make and lose money together; blue means one tends to be up when the other is down.

Heatmap of correlations between trading-rule contributions

The large red block is the trend-following core — momentum, breakout, acceleration and asset-class trend rules at different speeds are mostly variations on the same idea, so they move together. The smaller bright-red square is the carry family: tightly correlated with each other but nearly independent of trend, which is exactly why it’s worth carrying alongside. The cool cells — the skew, relative-value and mean-reversion rules (mrinasset most of all) — are what earn their place by leaning against the trend core: when trend is being whipsawed, these tend to hold up.

An honest note on what this is and isn’t: this is the post-overlay structure. Much of the anti-correlation you see is produced by the dynamic optimiser allocating risk across the book, not by the underlying signals being independent — strip the overlay and the families are far less negatively correlated. The diversification is real in the system as it actually runs; it is the optimiser doing its job, measured over backtested history, not a performance claim.