Platform: Systematic futures framework
License: GPL-3.0-only
Pricing: Free and open source
Live trading: Automated futures trading through Interactive Brokers
Best for: Systematic futures portfolios that combine forecasts with volatility-scaled position sizing

pysystemtrade follows a defined method for trading diversified futures portfolios. It combines several forecast rules, uses volatility-scaled position sizing and portfolio risk controls, manages contract rolls, and can trade through Interactive Brokers. The design follows Rob Carver's published methodology. It is not a general broker-agnostic backtesting library or a quick place to try an unrelated strategy.

The project supports both simulation and automated futures trading, but that breadth comes with substantial setup. Live trading needs market and contract metadata, historical prices, roll configuration, FX data, saved state, broker configuration, scheduled tasks, monitoring, account reconciliation, and safety controls. Reusing forecasting and sizing logic across research and live trading reduces translation work. It does not make backtest prices equivalent to broker fills.

Installation and license

pysystemtrade is not distributed through PyPI. Install it from its repository and follow the official setup guide.

The repository uses the GPL-3.0-only license. Review the copyleft obligations before distributing a modified or combined system.

How the pipeline is organized

A backtest is a System assembled from stages. The main futures configurations connect data, trading rules, forecast scaling and capping, forecast combination, position sizing, portfolio construction, risk overlays, buffering, and accounting. Configuration files can replace weights, estimators, rules, instruments, and risk targets without changing every stage.

The structure is useful because each value has a traceable role:

Layer	Main question
Data and contracts	Which adjusted price, carry contract, FX rate, multiplier, and roll state are valid?
Trading rules	What directional forecast does each rule produce?
Forecast scaling and combination	How are rule outputs normalized, capped, weighted, and diversified?
Position sizing	How many contracts correspond to the volatility target and available capital?
Portfolio and risk	How are instrument weights, correlations, concentration, and overlays applied?
Accounting	What return remains after rolls, commissions, spreads, and other modeled costs?

This stage model makes the framework auditable, but it also means that changing a seemingly small input, such as a contract multiplier or roll rule, can affect forecasts, risk, orders, and profit and loss downstream.

A small forecast-rule example

The following example calls pysystemtrade's public exponentially weighted moving-average crossover function directly. It uses a constant daily price volatility so that the output is easy to inspect.

import pandas as pd

from systems.provided.rules.ewmac import ewmac


prices = pd.Series(
    [100, 101, 100, 102, 104, 103, 105, 108],
    index=pd.date_range("2026-01-02", periods=8, freq="B"),
    dtype=float,
)
daily_price_vol = pd.Series(2.0, index=prices.index)

raw_forecast = ewmac(prices, daily_price_vol, Lfast=4, Lslow=8)
print(raw_forecast.round(3).tail(3).to_string())

Executed against the develop source on September 19, 2026, the final three raw forecast values were 0.214, 0.327, and 0.573. This checks one rule component only. The function returns an unscaled and uncapped forecast, and the constant volatility input is artificial. A complete system must estimate volatility without look-ahead, scale and combine forecasts, size positions, apply portfolio controls, and model costs.

The official introduction shows how this rule fits into a full System using the repository's futures data. Use that pipeline for an actual backtest rather than treating a raw EWMAC value as a position or an expected return.

Futures data is part of the model

The futures data workflow builds individual contract histories, roll calendars, multiple-price series, back-adjusted prices, instrument configuration, and spot FX. Those artifacts answer different questions. An adjusted series is useful for a continuous forecast, while trading and cost calculations need the actual contract, multiplier, roll, and currency.

Review these choices before trusting a result:

Roll construction: Roll dates and adjusted-price methods can change trend and carry signals. Use only information available at each historical date.
Contract metadata: Multipliers, tick sizes, commissions, spreads, trading hours, and expiry rules change through time and across venues.
Price granularity: The documented futures workflow stores OHLC plus a FINAL settlement or close, while much of the system uses the final series. Daily values cannot reveal intraday paths, queue position, or temporary liquidity.
Instrument universe: Current exchange access, capital, liquidity, and duplicate exposures may differ from the bundled research universe.
FX conversion: A stale or misaligned FX series distorts risk, capital, and profit and loss for non-base-currency contracts.

The repository includes sample data for learning and book examples. Sample data should not be assumed current, complete, point-in-time clean, or suitable for live capital.

Production trading is an operations project

The production system uses ib_async to connect to Interactive Brokers. Its architecture separates simulation data from production interfaces and adds price updates, optimal positions, order stacks, fills, capital, position and trade limits, overrides, locks, process control, reports, and reconciliation. The official production and instrument guide also distinguishes backtest configuration from the global configuration used downstream for live orders.

Before enabling order submission, verify at least the following in a paper account:

Broker contract identifiers, currencies, multipliers, trading hours, and permissions match the local instrument configuration.
Local positions, open orders, cash, and capital reconcile with the broker after startup and disconnects.
Roll state and priced, forward, and carry contracts update in the intended sequence.
Position limits, trade limits, overrides, and kill procedures work under partial fills and stale data.
Scheduled price, FX, strategy, order, reporting, cleanup, and backup processes are monitored and idempotent.
Logs, alerts, database backups, and recovery procedures are tested before unattended operation.

The Interactive Brokers adapter is a concrete production path, not evidence that every account, region, exchange permission, or order type will behave identically. Paper fills also do not validate live liquidity or operational resilience.

When to choose another framework

pysystemtrade imposes a futures-specific vocabulary and methodology. That is helpful when you want its forecast normalization, volatility targeting, diversification, buffering, and roll machinery. It is unnecessary overhead for a small equity signal study, crypto exchange bot, intraday order-book strategy, or a team that needs a broker-neutral execution service.

Choose pysystemtrade for a Carver-style systematic futures portfolio when you are prepared to understand and operate the whole data-to-order chain. For faster hypothesis screening or other asset and execution models, use a framework whose assumptions match the research question, then preserve point-in-time inputs and realistic transaction-cost assumptions regardless of the engine.

pysystemtrade