forex-scalping.com

request.security daily close on a 15 minute chart: when the backtest sees the future

Here is a Pine mistake that makes strategies look much better than they are. You want yesterday's daily close on a 15 minute chart, so you write request.security(syminfo.tickerid, "D", close, lookahead = barmerge.lookahead_on).

With lookahead on, each historical 15 minute bar is given the daily close of the day it belongs to. At 08:00 on a past day, the script already knows where that day finished.

Say price at 08:00 is 1.0874 and the day ends at 1.0912. A rule such as "go long when price is below the daily close" fires at 08:00, and it was right, because the future was in the data. The backtest shows a clean edge. Live, the close of the current day is not known until it arrives, so the same rule sees a moving number and the edge disappears. On the chart nothing looks wrong, because the historical bars just show a line.

The usual fix is to ask for the previous bar's value inside the call: request.security(syminfo.tickerid, "D", close[1], lookahead = barmerge.lookahead_on). The [1] has to be inside the function, as an argument, and not added after it. That returns the last finished daily close on historical and live bars alike.

This is one of the most common Pine mistakes. Using close[1] with lookahead_on, or keeping lookahead off and accepting the delay, avoids it. A quick check for any strategy that uses request.security: if results drop sharply when the higher timeframe value is offset by one bar, the original version was seeing the future.

The same pattern covers other higher timeframe values. A daily high or low has the same flaw: at 08:00 the finished day's high is not yet known, and with lookahead on and no offset the script sees it. Use high[1] and low[1] inside the call for the previous day's range. Weekly values follow the same logic with "W". If you want a developing value, such as today's high so far, use lookahead off and accept that the number will change during the bar, then plan for that in the alert logic. Mixing the two modes on one chart is where things get confusing, so label each variable with what it represents, prevDayClose or dayHighSoFar.

A check that catches it: print the value at a specific historical bar and compare it with what you can read from the daily chart. Pick 08:00 on a past Tuesday and look at the daily bars. The value your script shows at 08:00 on Tuesday should equal Monday's close. If it equals Tuesday's close, you are looking at the future. Do the check at two or three dates, since a script that is right on one date might still be wrong in other conditions, such as around holidays when a day has fewer bars. A five minute check like this is cheaper than finding out after a month of live trading that the live result is nothing like the backtest.

Another sign is the equity curve. A strategy that trades from a leaked value tends to show an unusually smooth line with a win rate that is too good for the idea, for example 85% winners on a simple rule that ought to be near 50%. Treat that as a reason to look for the leak before getting excited. Real edges on a retail chart are usually modest: a 52% win rate at 1:1 is plausible, and 85% is an alarm. If you cannot explain why the win rate would be that high, check every request.security call, and every reference to a value that comes from a bar that had not yet closed.

Alerts bring a final difference. A backtest runs once per bar, but an alert on a live chart can fire intrabar if it is set to once per bar rather than once per bar close. If a condition uses a value that develops during the day, like the day's high so far, the live alert may trigger and then the condition may stop being true by the close, while the backtest recorded only the final state. For a signal that should match the backtest, build it from values that are final when they are used: close[1] from the higher timeframe, and the lower timeframe's confirmed close. That gives the alert and the backtest the same information at the same moment.