Specify trading rules, design tests, account for data and execution limits, and evaluate system performance.
What it teaches
What a backtest establishes and what it only suggests, and how to state an idea as entry, exit, sizing and invalidation rules that are deterministic. The dataset and the clock: gaps, duplicates, stale values and outliers; a point-in-time universe that keeps the delisted names and adjusts splits without hindsight; how trades become bars and which sessions count; and the signal timing that keeps future information out of a past decision. The simulated account: order behaviour and realistic fills, cash, equity, open positions and rejected orders, and commissions, spread, slippage and market impact charged at every entry and exit. Measurement: an auditable trade log, the equity curve and its drawdown; win rate, average win and loss, expectancy, profit factor and sample size; and a benchmark that separates market exposure from independent performance. Doubt, applied on purpose: in-sample, validation and out-of-sample splits, walk-forward windows, and sensitivity, resampling, higher costs and stress tests. Trading System Specification and Backtest Report writes the whole system down and reports it.
Who it is for
Anyone who has produced a beautiful equity curve and cannot say why it should be believed. It assumes you can read a chart, and that risk per trade, R-multiples, expectancy and drawdown already mean something to you — Trading Risk Management defines them. It assumes nothing about walk-forward analysis, Monte Carlo resampling or point-in-time data. It also suits the reader who has never written a backtest and wants to know what the result of one is worth: the honest answer is that a simulation is evidence about a past sequence, that costs and timing decide most of it, and that a curve fitted to the data it was chosen on is not evidence at all.
Concept dependencies
Testable trading rules are what historical data, point-in-time universes, bar construction and signal timing feed. Simulated fills and transaction costs produce the equity curve. Performance metrics require the sample size those metrics describe. The split between in-sample, validation and out-of-sample data makes walk-forward analysis and stress tests more than another look at the same fitted result. Validation distinguishes a search from a test.
Where the definitions come from
The labs are simplified on purpose, so each lesson closes with an official reading link to a primary source rather than to a vendor selling backtesting software: FINRA's investor explainer stating that historical backtesting is hypothetical and does not predict future performance, its guidance on online trading, and FINRA Rule 2210 on communications with the public, which restricts performance projections and misleading performance claims; CME Group for market data and for what a trading simulator is; and the SEC's investor.gov on understanding fees. Those are definitions from a regulator, a self-regulatory organization and the venue — the course's own synthetic examples are illustrations of them, never a substitute.
Every lesson still works with no network at all. Each page is entirely self-contained, and the reference links are the only things on it that point off the site.
Lessons
Explanations, examples, interactive tools, and practice questions.
16 lessons
Educational use only — nothing here is trading advice.
This course defines and validates trading systems. It does not provide
live market data, trading signals, profitability claims, personalized
investment advice, or an execution system. Live data ingestion,
schedulers, broker connections, alerting, deployment, monitoring, and
automated execution belong to Algorithmic and Automated Trading, which is published and linked
below.
Data and results scope. All price paths, trades,
universes, fills, costs, folds, and Monte Carlo paths in these lessons
are deterministic synthetic examples. Historical simulations are
treated throughout as hypothetical evidence, never as predictions. The
course uses stated conventions — signals are separated from order
submission and execution; costs are applied at every entry and exit
rather than deducted once from the final result; time-series splits
remain chronological; out-of-sample and walk-forward results are
reported separately from training results; and robustness testing
means nearby parameters, resampled trade sequences, higher costs, and
the removal of favourable periods. A simulated result is not a
realized result: real outcomes vary by data source, vendor, venue,
asset class, session, liquidity, borrow, capacity, and the execution
you actually get.
Lesson topics
What a backtest is
Before any of the machinery: what a historical simulation actually establishes, and what it only ever suggests. A backtest is a claim about one recorded sequence under a set of assumptions you chose, so these lessons separate the assumptions from the result — and then make the strategy itself precise enough to test at all. An idea that a person has to interpret produces a different backtest every time it is run; rules that are deterministic produce the same decision from the same data, which is the minimum condition for everything that follows.
Convert a market idea into deterministic entry, exit, sizing, and invalidation rules that produce the same decision from the same data.
Open lesson
Not marked
Lesson topics
The data and the clock
Most backtests are wrong before a single rule runs, because of what was in the file and when the strategy was allowed to see it. These lessons cover both halves. First the dataset: the defects that manufacture signals, and the universe question — a list of today's survivors, adjusted with today's knowledge, quietly guarantees a good result. Then the clock: how raw trades become the bars a rule reads, which sessions are eligible, and the timing discipline that keeps a completed bar's close, a later revision, or a statistic computed over the whole file out of a decision made before any of it existed.
Prevent the strategy from using future prices, completed-bar values, revised data, or preprocessing information that was unavailable at decision time.
Open lesson
Not marked
Lesson topics
Simulating the account
A signal is not a trade. These lessons build the machinery between them: an order that only fills at a price the tested sequence could actually have traded, an account that tracks cash, equity, buying power and every open position bar by bar — including the orders it had to reject — and the costs charged on the way in and the way out. Costs are where most promising systems go: commissions, the spread you cross, the slippage you get instead of the price you wanted, and the impact of size the market never offered. They are deducted at every fill here, not subtracted once at the end, because that is the only version that answers what the strategy would have kept.
Deduct commissions, fees, bid-ask spread, slippage, and size-dependent market impact from every simulated entry, exit, and rebalance.
Open lesson
Not marked
Lesson topics
Measuring the result
Now there is something to measure, and the question becomes what to measure it with. The trade log is the primary record — every entry, exit, size and cost, reconstructible into the equity curve, and from that curve the drawdown a real account would have had to sit through. Then the summary statistics, plural and on purpose: win rate says nothing without the average win and the average loss beside it, expectancy and profit factor say nothing without the number of trades behind them. And a return is only impressive relative to something — a benchmark and a cash rate, so that exposure to the market is not mistaken for skill at trading it.
Calculate win rate, average win, average loss, expectancy, profit factor, return, volatility, trade frequency, and sample size without relying on one metric.
Compare the system with an appropriate benchmark and cash rate, then separate market exposure from independent performance and risk taken.
Open lesson
Not marked
Lesson topics
Validation and robustness
A good result on the data you tuned on is not evidence — it is a description of that data. These lessons try to break the system on purpose. First the split: rules developed on one period, parameters chosen on a second, and a final period left sealed until the system is fixed, in chronological order so the future never trains the past. Then walk-forward, which repeats that discipline through time and stitches the unseen windows into a single forward simulation. Then the stress: nearby parameter values, resampled trade sequences, higher costs, favourable periods removed — because a result that only exists at one exact setting on one exact history is a coincidence with a chart attached.
Test nearby parameters, resample trade sequences, increase costs, remove favorable periods, and verify that the result is not dependent on one precise historical path.
Open lesson
Not marked
Trading System Specification and Backtest Report
The specification
A system claim stays an anecdote until it is written down. Trading System Specification and Backtest Report collects the hypothesis, the data and its point-in-time handling, the rules, the execution and cost assumptions, the sizing, the validation plan, the metrics and the limits into one versioned document, states the acceptance criteria the system has to meet before it is taken seriously, and exports the whole specification as a machine-readable file you can keep, diff and hand to someone else.
Combine hypothesis, data, rules, execution, sizing, costs, validation, metrics, limits, and acceptance criteria into a versioned system specification and report.
Open lesson
Not marked
Recommended background
Trading rules, risk budgets, trade records, and performance measures.
Interop
Trading System Specification and Backtest Report exports a system specification
The specification lesson documents a trading system. It turns the whole course into one document — what the system claims, what it was tested on, how it was filled and charged, how it was validated, and what it has to achieve to be accepted — and hands that document back to you as a file, so it can outlive the browser tab it was written in.
Format: trading-system-specification-v1
What comes out of it
Trading System Specification and Backtest Report takes the identity and version you gave the system, the
hypothesis with its market regime and direction, the data section —
universe, timeframe, point-in-time handling, corporate actions,
timezone — the entry, exit and position-sizing rules, the execution
assumptions in basis points for commission, spread and slippage per
side, the validation plan with its in-sample, validation and
out-of-sample percentages, its walk-forward flag and its benchmark,
the acceptance criteria, and the reporting commitments, and exports
the whole specification as a JSON document stamped
trading-system-specification-v1.
The schema linked beside this is the contract for that shape. It is
worth reading if you would rather keep your systems in your own
notebook or repository: match the shape and the same fields carry
over. All nine top-level members are required, so a specification
that omits its validation plan or its acceptance criteria does not
validate — those are the two sections a hopeful backtest leaves out
first. Note what the shape deliberately does NOT contain: a realized
result. The numbers under
acceptance —
minimumTrades,
maximumDrawdownPct,
minimumExpectancyR — are thresholds you
commit to in advance, not performance the system achieved, so a
system that is merely well specified is never mistaken for one that
has been shown to work. Deployment, monitoring and live execution
are Algorithmic and Automated Trading's subject. Everything runs in your browser — nothing is
uploaded, and there is no account anywhere in this course.