pysystemtrade: Rob Carver's Futures Backtesting and Trading Engine in Python

What pysystemtrade actually is, and who it is for

pysystemtrade is the open source version of Rob Carver's own backtesting and trading engine. It implements systems according to the framework set out in his book "Systematic Trading", and the README describes it as three things at once: a backtesting environment he uses to test strategies from his books, an implementation of the optimisation and system design principles from his writing, and a fully automated system for futures trading through Interactive Brokers.

The intended audience is stated plainly in the README's support note. The project is "designed for people who are already comfortable using and writing python code, are capable of installing the dependencies, and who want a head start on implementing a system of their own." That sentence is the honest scope statement. If you want a supported product, the README says you are better off with another project.

So the problem it solves is not "how do I trade futures" in the abstract. It is "I understand systematic trading and I do not want to rebuild the instrument mapping, position sizing, forecast scaling and order plumbing from scratch." The repository layout reflects that: separate packages for data (sysdata), brokers (sysbrokers), execution (sysexecution), control (syscontrol), production running (sysproduction) and quantitative logic (sysquant).

How the engine is put together

The top level of the repository is organised by responsibility rather than by feature, which tells you a lot about the intended data flow. sysdata handles the futures data and the configuration that maps instruments. systems holds the strategy definitions, and systems/provided contains the rule sets shipped with the project as YAML files. sysquant holds the quantitative calculations, sysforecast the forecast generation, and sysexecution the conversion of desired positions into orders. sysbrokers contains the broker layer, with a dedicated IB subtree for Interactive Brokers.

Connection to Interactive Brokers goes through the ib_async library, which the README names explicitly and which pyproject.toml pins as ib_async>=2,<3. Configuration is YAML, and the packaging declarations in pyproject.toml show which directories ship YAML and CSV alongside the code: private, syscontrol, sysdata.config, sysbrokers.IB.config and systems.provided. That matters because a fresh clone carries the shipped configuration but the private directory is where your own settings live.

The production side is a separate concern from backtesting. docs/production.md is the entry point for running it as a live system, and sysproduction plus syscontrol exist for that purpose. The dependency list supports this split: pymongo is pinned at 3.11.3, and there is an optional arctic extra pointing at the man-group arctic repository, which is the kind of storage you need when you are keeping time series rather than reading a CSV once. Flask and Werkzeug are present, and there is a dashboard directory, so a running production system has a web surface.

Installing pysystemtrade and running a first backtest

The package is not on PyPI, and the README is direct about this: "This package isn't hosted on pypi.org." Installation is therefore from git. The README gives these commands, and they should be run in order.

git clone https://github.com/pst-group/pysystemtrade.git
cd pysystemtrade
python -m pip install .

If you intend to modify the code rather than just use it, the README offers an editable install with development dependencies instead of the plain install:

python -m pip install --editable '.[dev]'

That dev extra is defined in pyproject.toml as pytest>6.2 and black==23.11.0. The Python floor is stated in two places: pyproject.toml sets requires-python to >=3.10, and setup.py exits with an error message below 3.10.0. Note that setup.py and requirements.txt both carry a header saying this method of installing the project is deprecated and that the file will be removed in a future release, so treat pyproject.toml as the source of truth for dependencies.

The README points to docs/installation.md for a more complete guide, and to docs/introduction.md as the place to start. The repository also ships an examples directory with subdirectories for data, introduction, logging and production. Those example files are the practical way in, and pytest is configured with norecursedirs set to "examples", which confirms they are meant to be read and run by hand rather than collected as tests.

One thing the README does not do is walk you through a first backtest command. It gives the install steps and then hands you to the docs. If you want a copy-pasteable first run, the introduction documentation and the examples/introduction directory are where you have to go.

The support model is the real constraint

The most important limitation is not technical. The README states that the project is for people who can install the dependencies themselves, and that "if you need a higher level of support then you are better off with another project." That is an unusual thing for a README to say, and it should be read as a boundary rather than modesty.

Bug reports have a defined shape. The README asks for the full script that produces the error including all import statements, or a pointer to a standard example file, ideally reduced to a minimal example. It also asks for versions of any necessary libraries and the full output trace. Questions of the form "how do I do X" belong on the discussions board, not the issue tracker. If you file a vague issue, you are working against the process the maintainers have described.

There is a second constraint that follows from the dependency list. pandas is pinned at exactly 2.1.3, pymongo at exactly 3.11.3, statsmodels at exactly 0.14.0, PyYAML at exactly 6.0.1, pytz at exactly 2023.3 and psutil at exactly 7.2.1. If you want to bring pysystemtrade into an existing environment with different pins, you will be resolving conflicts. The loose ranges sit on numpy, scipy, matplotlib and scikit-learn, and pyarrow is constrained to >=16,<20. That is a deliberate choice, and it means the project does not slot neatly into an environment that has already made other version decisions.

Finally, this is a futures system. The README's legal section says leveraged trading such as futures trading may result in losing all your money and still owing more, that backtested results are no guarantee of future performance, and that the project owners are not currently registered or authorised by any financial regulator.

Where pysystemtrade sits next to QTPyLib and other Python backtesters

The related searches around this project include QTPyLib and generic "GitHub backtesting Python" queries, which is the right comparison set. The difference is one of scope rather than quality.

A general Python backtesting library takes a price series and a strategy function and returns performance statistics. You bring your own universe, your own position sizing and your own execution assumptions. pysystemtrade instead ships an opinionated framework: instrument configuration, forecast scaling, the optimisation principles from Carver's books, and a broker connection to Interactive Brokers through ib_async. The backtester is one component of a system that also includes sysproduction and syscontrol for live running.

That means the trade-off runs in both directions. You get a head start on the parts of a systematic futures system that are tedious to build and easy to get subtly wrong. You also inherit the framework's assumptions, its dependency pins, and a codebase organised around its author's methodology. If your strategy does not fit the forecast-and-position-sizing model the framework implements, you are fighting the structure rather than using it.

The second real difference is domain. pysystemtrade is a futures system with an Interactive Brokers broker layer. If you trade equities or crypto, or you use a different broker, the sysbrokers layer is not written for you, and the framework's instrument handling assumes the futures contract structure.

Maintenance, licensing and what GPL-3.0 means here

The repository is not archived, and the last push was on 2026-09-21. The README documents the project's own history of stewardship, which is relevant if you are deciding whether to build on it. Rob Carver developed and open sourced the system in December 2015. In 2024 Andy Geach took over as primary maintainer. In January 2026 the project moved to the pst-group GitHub organisation, which the README says is owned by Andy and Rob, with the stated intention that the organisation always has at least two owners so the project continues if one of them loses access or dies.

The release history is less tidy than that governance story. The most recent releases are 1.8.2 and 1.8.1, both dated 2024-11-06, and before that a release tagged "1,31" dated 2022-04-29. The version in pyproject.toml is 1.8.2. So the tagged releases are infrequent, and the develop branch is the default branch rather than main. If you depend on tagged releases, you are depending on something that moves slowly. If you track develop, you are tracking whatever is being worked on.

The licence is GPL-3.0, declared in pyproject.toml as a file reference to LICENSE. This is a copyleft licence, which is a meaningful difference from the permissive licences common in Python tooling. If you plan to distribute software that incorporates this code, the licence terms apply to that distribution. This is not legal advice; read the LICENSE file and, if the answer matters commercially, get proper advice. The README adds its own disclaimer: absolutely no warranty is implied, use at your own risk, and the owners take no responsibility for losses caused by live trading.

Editorial conclusion

Adopt pysystemtrade if you write Python, accept the framework's opinions about how a systematic futures system should be structured, and want a head start rather than a finished product. Do not adopt it if you need vendor support, a point-and-click interface, or a system that trades anything other than futures through Interactive Brokers. Before committing, check the Python version requirement in pyproject.toml against your environment, confirm that the private configuration YAML files you need are present, and read docs/introduction.md and docs/production.md to see how much of the framework you would be taking on.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. pst-group/pysystemtrade on GitHub
4. README
5. Releases