Order Types and Execution Tactics in Indian Markets

A strategy produces a decision: buy this instrument, this quantity, now. Everything between that decision and a fill is execution, and it is where a measurable share of retail edge is lost. The choice of order type is the largest single lever in that gap, and it is usually made once, early, and never revisited.

The order types you actually have

Every broker API in India exposes broadly the same four order types, because they map onto exchange order attributes rather than broker features. The names are consistent; the edge-case behaviour is not.

The row that deserves attention is SL. A stop-loss limit order that triggers during a fast move can end up resting unfilled below the market, which means you have a working order and an open position rather than the protection you intended. That is the failure mode that turns a planned small loss into an unbounded one.

Market or limit: the actual trade-off

The textbook framing is that market orders cost you the spread and limit orders do not. That is incomplete. A limit order that does not fill has a cost too — the cost of not having the position the strategy asked for — and that cost is invisible in your fill records, which is why it is systematically underestimated.

The correct way to frame it is by asking what your strategy loses when it misses a trade. A mean-reversion strategy entering into weakness is often fine with a resting limit order; if it does not fill, the opportunity was probably not there. A breakout strategy is the opposite: the trades it fails to enter are disproportionately the ones that worked, so a limit order introduces a bias that no amount of saved spread compensates for.

How a stop-loss order actually behaves

A stop order is two events separated in time, and treating it as one is the source of most confusion about why a stop "did not work". The trigger is evaluated by the exchange against the last traded price; only when it fires does an actual order enter the book.

Between those two events, the market can move. With SL-M the resulting market order will fill somewhere, possibly well past your trigger. With SL the resulting limit order may not fill at all. Neither behaviour is a malfunction; both are what you asked for.

SL_M_SUPPORTED = {"NFO": False, "NSE": True}  # verify per broker and segment # How far through the trigger to price a protective limit, as a fraction.# Wide enough to fill in a fast market, tight enough to bound the loss.STOP_LIMIT_SLACK = 0.004  def build_stop(exchange: str, side: str, trigger: float, quantity: int) -> dict:    """Prefer SL-M for certainty of exit; fall back to a slack-priced SL."""    if SL_M_SUPPORTED.get(exchange, False):        return {            "order_type": "SL-M",            "trigger_price": round(trigger, 2),            "quantity": quantity,            "side": side,        }     # SL-M unavailable: price the limit through the trigger so it still fills    # in a fast market, and accept a bounded amount of extra slippage.    slack = trigger * STOP_LIMIT_SLACK    limit = trigger - slack if side == "SELL" else trigger + slack    return {        "order_type": "SL",        "trigger_price": round(trigger, 2),        "price": round(limit, 2),        "quantity": quantity,        "side": side,    }  def on_stop_triggered_but_unfilled(order, book, seconds_waiting: int) -> dict | None:    """A triggered SL resting unfilled is an open position with no protection."""    if seconds_waiting < 3:        return None    # Escalate: cancel the resting limit and exit at market.    return {"action": "replace_with_market", "cancel": order.id, "reason": "stop unfilled"}

The escalation function is the part worth copying. A triggered stop-limit that has not filled within a few seconds is a position with no protection, and the only safe response is to stop being clever about price. Systems that lack this path are the ones where a small planned loss becomes the day's largest.

Freeze quantity and order slicing

Exchanges publish a freeze quantity for each derivatives contract — the maximum quantity permitted on a single order. Submit more and the order is rejected outright, not partially accepted. Any system that sizes positions dynamically will eventually generate an order above the limit and needs to handle it before it happens rather than after.

Slicing solves the rejection and creates two new problems. The slices are separate orders, so they incur separate brokerage, and they hit the book sequentially, so later slices execute at worse prices than the first. Both effects are real costs that a backtest assuming a single fill at one price does not include.

Validity and product type: the quiet incident generators

These two fields cause more live problems than order-type selection, precisely because they are set once during integration and then never examined again.

Making execution choices auditable

Execution quality cannot be improved without being measured, and measuring it requires recording the intent alongside the outcome. The single most useful field is the price at the moment the decision was made, because the difference between that and your average fill is the number you are actually trying to reduce.

With those fields you can answer the question that actually improves returns: for this strategy, on this instrument, at this time of day, does an aggressive order or a passive one net more after costs? That is an empirical question about your own order flow, and it has a different answer for different strategies. Slippage and impact cost covers how to turn those records into a number.