How to Backtest in Sierra Chart Without Lookahead Bias

The written companion to the video above: how I backtest from Sierra Chart, why I don't run my research in its replay, the lookahead bug that turned a losing strategy into a winning one, and the free bias check that catches it.

Short answer: backtest from Sierra Chart, not inside it. Sierra Chart stores the tick data on your machine and generates the signals. Python runs the research. Claude Code writes the Python. Sierra's own replay can do an honest backtest in Accurate Trading System Back Test mode, but it's slow, it tests one version at a time, and its faster modes can read the future the moment your strategy looks at a second chart.

Here's why that matters. I rebuilt a bug from my own pipeline on a plain opening range breakout (ORB) and ran it on real tick data since 2020, one contract. With the bug, it made money. Then I fixed one line of code, and the same strategy lost money. The 10-minute candle knew its own close.

I wouldn't say the backtest lied. That's a strong word. It reported exactly what my pipeline fed it, and I never checked the pipeline. This post is how I check it now.

Sierra Chart's replay, the fair version

The obvious move is to open Sierra Chart, find the replay, and run the strategy right there. That's the right instinct, and Sierra can do it properly:

1. Go to Chart → Replay Chart.
2. Set the mode to Accurate Trading System Back Test.
3. Replay All Charts in Chartbook, so every chart moves together.

Run that way, you get every trade: the entry, the exit, the max open profit and the max open loss. If your strategy fits inside it, it's a legitimate backtest.

The catch: the second chart

The catch isn't on the settings screen. It starts the moment your strategy reads a second chart: an ES and NQ confluence, a VIX filter, a higher timeframe, anything. Sierra has three ways to run a backtest, and only one moves the other charts with the strategy:

In the two fast modes, the reference chart doesn't advance with the strategy. It sits fully calculated, with all its history loaded. So a 1-minute strategy can read the finished value of a 10-minute bar that hasn't finished yet. Your entry logic can be correct and still trade on information it couldn't have had.

Why I don't run my research there

The honest mode had two problems for me.

Speed. At 1x it's impossible. In my setup I tested as high as 60x, and the study stopped behaving the way it did live. Even at 60x, two years of data takes over 12 days.

One version at a time. There's no button that runs hundreds of variations of an idea and ranks them, and that research loop is what I needed.

A viewer asked why I research in Python and not in Sierra's own backtester. Part of my edge is in how I manage the trade, and I couldn't build that in replay. I couldn't run my whole book together to see whether one setup took trades away from another. I couldn't sweep, and I couldn't get the data I wanted.

What Sierra Chart is actually good for

What Sierra does give me is a standardized tick data file on my own machine: the intraday .scid files, holding every tick. The $26 a month Base package includes the historical data service, with CME tick history back to 2011 and no separate data fee. It trails by 10 or 15 minutes, so you can't trade live on it, but for research that's fine. (Which package you need if you also trade from the chart.)

So the split on my desk is:

That last row matters. With Claude Code you can have a conversation with your backtest: ask why a number moved and trace it to exactly where it happened. In Sierra, adjusting parameters, you might not fully understand what you're setting up. Claude Code won't make a result trustworthy on its own, but it makes every result something you can question.

For why tick data beats bar data for fills, read the tick-data post. This one picks up where it stops.

Where my pipeline lied

Two mistakes, both in the plumbing, neither in the strategy.

The clock: UTC vs Pacific

A lot of my data is in UTC, and I trade in Pacific time. I was telling Claude Code one set of hours while the data was in another. I went trade by trade trying to find the discrepancy, and spent hours chasing why my prices didn't match and why the open was quieter than normal before I checked the clock.

The 10-minute candle that knew its own close

The second one cost me about another week and a lot of backtest runs. I was using a 10-minute confluence on a 1-minute chart, and the current 10-minute candle always knew its open and its close. So every 1-minute bar inside that 10-minute bar could see the future.

That's the bug I rebuilt on the ORB. With it, the strategy made money in six years out of seven. Once it read the candle that had actually closed, it lost money. The leak was in my indicator. So if a backtest looks incredible and live looks nothing like it, check the pipeline before you change the strategy.

The fix: read the last closed candle

The fix was simple. I lined up every timestamp, and the strategy now reads the last completed 10-minute candle, never the one still forming. Any confluence from another chart gets the same rule.

If you're coming from TradingView, request.security can give you the same higher-timeframe lookahead. A call with lookahead_on is the first thing to look for. (If you built an ORB there first, this post is the TradingView side.)

The free bias check

The bias check is a Claude Code skill you point at your own backtest, and you don't need to be a coder to run it. In order, it:

1. Maps the pipeline from raw data to the equity number, with the file and line for each stage.
2. Checks for lookahead first: signal bar vs next bar, forming vs completed higher-timeframe bars, timestamps, timezones, repainting.
3. Runs probes against your real code instead of only reading it.
4. Reviews the rest: fills, costs, drift, accounting, how many variants you tried, and a buy-and-hold benchmark.
5. Writes a report to _bias_check/REPORT.md, most severe first, both numbers side by side.

It never edits your files. Everything it builds goes in that _bias_check/ folder.

How to run it

Clone optd-starter, open Claude Code inside that repo (that's what registers the skill), and point it at your backtest folder, wherever it lives:

/bias-check path/to/your-backtest

No skills? Paste the one-shot prompt into Claude Code from inside your own backtest folder. The method is in the skill file.

How it catches the 10-minute candle

The first thing the bias check looks for is exactly my bug. It runs your indicator on the full data set, then again with the future cut off. If the answer changes, it was reading the future. That probe is prefix_invariance in backtests/probes.py, and it doesn't need to understand your code to work.

To see it on something harmless first, run the lookahead demo:

python3 backtests/runs/run_lookahead_demo.py

It's a 1-minute strategy with a 10-minute trend filter on random data, so there's no edge to find. Read the 10-minute candle that's still forming and it makes money. Read the closed one and it loses. Same rules, fills and costs; the only difference is one index.

Make "prove me wrong" part of the workflow

The bigger habit: when a backtest looks successful, I ask Claude Code to prove me wrong. I have a prompt that asks it to break my pipeline and my strategies, and it usually finds something.

Once it found a system with a thin edge that broke under slippage, which I hadn't thought to check. So I built a slippage tester: how close the fills would be, how much volume was trading, how fast the tape was moving.

Claude can name all these tests: out-of-sample, walk-forward, slippage. It won't decide to challenge your result unless you make that part of your workflow.

The research loop

My first pass is a raw Python simulator that Claude Code wrote. It loads the tick files and runs the exact rules across every parameter I want to test, and gives me what replay didn't: a day-by-day calendar of every trade, win or loss, with its MFE and MAE (how far it went in my favor, and against me).

Then I go in this order:

1. Base edge. Is there an edge on the entry alone?
2. Exits. Plan the stops and targets from the MFE and MAE.
3. Adds. Only if the entry holds up do I look at adding to the position, because the entry is usually the hardest part to confirm.

A normal batch backtest takes about 5 to 20 minutes on my machine. Bigger data sets take about 45, but I don't run those as often anymore.

Build your own: the 12-requirement prompt

This is the prompt I'd start from, plain text in the repo (backtest_pipeline_starter.md). Fill in your instrument, session, rules, costs and holdout at the top and paste it into Claude Code as one message. The requirements follow the order of this post:

1. Read the .scid files directly, from Sierra's documented layout.
2. Timezone first. Convert UTC to your session's timezone before any session filter, and print a sample day.
3. Build 1-minute bars from the ticks, stamped at the close, keeping whether the high or low printed first so fills can be honest.
4. Contract rolls. Each futures contract is its own file, so roll the week before expiry. Indicators that need one continuous price get adjusted for the gap at the roll; fills always come from the real contract's ticks. Same idea as Sierra's continuous charts.
5. Only read the last completed higher-timeframe bar, for every confluence.
6. Enter at the next bar's open, not the close of the signal bar.
7. Exits walk the ticks in order. If the data can't say whether the stop or target hit first, assume the stop.
8. Costs on every fill, with results shown with and without them.
9. Output a day-by-day trade calendar with MFE and MAE.
10. Keep a trial log, so you always know how many versions you've tried.
11. Hold out data that stays untouched until the rules are frozen, then run it once.
12. Compare against doing nothing: buy-and-hold, sized to the same risk, after costs.

The last line sets up the bias check: once the pipeline runs, audit it and fix what the audit finds. Trading stocks? It's easier. There's no roll, so splits and dividends take its place. No Sierra yet? The prompt file has a line to build against synthetic contracts first.

Tuning vs overfitting

The most powerful thing I built was sweeps: an indicator at 10 settings and the exits at 10 R levels, all at once, ranked.

That can turn into a curve-fitting nightmare fast. But to a degree, you have to fit different instruments differently. NQ and ES have different tick values and different volatility, so when I moved one indicator from NQ to ES, I had to sweep it to tune it to the new instrument. That's calibrating to a real difference. Same with exits: I sweep to see how far a trade travels before it turns, and whether to take a target or ride to the end of the day.

Overfitting starts when you try 100 versions, keep the one that made the most money, and forget the other 99.

The fix has a name: the deflated Sharpe ratio. The more versions you try, the better the best one looks by luck, so it raises the bar for every version tested. Try 50 and keep the winner, and it has to beat what the luckiest of 50 coin flips would have scored.

In practice:

• Log every trial.
• Freeze the rule.
• Test it once on history the sweep never saw. Once you peek and retune, it isn't holdout data anymore.
• Check the neighbors. A result that works at one setting and dies at the next is a coincidence.

Would doing nothing have beaten it?

The last check is the boring one. If you can't beat putting your money into the S&P 500, there's no point putting time, energy and extra risk into a system.

Compare on the same risk: did it beat buy-and-hold after costs, with a similar drawdown? This kills a lot of mediocre strategies. A few extra percent over the market with a lot more drawdown and work isn't worth chasing. I want a strategy that does something when the market goes down too, to hedge or to make money. (Five popular strategies went through this test, and the survivor turned out to be a long position with extra steps.)

For the ORB in this post, the answer was no. At the same drawdown, buy-and-hold beat the fixed strategy easily. Even the version with the bug, the one reading the future, didn't beat buy-and-hold at its own risk.

The process, in order

1. Validate the plumbing. Clock, bars, higher-timeframe reads, fills. Run the bias check.
2. Find the base edge on the entry alone.
3. Design the exits from the MFE and MAE.
4. Sweep, and count every trial.
5. Test once on data you haven't touched.
6. Compare against doing nothing, at the same risk, after costs.
7. Only then wire it into a signal on the chart. That's a different build, with its own safety rules, and it starts in sim.

FAQ

Can Sierra Chart backtest a trading strategy? Yes. Use Chart → Replay Chart in Accurate Trading System Back Test mode, and replay All Charts in Chartbook if your strategy reads more than one chart. It's accurate but slow, and it tests one version at a time.

Why does my Sierra Chart backtest look better than live? Check the pipeline before the strategy. If it reads a second chart, the bar-based and automatic replay modes can let it read a bar that hasn't closed yet. Timezone mismatches and signal-bar entries do similar damage.

What is lookahead bias in a backtest? The backtest uses information that didn't exist yet at the moment of the trade. The common version: a 1-minute strategy reading the close of the 10-minute candle it's still inside.

---

Get the starter. The bias check, the 12-requirement pipeline prompt, the ORB signal study from the earlier videos, and the lookahead demo on random data are all in one free download: onepersontradedesk.com/get/backtest. It's a starting point for you to adapt to your own setup, and it doesn't include any of my setups. Method free, no signals, no live P&L.

Which part of your backtest do you trust the least right now? Tell me the step in the video comments. That's where the next one comes from.