Algo Trading Risk Controls: Caps, Guards, Kill Switch

Algo trading risk controls are the checks that run before every order and can't be skipped: position caps, a per-bar guard on order count and size, a kill switch that stops new risk while market data keeps flowing, and several independent gates in front of live orders. They should run identically in backtest, paper, and live trading.

TL;DR: Build five controls before going live: position caps tracked from fills, a per-bar guard against order loops, a kill switch that halts new risk but keeps data flowing, independent live gates, and sanity checks on prices. Run them in backtest and paper too. SEBI's retail algo framework applies to all brokers from April 1, 2026.

We built these controls into a private options trading platform for a confidential client trading index options on an Indian exchange. Client, broker, and strategy details are withheld. This post doesn't tour the platform. It goes deep on each control: what it stops, how to design it, and the mistakes that make it fail on the day you need it.

Why do trading systems need risk controls at all?

Because a working strategy in the wrong state can do more damage in minutes than a bad strategy does in a month. Risk controls exist for the states nobody planned: a loop, a stale price, a missed fill, a test config in live. Each control turns one of those into a blocked order and a log line.

The best-known public example is Knight Capital. In August 2012, during the first 45 minutes after the open, a router that had been incorrectly deployed with new code sent more than 4 million orders while trying to fill 212 customer orders, and losses topped $460 million (SEC press release). The strategy wasn't the problem. The deployment was, and nothing stopped it fast enough.

Here are the failure modes we design against:

1. A bug sends the same order on every tick instead of once.
2. A stale or zero price produces signals that make no sense.
3. A reconnect replays old ticks and the strategy trades on them.
4. A position is larger than the system thinks, because a fill was missed.
5. A test configuration reaches the live environment.

The five controls at a glance

Control	What it stops	Where it sits
Position caps	Positions growing past a set size	Per instrument and in total
Per-bar guard	Too many orders or too much size in one bar	Between strategy and order router
Kill switch	All new risk, at once	Reachable by an operator and by other controls
Independent live gates	An order reaching the broker when any gate says no	In front of the broker adapter
Data sanity checks	Trading on stale, zero, or wild prices	Before the strategy sees the tick

On the platform, the first four are built in: position caps, a per-bar guard, a kill switch that stops new risk without dropping the data stream, and live orders behind several independent gates. Data checks belong in the same list, so we include them here as a recommendation.

How should position caps be checked?

Check a cap against the position you would hold if the order filled in full, not the position you hold now. Track that position from fills reported by the broker, not from orders you sent, because orders get rejected, partly filled, or cancelled. A cap that counts sent orders drifts away from reality within a day.

Set caps at two levels: per instrument, and in total across the book. With options, many strikes and expiries can add up to one directional bet, so define "total" before picking a number.

Then reconcile. If the system's view of the position and the broker's view disagree, stop opening new risk until they agree. Isn't it safer to trade on and fix it later? No. A mismatch means one of your inputs is wrong, and every cap built on that input is wrong too.

One related detail from the platform: instrument identity is read from a snapshot map, never derived from strings. A cap applied to the wrong instrument is no cap at all.

What does a per-bar guard catch?

A per-bar guard limits how many orders, and how much quantity, a strategy can send within one bar. It's the control that catches the classic bug: a signal that should fire once per bar firing on every tick. It also limits a strategy that's technically correct but reacting to noise.

Pick limits generous enough for normal behaviour and tight enough to stop a loop within seconds. A useful way to choose them is to run the strategy through backtests and paper sessions, record how many orders it sends per bar at its busiest, and set the guard a comfortable margin above that.

Log every block with the strategy, instrument, bar, and reason. In our experience, a guard that fires often isn't being too strict. It's reporting a bug in the strategy or in the data feeding it, and the log is the fastest way to find which.

What should a kill switch stop, and what should it keep running?

A kill switch should stop all new risk at once: no new orders, and working orders cancelled. It should not stop market data. On the platform, the kill switch stops new risk without dropping the data stream, because the moment you hit it is the moment you most need to see the positions you still hold.

Two more design rules matter:

1. One action to reach it. An operator engages it from the control dashboard in one step, and other controls can trip it automatically when something goes badly wrong.
2. A written answer to "and then what?" Decide in advance what happens to open positions: hold them, or flatten them under a person's control. Don't let the kill switch improvise.

SEBI's own definition is a useful benchmark. Its February 2025 circular describes the kill switch as "the last level of defence against any Algorithm malfunction" and expects it to trigger a halt automatically on pre-defined conditions (SEBI circular, 4 February 2025). Test yours in paper trading on a schedule, not only once.

Why put several independent gates in front of live orders?

Because one check is one point of failure. The platform puts live orders behind several independent gates, so a single bug or a single wrong setting can't send a real order by itself. If every gate calls the same function, you have one gate with several names.

Typical gates we'd recommend, each checked by different code where possible:

1. The environment is explicitly marked live, never live by default.
2. The strategy is enabled for live by a separate setting from the environment flag.
3. The order passes position caps and the per-bar guard.
4. The kill switch isn't engaged.
5. The order's size and price sit inside sanity bounds for that instrument.

Gates one and two catch the test config in live. One stray setting can flip one flag, not two.

Should backtest, paper, and live run the same checks?

Yes. Risk controls tested only in live are tested in production. The platform runs one system for research, paper trading, and execution, with the same code path in each, so strategy code and risk checks don't change between paper and live. A backtest then exercises the same caps and guards a live session will.

The payoff: a paper run shows how often each control would have fired before real money is involved. Research runs on a Parquet tick archive queried with DuckDB and Polars, so you can replay a bad day and watch the controls respond.

Keep risk checks fast enough that nobody skips them

Speed is a safety feature here: a slow check invites a bypass. On the platform, the risk check runs at 21 µs at p50, measured in tape replay. That's quick enough that it's never the reason an order is late, which removes the most common argument for a bypass.

We cover how those numbers were measured, stage by stage, in how we measure trading latency. The rule for risk is simple: measure the check like any other stage, and if it gets slow, make it faster rather than optional.

The same thinking applies to the dashboard where the kill switch lives. It must never slow trading. On the platform, market state reaches the dashboard through Redis and a WebSocket gateway throttled per instrument, and the publisher drops rather than blocks when full. If the gateway dies, trading doesn't notice, and the kill switch path stays separate from the display path.

What do SEBI's algo trading rules require?

SEBI's February 2025 circular makes the broker the principal for algo orders placed through its APIs, requires every such order to carry a unique identifier from the exchange, and requires self-built algos to be registered through the broker once they cross an order-per-second threshold. Exchanges keep the ability to use a kill switch on orders from a particular algo ID (SEBI).

The timeline moved more than once. A September 2025 circular says that from April 1, 2026, the framework, with the exchanges' implementation standards, applies to all stock brokers (SEBI circular, 30 September 2025). How it applies to you depends on who you are and how you reach the market, so work it through with your broker and advisers.

US readers have a parallel: SEC Rule 15c3-5 requires brokers with market access to have controls that block orders exceeding pre-set credit or capital thresholds, or that appear erroneous (SEC). Engineering controls support compliance. They don't replace it. Our fintech page covers how we work with clients on this.

A checklist before going live

1. Are caps enforced on position from fills, per instrument and in total?
2. Does the per-bar guard stop an order loop within seconds?
3. Does the kill switch keep market data flowing, and was it tested this month?
4. Are the live gates independent, in different code?
5. Do backtest, paper, and live run the same checks?
6. Does a position mismatch with the broker stop new risk?

FAQ

What should trip a kill switch automatically?

Conditions you can state in advance: a position mismatch with the broker that doesn't clear, the per-bar guard firing repeatedly for one strategy, a loss limit for the day, or market data going stale. Keep the list short and written down, so an operator knows exactly why trading stopped when it does.

Where should position limits be enforced, strategy or engine?

In the engine, between the strategy and the order router. If each strategy enforces its own caps, a bug in one strategy can skip them. A single risk layer that every order passes through, in backtest, paper, and live, gives you one place to test and one place to trust.

Do risk checks slow down order execution?

They don't have to. On the options trading platform we built, the risk check runs at 21 µs at p50, measured in tape replay. Treat the check as a measured stage like decoding or routing, and optimise it when it slows, rather than letting anyone argue for turning it off.

Does SEBI's algo framework apply to a private trading setup?

It depends on how orders reach the exchange. The February 2025 circular covers algo orders flowing through broker APIs and self-built algos above an order-per-second threshold, and applies to all brokers from April 1, 2026. Ask your broker how it classifies your orders before you go live.

Building an algo trading system, or adding risk controls to one you already run? See our algo trading software work, read the anonymised options trading platform case study, or look at our trading platform development page to plan the engine around these controls.