Crude oil has spent the last week behaving like a news ticker rather than a price series. If your algo uses "crude is up" or "crude is down" as a risk filter, this is the week that exposes whether that filter was ever engineered or just assumed.
This post is not a view on where oil goes. It is about something more boring and more useful: how to check whether a macro input is stable enough to be allowed inside a trading rule, and what to do when it is not.
What the last week of crude headlines actually looked like
Pull up the Economic Times crude commodity page on November 5, 2026 and read the news stack in order. The daily headlines ran roughly like this: October 29, crude dips to $113 as diplomatic talks outweigh infrastructure attacks. October 30, crude jumps to $118 as fresh strikes are weighed after the midterms. November 2, crude falls to $111 as Iran–Qatar talks continue. November 3, crude rebounds to $105 as fresh attacks outweigh peace talks. November 4, crude falls below $104 ahead of the US midterm election outcome.
The same page's November 4 report quoted Brent futures at $103.21 and US WTI at $95.42 per barrel. On the MCX side, the near-month crude contract — the one expiring 19 November 2026 — was showing a fall of around 765 points, roughly 8.4%, with a day band near 8,231 to 9,189 and a wider band near 6,926 to 9,972.
Three things jump out, and none of them are directional.
First, the driver alternated between "peace talks progressing" and "fresh attacks" on consecutive days. That is an event process, not a trend. Second, the magnitude is large: a roughly 8.4% single-session move in the rupee contract is bigger than most intraday Nifty ranges you will ever filter on. Third, the headline number and the quoted contract do not match. Headlines in the $104 to $118 band sat next to a Brent print of $103.21 and a WTI print of $95.42.
That third point is where most retail macro filters quietly break.
The first problem: which crude are you reading?
"Crude oil price" is not one number. On any given morning you can source at least four different things, and they do not move together tick for tick:
- Brent near-month futures, in USD per barrel, the global benchmark most Indian commentary references.
- WTI near-month futures, in USD per barrel, structurally lower than Brent and driven partly by US inventory data.
- MCX Crude Oil futures, in INR per barrel, with its own contract expiry (19 November 2026 for the current near-month) and its own Indian trading hours.
- Synthetic OIL/INR quotes from conversion sites, which are a USD oil price multiplied by a live USDINR rate and refreshed on their own schedule.
If your pre-open note reads Brent, your scanner config reads an MCX figure, and your spreadsheet reads an OIL/INR widget, you have three inputs pretending to be one. On a quiet week nobody notices. On a week where the move is 8% in a session, the three can disagree about whether crude is even up or down at the moment you sample them.
Pick one source, write down the exact instrument and currency, and record the timestamp of the sample along with the value. A macro input without a timestamp is not data, it is a memory.
MCX rupee crude already contains the rupee
This one catches a lot of people building "crude plus currency" dashboards.
MCX crude is denominated in rupees. Its price is approximately the dollar oil price multiplied by USDINR. So if you run one filter on MCX crude and a second filter on USDINR, you are not combining two independent macro signals. You are double-weighting the currency leg, and on a day when the rupee moves hard, both filters will fire for the same underlying reason.
If you want two genuinely separate inputs, use a dollar-denominated oil price (Brent or WTI) and USDINR separately. If you want one combined input, use the rupee oil price and stop there. Mixing them means your risk-off state can trigger twice from one event, which usually shows up as unexpectedly low trade counts in live trading compared with your backtest.
The other MCX-specific trap is contract continuity. The near-month rolls on 19 November. If you scrape "the MCX crude price" daily and store it in one column, your series will contain a roll gap that has nothing to do with the oil market. Any percentage-change filter you compute across that date will produce a fake signal. Either store the contract identifier alongside the price, or use a continuous series you know is roll-adjusted.
The second problem: your filter flips faster than your trades
Suppose you settled all of the above and now hold a clean daily Brent series. You still have to answer the harder question: is this input stable enough to gate trades?
A filter that changes state every other day is not a regime filter. It is noise with a confident label on it. Look again at the week above — the narrative flipped between de-escalation and escalation four times in five sessions. Any threshold rule sitting near the current price would have flipped with it.
Three numbers to measure before trusting a macro filter
Before a macro input is allowed anywhere near your risk management layer, measure these on at least a year of history:
Flip rate. Over the lookback, on what share of sessions did the filter's state change? If a "risk-off" filter changes state on more than 20% to 25% of sessions, it is sampling news cycles, not regimes. Count this explicitly; do not eyeball a chart.
State persistence. When the filter enters a state, how many sessions does it typically stay there? If the median run length is one or two sessions and your average holding period is multi-day, the filter will chop your positions for reasons unrelated to your edge.
Lag versus your trade clock. Crude trades across sessions that do not line up with the 09:15 to 15:30 Indian equity window. If you sample at 08:45 IST, you are reading an overnight state that may already be stale by the time your 10:30 entry fires. Write down the sample time and ask whether the information would still have been actionable at the entry time.
A fourth check is worth doing once: how much of the filter's apparent usefulness is just a proxy for volatility you already measure? If your crude filter and an India VIX band filter block roughly the same days, keep the simpler one.
Hysteresis beats thresholds
The practical fix for a flippy input is not a better threshold. It is two thresholds.
A single line — "crude above X means risk-off" — guarantees maximum flipping exactly when price sits near X, which is also exactly when uncertainty is highest. Instead, define entry and exit bands that do not overlap. For example, the state turns risk-off only when the input closes beyond the upper band for two consecutive sessions, and only returns to normal after it closes back inside a lower band for two consecutive sessions. The gap between the bands is the whole point: it costs you a little responsiveness and buys you a lot of state stability.
Two more controls that pair well with this:
- Size scaling instead of on/off. Rather than blocking all trades in a risk-off state, run normal size in the normal state and a reduced fraction in the elevated state. This turns a binary misclassification into a small cost instead of a missed week.
- A hard event veto that bypasses price entirely. Some days you want to stand down regardless of what the filter says.
Event dates are a separate control from price filters
The research week makes this concrete. Traders were watching a US midterm election outcome and an ongoing Middle East diplomatic track. Neither of those is a price level. Both are scheduled or semi-scheduled resolution points where price can gap through your stop.
Keep a plain calendar file in your repo, separate from your indicator logic, listing the dates you will not take new positions or will take reduced size: index expiry dates, the MCX crude expiry on 19 November, major scheduled global events, RBI policy dates, and domestic earnings clusters. The calendar is a veto. It does not negotiate with your signal.
The reason to keep it separate is auditability. When you review a bad month, you want to answer "was it signal quality or event exposure?" without untangling the two inside one function.
How to test this without fooling yourself
Macro filters are unusually easy to overfit, because you are choosing both a threshold and a lookback after already knowing how the year went. Guard against that with structure rather than intuition.
Run your base strategy with no macro filter and record the full set of metrics: trade count, win rate, average win over average loss, maximum drawdown, and the worst single day. Then run the identical strategy with the filter switched on, and compare like for like in your options backtesting workflow.
The honest question is the ratio. If the filter removed 30% of your trades and cut maximum drawdown by 5%, that is a bad trade — you paid a lot of opportunity for very little protection. If it removed 8% of trades and cut the worst-day loss meaningfully, that is worth keeping. Also check what the filter did on your five worst days historically: if it was flat or in the wrong state on most of them, it is not doing the job you built it for.
Then test parameter sensitivity. Shift the threshold by 5% in each direction and shift the lookback by a few sessions. If the results collapse, you fitted the parameters, not a regime. A filter worth keeping degrades gracefully.
Finally, test the plumbing. Deliberately feed your system a stale value, a missing value, and a value from the wrong contract, and confirm the system refuses to trade rather than silently defaulting to "normal". A macro filter that fails open is worse than no filter, because you will believe you are protected.
Where this sits in a daily workflow
The point of all this is to compress a noisy news week into a small number of pre-decided states, so that your morning is mechanical.
In practice that looks like: sample your one chosen crude series and USDINR at a fixed time, log both with timestamps, derive the state using your hysteresis bands, check the event calendar for a veto, and then set today's size multiplier. Only after that do you look at setups.
From there, signal review stays signal review. A scanner should still rank candidates on structure and freshness, and the Action Center's blocked reasons — chase distance, invalidated price, stale structure — remain independent of the macro state. Macro should change how much you risk, not whether you accept a late entry on a broken setup. For options, the chain and margin view is where the size multiplier becomes real: a reduced multiplier should visibly change the basket and the margin estimate before you execute, not after. Treating a weekly market outlook as preparation for these states — rather than as a source of trade calls — is the difference between context and noise.
If you want to build and test these state rules against your own strategies rather than hold them in your head, you can request early access and work through them in a paper-first setup first.
A checklist for a noisy-crude week
- One crude source, one instrument, one currency, written down. Brent, WTI, MCX rupee, and synthetic OIL/INR are not interchangeable.
- Timestamp every macro sample. A value without a sample time cannot be audited.
- Do not run MCX rupee crude and USDINR as two independent filters — the rupee is already inside the MCX price.
- Store the contract identifier with MCX prices so the 19 November roll does not create a fake percentage move.
- Measure flip rate, median state persistence, and sample-to-entry lag before the filter gates anything.
- Use two bands with a gap, plus a consecutive-session confirmation, instead of one threshold.
- Prefer size scaling over a hard on/off block for price-based states.
- Keep event dates in a separate calendar veto: index expiry, MCX crude expiry, policy dates, major global events.
- Compare filtered against unfiltered on trade count, maximum drawdown, and worst single day — and judge the ratio, not the headline return.
- Shift thresholds and lookbacks by a small amount; if results collapse, you fitted noise.
- Test stale, missing, and wrong-contract inputs. The system should fail closed.
An 8% single-session move in a macro input is not a signal to act faster. It is a test of whether the input was ever specified tightly enough to act on at all. Most weeks, the correct response to a crude headline is to confirm your state has not changed and get on with your process.
