Backtest troubleshooting
Why did my backtest produce no trades? A step-by-step diagnostic checklist
A flat equity curve does not explain why a backtest did nothing. “No orders” and “orders submitted but unfilled” require different investigations. For a FiClaw-generated strategy, the useful starting point is the spec and the path from historical observations to executed trades.
Published by FiClaw 产品团队 · Published · Updated
阅读中文版Quick answer
A backtest with no trades can stop at several different stages: no usable data, no eligible instruments, an indicator that is not ready, no triggered signals, no submitted orders or orders that never fill. Count each stage in that order and inspect the first stage that unexpectedly drops to zero. Do not change strategy thresholds until you know whether the result comes from the research rules or an implementation or execution issue.
Key takeaways
- Locate the first missing step in the data-to-fill chain before tuning the strategy.
- Keep signal counts, submitted orders and completed fills separate.
- A correctly implemented strategy may legitimately generate no trades in a given sample.
1. Count the pipeline instead of guessing from the equity curve
Run a short, inspectable diagnostic window while preserving enough preceding history for the chosen lookback. Ask the generated code to report stage counts or inspect equivalent evidence already available in the run. The first unexpected zero usually narrows the investigation more than changing several parameters at once.
| Stage | Count or evidence | If this is unexpectedly zero |
|---|---|---|
| Observations | Usable bars and covered trading dates | Check instruments, dates, fields, frequency and data access errors |
| Eligibility | Instruments remaining after each universe filter | Inspect the first filter that removes every candidate |
| Readiness | Instruments with a complete valid lookback | Check required history, missing values and indicator initialization |
| Signals | Entry or rebalance conditions that evaluate true | Inspect formula, units, threshold direction and schedule |
| Orders | Submitted quantities and order statuses | Check sizing, cash, lot rounding, permission checks and code branches |
| Fills | Executed quantities and unfilled reasons | Check trading constraints, prices and the fill assumptions |
2. Check coverage, lookbacks and signal timing
Confirm that the requested instruments have observations in the test interval. A listed instrument may not cover the full requested history. A long lookback, suspended observations or aggressive missing-value filters can leave no ready signals even when the data request succeeds.
Inspect the actual value of each condition on several dates. Percentage and decimal units, ranking direction, shifted series, calendar alignment and comparisons against missing values can all keep a condition false. Confirm that a scheduled rebalance occurs inside the test window and that the code reaches the decision branch.
- 01Compare requested dates with the first and last usable observations.
- 02Print the remaining candidate count after each filter rather than only the final count.
- 03Check how many observations the indicator needs and when its first valid value appears.
- 04Verify that decision timestamps and execution timestamps match the confirmed spec.
3. Separate a missing order from an unfilled order
If a signal is true but no order is submitted, inspect the sizing calculation and control flow. Target weights can become zero quantities after rounding; a minimum trading lot can exceed available cash; an existing-position check may suppress the intended rebalance. These are different from a signal that never triggers.
If an order exists but never fills, read the order status and execution assumptions. A suspension, a price limit, a limit price that is never reached or another modeled constraint may prevent a fill. Determine which conditions the actual backtest engine represents and record what it does not represent. Do not assume that every real market constraint is modeled automatically.
Diagnostic record for one expected trade Decision date and instrument: [value] Eligible universe and valid input count: [value] Indicator values and each condition result: [value] Target weight, cash and rounded quantity: [value] Order submitted? Order type, time and price: [value] Order status, filled quantity and reported reason: [value] Spec rule being checked: [rule] Conclusion and next isolated check: [value]
4. Rerun one explanation at a time in FiClaw
FiClaw can assist code generation and diagnosis, but the diagnostic question should be narrow: “show where candidates disappear” is more useful than “make the strategy trade.” Preserve the original code and result, add the relevant checks, and change one confirmed error at a time.
After a correction, compare the same stage counts and inspect an actual trade. If every stage behaves as specified and entry conditions simply never occur, zero trades is a valid observation about that sample. Expanding the interval or relaxing a rule creates a new experiment; record the reason and retain independent validation rather than tuning only until trades appear.
The stage counts and diagnostic record above are checks to request or add to the research code; they do not describe a guaranteed built-in FiClaw audit screen or automatic diagnosis for every engine condition. The external order-event and warm-up references provide general methods, not FiClaw's engine, status labels or default fill rules.
Frequently asked questions
Does zero trades mean the backtest engine is broken?
No. It may reflect limited data, a restrictive universe, an incomplete lookback, a condition that never triggers, zero order size or unfilled orders. Trace stage counts and statuses before deciding whether the issue is the engine, the implementation or the intended rules.
Should I lower the entry threshold to fix a zero-trade backtest?
First confirm that data, filters, timing, sizing and orders behave as specified. Lowering a threshold can hide an implementation error. If the original rule is correctly implemented but too restrictive for the research question, document a separate rule change and test it independently.
What should I ask FiClaw to inspect first?
Ask for counts of usable observations, eligible instruments, ready indicators, triggered signals, submitted orders and fills, plus a few representative dates. Then inspect the first unexpected drop and compare it with the confirmed strategy spec.
Method and product references
Related reading
A-share data coverage and conventions →
Check historical coverage, data timing and execution assumptions.
Write a reviewable strategy spec →
Make signal timing, sizing and execution rules explicit before coding.
Reviewing an AI backtest report →
Connect report metrics with the underlying settings and trades.
Turn a research question into a checkable experiment
Start with explicit strategy rules in FiClaw, then review the code, data assumptions and backtest results.