Bar-close backtesting tells you what a strategy decided after a candle finished. Intrabar backtesting asks what happened inside that candle, where an entry, stop, target, spread and floating loss may have been touched. For a prop trader, that distinction can separate a trade that closes green from an account path that survives.
Neither label is a guarantee. A strategy that truly waits for a closed bar can be tested on close; an intrabar test can still mislead if it leaves the data source, bid/ask prices, spread and event order vague. The thesis is simple: bar-close and intrabar answer different questions, and a credible prop backtest must not pretend one answers the other.
Start with the question, not the setting
Bar-close describes when the signal is evaluated. Intrabar describes how much of the price path the test observes. They are related, but they are not the same setting.
| Test language | What it usually means | Question it can answer |
|---|---|---|
| Bar-close | The rule reads a completed candle before acting | What happens when the strategy only makes decisions from closed-bar information? |
| Intrabar | The engine processes finer observations inside a larger candle | What happens when an entry, stop, target or spread changes before that candle closes? |
cTrader's bar-events guide distinguishes OnBar() from OnBarClosed(). OnBarClosed() works with the last completed bar, but the event is triggered when a new tick forms the next bar. That matters because a close-confirmed signal is not automatically a fill at the exact closing price.
A close-confirmed signal can still need intrabar execution
Signal timeframe and execution resolution can be separate. A strategy may read an H1 bar only after it closes, then manage an open position with M1 or tick observations. That is a hybrid design, not a contradiction.
The mistake is to let the report blur the boundary. If the signal is close-confirmed but the stop and target are evaluated only at the next close, say so. If the signal waits for the close but the position is managed inside the bar, document that path instead. The reader needs to know when the decision happened and how the order was later exposed to price.
What an OHLC bar hides
An OHLC bar records open, high, low and close. It does not, by itself, record the order in which prices visited those points. That missing order becomes material when more than one event could have happened inside the same candle.
| Hidden detail | Shortcut that flatters the result | What to declare instead |
|---|---|---|
| Stop versus target | Assume the favourable level was touched first | Use finer data or state an explicit tie-breaking rule |
| Trigger versus fill | Treat the close or boundary as the executed price | Separate the signal price from the order price and time |
| Bid versus ask | Use one price for entries and exits on both sides | State which quote triggers and which quote fills |
| Gaps through a level | Fill exactly at a price the market skipped | Define gap handling and the resulting slippage |
| Floating exposure | Look only at closed-trade profit | Record equity while the position is open |
If a bar reaches both a stop and a target, OHLC values alone do not establish which was reached first. Choosing the favourable order is a modelling assumption, not a discovery about the market. A report that hides that assumption has turned missing information into apparent edge.
This is why intrabar does not simply mean “more detail, therefore truth.” M1 data narrows the unknown path; tick data can narrow it further. Neither removes the need to define spread, slippage, quote side and what happens when the available data still cannot establish event order.
Why prop rules make the path non-negotiable
A prop evaluation can care about the account's floating equity, not only the profit of trades after they close. A position can finish positive after spending time below a loss threshold. The final candle and the final trade result can therefore hide the event that mattered to the account.
The exact rule definitions belong to each prop firm and can change. Keep the current firm documentation beside the test. The funding model is useful for keeping daily loss, overall drawdown, overlapping positions and the account path in the same conversation as the strategy result.
Before trusting a prop backtest, write down:
- when the daily loss calculation resets;
- whether floating equity is checked continuously or at a declared observation point;
- how simultaneous positions contribute to the account path;
- how gaps and stop fills are recorded;
- whether the strategy can open another position while the first is still exposed.
The point is not to assume the most restrictive rule or to imitate a firm's current page from memory. The point is to make the account test explicit, then verify the live rule against the firm's own source.
Build a reproducible cTrader comparison
cTrader's backtesting documentation lists server tick data, server M1 bars, local M1 CSV data and H1 bars as available data choices, along with fixed or variable spread settings. The source and the execution model are part of the result, so record them with the report.
Use a comparison that changes one layer at a time:
| Layer | Write it before the run | Compare |
|---|---|---|
| Signal | OnBar() or OnBarClosed(), trigger price and confirmation rule | Does the signal arrive at the intended moment? |
| Data | Tick, M1 or higher-timeframe source, server and timezone | Does the observed path match the question? |
| Execution | Market or pending order, spread, slippage, commission and swap | Is the fill model the one the account will face? |
| Ambiguity | Stop/target order, gaps and unavailable ticks | Is uncertainty shown instead of awarded to the strategy? |
| Account | Floating equity, loss clocks, overlap and drawdown basis | Does the path stay inside the applicable constraints? |
Run the bar-close and intrabar versions with the same rules, costs and date range before changing the strategy. If the result changes, the difference is evidence about signal timing or path assumptions. It is not a reason to keep whichever curve looks nicer.
The cTrader backtest verification checklist is a useful companion because it treats data, logic, costs and drawdown as one reproducibility problem.
What the published method lets you check
realbacktesting is a trading-software studio for cTrader built around results a trader can inspect. Its published FTMO-line method uses cTrader broker M1 bars from the server in 2021-2026, intrabar M1 execution, 1 bps slippage, a fixed spread of 2 pips, commission charged in the run, swap applied and additive percentage-risk sizing on an 80,000 EUR model base. The drawdown ceiling is the worst floating-equity low that FTMO's drawdown rule measures, taken from the 5-year cTrader-native backtest and confirmed on a 30% out-of-sample hold-out.
Those are test conditions, not a live-performance promise. They make the assumptions inspectable and give a reader a basis for rerunning the result in their own cTrader. The methodology page explains the validation chain; broker data, execution and the firm's current rules still need to be checked for the account being evaluated.
That distinction is the useful standard for any cTrader backtest. It is better to publish a smaller claim with a visible path than a polished return whose candle sequence nobody can reconstruct.
Frequently asked
Is bar-close backtesting wrong?
No. It is appropriate when the strategy genuinely makes decisions from completed bars and the report says when the order is filled. It is incomplete when intrabar stops, targets or account limits are treated as if they did not exist.
Is tick data always better than M1 data?
Finer observations can reveal more of the event sequence, but they do not automatically match live execution. cTrader describes tick data from the server as its most accurate historical data source in its backtesting documentation; the feed, spread, quote side and order rules still determine what the test means.
Can a strategy use a higher-timeframe signal and intrabar exits?
Yes. That is a valid hybrid when the signal clock and the execution resolution are declared separately. The test must not report it as a close-only result if stops and targets were evaluated inside the bar.
Why can a trade close positive while a prop account fails?
Because the account may have crossed a loss threshold while the trade was open. A closed-trade summary does not replace the firm's current definition of daily loss, overall drawdown or floating equity.
The stubborn takeaway
Bar-close is a timestamp for a decision. Intrabar is the path that decides whether the order, stop, target and account limit were touched. Trust a backtest only when it states both and treats anything an OHLC bar cannot reveal as uncertainty, not free profit.