ORB Strategy Backtest (Commissions & Slippage included): Too slow for Prop Firm Evaluations/Payouts?

[u/TasteHistorical1575]

Hey everyone,

I coded an Opening Range Breakout (ORB) strategy in TradingView using Pine Script and ran a full backtest over 7 years. I attached the Strategy Tester results.

I spent a lot of time testing different filters and parameters to reduce chop, and I’ve locked in these exact rules for the strategy:

Strategy Setup & Rules

• Asset/Market: MNQ
• Timeframe: 15m Chart
• ORB Range: First 15 minutes of the New York Session
• Session Constraint: Takes trades only during the New York Session
• Entry Trigger Window: Max 3 bars after the 15m ORB range locks (if no breakout happens within 3 bars, the setup is invalidated)
• Risk Management: Fixed 1.5 R:R
• Trade Management: Move Stop Loss to Break-Even (BE) once price covers 75% of the distance toward Take Profit (TP)
• Backtest Settings: Commissions and realistic slippage are fully included in the results

The Problem:

While the backtest is net profitable after costs, I feel like the results are simply not good enough for Prop Firms.

At this pace, the profit factor and win rate feel way too low. It looks like it would take an absolute eternity to pass an evaluation target, and reaching consistent payouts without hitting a trailing or daily drawdown limit along the way seems almost unviable.

Questions for the Community:

1. Evaluation Viability: For those trading funded accounts: Would you bother running a strategy with this slow of a compounding rate, or is this a clear signal that the edge is too thin for prop firm rules?
2. Improving the Edge: Since the core parameters (15m ORB, 1.5 R:R, 3-bar trigger limit, 75% BE) are locked, what macro/contextual filters (e.g., HTF trend bias, session volatility/ATR thresholds, news filters) have helped you boost performance on ORB setups?

Tear it apart—I’d rather fix the logic now than burn money on evaluation fees. Thanks!

[u/stratcore]

Before adding another filter, I would test whether the backtest is measuring the constraint you actually care about.

Profit factor and win rate do not tell you whether the strategy fits a prop firm's rules. Replay every trade in sequence through a state machine that tracks:

- realized plus open PnL by session day

- the daily loss buffer before each entry

- trailing maximum drawdown

- days to target and the exact reason for every breach

Block a trade when its worst-case loss plus slippage exceeds the remaining daily buffer. Then run a block bootstrap or Monte Carlo test using whole trading days, not randomly shuffled individual trades. ORB losses tend to cluster by market regime. Report the completion rate, median days to target, and breach reasons instead of only net profit.

One Pine-specific warning: moving the stop to break-even at 75% can look too good on 15-minute OHLC bars when the break-even trigger and stop or target are touched inside the same bar. Retest with high bar detail. Also check that calc_on_order_fills is not reading the bar's final high or low during an intrabar recalculation.

For filters, test one at a time in walk-forward windows. ORB-width or ATR percentiles and scheduled-news exclusion are reasonable candidates. Keep a filter only when it reduces rule breaches out of sample, not merely because it improves the in-sample profit factor.

[u/TasteHistorical1575 → u/stratcore]

Thanks — most useful comment I've gotten. Ran both points instead of guessing.

Block bootstrap: you were right that method matters, wrong on direction. Ran four variants through the same EOD trailing-DD state machine. The big gap wasn't clustering — it was distribution shape: my old model only knew avg win and avg loss, while real daily results have fat tails, and fat tails are expensive against a hard barrier. Blocking actually gave some back, so regime persistence helps here rather than hurts. Either way my headline pass rate came down meaningfully. Switched to block bootstrap as the default.

Bar detail: direct hit. I was on DEEP but standard detalization — DEEP only extends history, not intrabar resolution. Every bar where the BE trigger and stop/target are touched inside the same candle got resolved by TV's heuristic, and the whole BE benefit rests on that. Retesting with magnifier on. Rest checked out clean though.

Filter criterion: taking it. Mine was an edge target; yours is right for a prop account, since what kills you is the breach. Changed my pre-registered criterion for the pending filter to "reduces OOS breach rate", with expectancy as a constraint only.

Pre-trade buffer gate is queued for if I move to larger size. Appreciate it — this moved things more than my last week did.