Running an algo live is not a hands-off activity. There are moments when manual intervention is the right call. The problem is that most traders cannot tell the difference between a legitimate override and an emotional one — and making the wrong call in either direction costs money.
This post is about one thing: knowing in advance exactly when you are allowed to touch a running strategy, and what you do when that moment arrives.
Why Override Rules Have to Come Before Going Live
The worst time to decide your override policy is mid-session when a strategy is down ₹8,000 and you are watching it tick lower.
That is not decision-making. That is panic.
Override rules work the same way stop-losses work: they have to be set in cold blood, before the trade, based on logic. If you have not written down your override conditions before your algo goes live, you do not have a policy — you have a reflex.
The live monitoring checklist covers what to watch during a session. This post covers the harder question: what do you actually do when something looks wrong?
Two Kinds of Override: Legitimate and Emotional
Before you even list the triggers, separate these two categories clearly.
Legitimate overrides are about the system, not the P&L. Something is broken, unexpected, or outside what the strategy was designed to handle. The algo is operating correctly but the environment has changed in a way that invalidates its assumptions.
Emotional overrides are about the P&L. "It's down a lot today." "I have a bad feeling about this market." "I would not have taken this trade manually." None of these are valid reasons to touch a running strategy.
The hard truth: most mid-session interventions by retail traders are emotional overrides disguised as rational ones. You will find a system-level reason after the fact. But the real trigger was the number on the screen.
Rule 1 — Pre-Define Your Legitimate Override Triggers
Write a short list. These are the only conditions that allow you to pause or stop the algo during the session.
Typical legitimate triggers:
- Data feed confirmed dead. Not slow — dead. Your platform's LTP has not updated in over two minutes, and NSE's official site shows different prices. An algo trading on stale data can fire entries or exits that have nothing to do with market reality.
- Broker API rejection rate spikes. More than three consecutive rejections in five minutes for reasons beyond margin (such as: API error, gateway timeout, session expired). Your execution layer is broken, not your strategy.
- Exchange halt or circuit. A 10% or 15% market-wide circuit freeze means the strategy was never backtested in this regime. Pause, wait for the reopening, then decide.
- Margin is actually at risk. Not "P&L is negative." Your available margin in the broker terminal has dropped to a level where the next entry could trigger a margin call. This is different from a normal drawdown.
- A critical strategy bug is confirmed. You see the algo firing entries you explicitly ruled out — the wrong instrument, wrong direction, or wrong lot size. This is a code issue, not a market call.
Everything else — the market is volatile today, BANKNIFTY is trending against you, global news is bad — does not make this list.
Rule 2 — Never Adjust Position Sizing Mid-Trade
This rule gets broken constantly, always for understandable reasons.
The trade is going your way, so you want to add more. The trade is going against you, so you want to reduce it a bit. Both feel logical in the moment. Both are overrides that corrupt your edge.
Your backtesting calculated an expected value based on specific entry, exit, and sizing rules. The moment you change sizing mid-trade, the live result is no longer drawn from the same distribution as your test. You have created a hybrid system with unknown properties.
More concretely: if your strategy was backtested at 1 lot and you add a second lot because "this one feels strong," you are not running a 2-lot strategy. You are running an unverified gut call with a slightly lower entry cost.
The position size goes in before the trade. It does not change unless you are changing the strategy for all future trades, not just this one.
Rule 3 — The Kill Switch Requires a Pre-Set Trigger
A kill switch — flatten all positions, disable new entries — is the most powerful tool in live algo trading. It should also have the clearest trigger condition.
If you are running the kill switch on feel, it is not a kill switch. It is a panic button.
Define it before you deploy:
- Daily loss cap in rupees, pre-set at broker and platform level. When that number is hit, automation stops. This should trigger automatically, not wait for your attention.
- Manual kill reserved for confirmed system failure only (see Rule 1 triggers).
The kill switch test is also non-negotiable: before any real capital, use paper trading to confirm the kill switch actually flattens positions and blocks entries. Many traders discover on a real day that their kill switch only stops new entries — it does not close existing positions because that logic was never tested.
Anadi Algo's risk management setup lets you configure daily loss limits, position caps, and kill-switch behavior before you deploy a single rupee live.
Rule 4 — Log Every Override You Make
Every time you touch the algo outside of a pre-defined trigger, log it. Minimum entry:
- Time and session. When exactly did you intervene?
- Reason. What was the stated reason? Be honest — "I was nervous about the FOMC tone" is a real entry.
- What the algo would have done. After the session, come back and check what the trade would have produced without your intervention.
After 20 logged overrides, review the log. The pattern is almost always the same for retail traders: emotional overrides tend to reduce winning trades more than they reduce losing ones. Because losing trades are already running toward their stop-loss — the algo would have exited anyway. Winning trades are the ones where humans tend to exit early.
If your override log shows your manual interventions cost you money, that data will do more to improve your discipline than any framework.
Rule 5 — First Session Means Observer Mode
For any new strategy going live for the first time, the first one to three sessions are observation runs, not full deployment.
Even if paper trading looked clean, the live session will surface things that paper trading did not — fill latency, actual slippage on illiquid strikes, real margin behavior. In this window, the valid override is to watch and document, not to adjust on the fly.
If something looks wrong in the first session, the response is to pause, identify the exact cause, fix it in the strategy, and retest — not to manually adjust the live run to compensate.
Pause vs. Reduce vs. Full Stop
Not every intervention is a kill switch. There is a spectrum.
Pause new entries. Valid when you need to investigate something without closing existing positions. A feed issue, an unexpected order state, a news event that just hit. Set a timer — 15 minutes, not the rest of the day.
Reduce exposure. Valid only if you are changing the strategy permanently, not just for today. If slippage on large lot sizes is worse than modeled, reducing lots is a strategy update that applies going forward. If you are reducing because you are nervous about this particular session, it is an emotional override.
Full stop and flatten. Valid for confirmed system failures and when your daily loss cap is hit. Not valid as a substitute for good risk configuration before deployment.
When You Find Yourself Justifying an Override
Here is a quick diagnostic. Before you touch anything, ask yourself: is the reason I am about to intervene something I could have written into the strategy rules before going live?
If yes — it should have been a rule, not a manual action. Document it, pause the strategy if needed, and encode it properly before the next session.
If no — you are about to make an emotional override dressed up as a system call.
The traders who scale algo strategies are not the ones who never intervene. They are the ones who have a pre-written, short, specific list of conditions under which they intervene — and who leave everything else to the algo.
If you are building that workflow and want guardrails that enforce it at the execution layer, you can try early access and walk through your setup with the team.
Override Rules Checklist
Keep this somewhere visible next to your trading setup:
- Override triggers are written down before the session starts
- Data feed failure confirmed against a second source before touching anything
- Broker API errors — three consecutive failures, documented reason, before pausing
- Position sizing does not change mid-trade — ever
- Kill switch trigger is a number or a system event, not a feeling
- Kill switch tested in paper mode before live deployment
- Every manual override logged with time, reason, and post-session outcome
- First 1–3 sessions on a new strategy: observe, do not adjust
- "Pause entries" and "full stop" are different responses to different problems
- If you are justifying an override in real-time, you probably should not make it
The override policy is part of the strategy. Write it before you go live.
