Systematic (rule-based) strategy
A systematic strategy is a trading procedure fully specified by written rules, so that the same inputs always produce the same decision about entry, exit, size and abstention, whether the rules are executed by a person or by a program.
Senzoukria · Glossary · Updated September 2026
Systematic is about the rules, not the computer
The defining property is determinism. Given the same closed bars, the same session filter and the same account state, a systematic strategy reaches the same decision every time. A trader can apply such rules by hand; a script can apply them automatically. What is excluded is discretion in the moment: a rule that says "enter if the delta looks convincing" is not systematic, because two readings of the same bar can disagree.
This is why the beginner's guide to quantitative trading says quant trading can be manual or automated. Automation is a later step that makes repetition cheaper and mistakes rarer; it does not make an ambiguous rule precise.
Anatomy of a rule set
| Component | Question it answers |
|---|---|
| Universe and session | Which instrument, which hours, which bar construction |
| Signal | Which computed condition, with lookback and threshold, evaluated on closed bars |
| Entry timing | At which price and when, for example the next bar's open |
| Exit | Stop, target, time stop, and the policy when both are touched within one bar |
| Position size | How many contracts, from what risk budget |
| Abstention | When not to trade: session cutoff, one position at a time, regime filter |
Systematic versus discretionary orderflow
- Discretionary orderflow reading uses the footprint, the DOM and the heatmap to form a judgement bar by bar. It can be skilled and consistent without being systematic.
- A systematic version of the same idea has to reduce the judgement to fields the data contains: executed bid and ask volume per level, delta, imbalances with a stated ratio, closed-bar prices.
- Some observations do not survive the translation. Queue position, hidden reserve and a participant's intent are not fields in the data and cannot be part of a rule.
In Senzoukria
Strategies are written in the Scripts editor in TypeScript, Python or C++ and receive the footprint data, bid, ask and delta per level, as input. The editor ships templates such as Breakout strategy, which buys a break of the N-bar high with a fixed stop and target on the simulated account only, and Mean reversion under regime (HMM + Hurst) in Python. A strategy drives the simulated account, the replay, or, once armed by typing the arming word in the Autopilot panel on a compatible Rithmic account, the optional autopilot with its Max contracts and Max daily loss limits. The guided tour states the sequence plainly: backtest on your bars, then run on a simulated account; live execution needs the autopilot armed by hand.
Common mistakes
- Calling a rule systematic while leaving the exit or the size to judgement.
- Overriding the rule mid-session and then evaluating the strategy as if it had been followed.
- Assuming a systematic rule is validated because it is coded; the code only makes it testable.
- Confusing a strategy that runs in the simulated account with permission to run it on a funded one.
Related
This page in other languages
Frequently asked questions
- Can a systematic strategy use orderflow inputs like delta and imbalances?
- Yes, provided the inputs are defined in the data. Delta per level is ask volume minus bid volume; a diagonal imbalance compares ask volume at one level with bid volume one tick below at a stated ratio. Both are computable from executed trades with side classification, so a rule can use them. Depth-based conditions need book history, which trades alone do not contain.
- Is a systematic strategy the same as an automated one?
- No. Systematic describes the rules; automated describes who executes them. A person can follow a systematic rule set by hand, and a program can execute a badly specified rule with undefined behaviour. In the desktop, automation of a rule on a live account requires a separate, explicit arming step and its own limits.
- Why must signals be evaluated on closed bars?
- Because a forming bar changes until it closes, and a rule that reads it mid-bar sees values the historical test never saw. Evaluating on the closed bar and entering at the next open keeps the live behaviour consistent with the backtest, which is the execution model the desktop's historical tests use.