Reproducing a Canonical Time-Series Momentum Baseline
A 252-day trend baseline built twice — in a dedicated backtesting platform and in Python — and reconciled daily.
Research question
Can a canonical 252-trading-day trend-following baseline be implemented independently in two systems and reconciled at daily return level, and where do the remaining differences come from?
Why this matters
Published trend-following specifications leave several choices to the implementer: when the signal is observed, when it is traded, how volatility is measured, whether positions are rounded to contracts, and how roll dates are accounted for. Each is small on its own and each can move a daily return series. Reconciling two implementations turns those hidden choices into documented ones.
Hypotheses
- 01H1: Two independent implementations of the same written specification can be reconciled to a small, explainable daily tolerance.
- 02H2: Residual differences are dominated by execution timing and volatility-estimator definition rather than by signal logic.
- 03H3: Position rounding to whole contracts produces differences that grow as account size falls.
Methodology
Signal construction
A 252-trading-day trend signal is computed identically in both systems, with the observation bar and the execution bar stated explicitly rather than inferred.
Volatility-scaled position sizing
Each market's exposure is scaled to a common risk target using a lagged volatility estimate with a fixed window and annualization convention.
Cross-market aggregation
Market-level returns are aggregated into a portfolio series under a stated weighting rule, with the aggregation step reconciled separately from the market-level step.
Currency conversion
Conversion is applied at the same point in both implementations, since converting before or after risk scaling produces different exposures.
Daily-return reconciliation
The two daily series are differenced, and every break above tolerance is attributed to a component: signal, sizing, timing, rounding, roll, or accounting.
Data
Data source
[DATA SOURCE TO CONFIRM] MetaStock-formatted futures history shared by both implementations so that data differences are eliminated as an explanation.
Validation steps
- Identical input files hashed and version-recorded for both systems
- Contract-level spot checks against exchange references
- Roll-date inventory compared across systems
Licensing restrictions
Input data is licensed and not redistributed. The repository publishes schema, transformation code, and synthetic sample files only.
Key results
No results published yet
Mean absolute daily difference
—
Awaiting final output
Correlation of daily series
—
Awaiting final output
Breaks above tolerance
—
Awaiting final output
Markets fully reconciled
—
Awaiting final output
Planned exhibits
- Daily difference distribution between implementations
- Break attribution by component
- Cumulative series overlay, both implementations
- Tolerance table by market
Every published chart will carry a descriptive title, axis labels, units, legend where needed, its sample period, a gross or net label, a short written interpretation, and accessible colors with tooltips.
Interpretation
What did not match perfectly?
Exact agreement between two implementations is not expected, and the informative part of the project is the catalogue of reasons.
- Execution timing: whether a signal observed at the close is filled at that close or the next open.
- Volatility calculation: window length, sample versus population, annualization factor, and whether the estimate is lagged.
- Rounding: continuous exposure versus whole contracts, and how residual exposure is treated.
- Contract treatment: roll timing, adjustment method, and the return credited on roll dates.
- Portfolio accounting: whether risk is scaled to a fixed target or to trailing realized portfolio volatility, and how cash and financing are handled.
What this does not test
Reconciliation validates accounting and specification precision. It does not provide evidence about whether the strategy has an economic edge.
Robustness checks
- Alternative execution-timing assumptions
- Alternative volatility windows
- Continuous versus rounded position sizing
- Alternative roll conventions
- Subperiod reconciliation stability
Limitations
- A reconciliation can agree precisely and still encode the same shared mistake.
- Licensed input data limits independent third-party replication.
- Platform internals are not fully documented, so some attribution is inferred.
- Results are specific to this universe and specification.
Conclusion
[CONCLUSION TO COMPLETE] Final reconciliation tolerances and the component attribution table will be summarized here once outputs are supplied.
Reproducibility
Repository structure
[REPOSITORY LAYOUT TO CONFIRM] Parallel directories for the Python implementation, the platform scripts, and the reconciliation harness.
Instructions
The reconciliation harness runs both output files through a single comparison script that emits the break report and tolerance table.
Version information
Package versions and platform build are recorded with each reconciliation run.
Downloads and links
Related research
Citation
This is working research, not a peer-reviewed publication. If you refer to it, please cite it as work in progress and note the status shown above.
BibTeX
@misc{bang_tsmom_replication,
author = {Bang, Pratik},
title = {Reproducing a Canonical Time-Series Momentum Baseline},
year = {2026},
note = {Status: Replication. Working research, subject to revision.},
url = {[PROJECT URL TO ADD]}
}Plain text
Bang, P. (2026). Reproducing a Canonical Time-Series Momentum Baseline. Working research (Replication). [PROJECT URL TO ADD]