Smart Order Routing and Multi-Venue Execution

Right now, with the market shut, the same RELIANCE share carries two prices: 1318.10 on NSE and 1318.25 on BSE. A 15 paise difference on a 1318 rupee stock sounds like rounding error, and most days it is. But the two exchanges are independent matching engines running their own order books in parallel, and nothing forces them to agree to the paisa. When the bell rings, those books drift apart and snap back hundreds of times a day. Whenever they disagree, there is a better side to buy on and a better side to sell on - and the job of a smart order router is to find it before the gap closes. This chapter is about that machinery: why a single instrument lives in two places at once, how a router chooses between them, and what "best execution" really obliges you to do.

One company, two order books

A large Indian company is typically listed on both NSE and BSE. Each exchange keeps its own limit order book, its own price-time priority queue, and its own stream of trades. They share the same underlying company and the same clearing plumbing, but they do not share a book. That is the whole reason routing exists: a buy order resting on NSE cannot fill against a cheaper sell order sitting on BSE. The two queues are walled off, so price discovery happens twice, slightly out of step.

Most of the time arbitrage keeps them within a tick of each other. Market makers quote both venues simultaneously, and the moment one side gets cheap, someone lifts it and re-sells on the dearer side. That competition is exactly what holds the gap near zero. But "near zero" is not zero, and the residual wobble is real money on size.

What a smart order router actually does

A smart order router (SOR) is a piece of execution software that sits between your decision to trade and the exchanges. Given a parent order ("buy 5,000 RELIANCE"), it builds a consolidated view of liquidity across every venue it can reach, then slices and sends child orders to wherever the fill is best right now. To buy, it wants the lowest ask; to sell, it wants the highest bid. If one venue cannot fill the whole size at the top price, the router takes what is there and sweeps the remainder to the next-best venue.

Underneath, the SOR is solving a small optimisation each instant: minimise the total cost of the fill (price plus fees plus expected impact) subject to the displayed depth at each venue. The simplest version is a pure price sweep, as above. Richer routers also weigh exchange transaction charges, the probability a passive order actually fills, and the risk that the price moves while they wait. The point is the same: never blindly send the whole order to one venue when the other is showing a better price.

Here is the raw signal a router reads, captured from the two live quote feeds:

# Cross-venue prices: the same stock quoted on NSE and BSE, and where to buy vs sell.
import os

from openalgo import api

client = api(
    api_key=os.getenv("OPENALGO_API_KEY", "your_api_key_here"),
    host=os.getenv("OPENALGO_HOST", "http://127.0.0.1:5000"),
)

# Large dual-listed names trade on both NSE and BSE at the same time.
SYMBOLS = ["RELIANCE", "TCS", "HDFCBANK"]

print(f"{'SYMBOL':<10}{'NSE':>10}{'BSE':>10}{'GAP Rs':>9}{'GAP bps':>9}   BUY @   SELL @")
for sym in SYMBOLS:
    n = client.quotes(symbol=sym, exchange="NSE")["data"]["ltp"]
    b = client.quotes(symbol=sym, exchange="BSE")["data"]["ltp"]
    gap = n - b                              # NSE minus BSE
    bps = 10000 * gap / ((n + b) / 2)        # gap as a fraction of mid, in basis points
    buy_at = "NSE" if n <= b else "BSE"      # buy where it is cheaper
    sell_at = "BSE" if b >= n else "NSE"     # sell where it is dearer
    print(f"{sym:<10}{n:>10.2f}{b:>10.2f}{gap:>+9.2f}{bps:>+9.1f}   {buy_at:<7} {sell_at}")

# Focus on one name for the one-line takeaway.
sym = SYMBOLS[0]
n = client.quotes(symbol=sym, exchange="NSE")["data"]["ltp"]
b = client.quotes(symbol=sym, exchange="BSE")["data"]["ltp"]
better_buy = "NSE" if n <= b else "BSE"
better_sell = "BSE" if b >= n else "NSE"
print(f"\n{sym}: NSE {n} vs BSE {b}. A smart router buys on {better_buy} (cheaper) "
      f"and sells on {better_sell} (dearer); gap {abs(n - b):.2f} Rs "
      f"({abs(10000 * (n - b) / ((n + b) / 2)):.1f} bps).")

SYMBOL           NSE       BSE   GAP Rs  GAP bps   BUY @   SELL @
RELIANCE     1318.10   1318.25    -0.15     -1.1   NSE     BSE
TCS          2094.70   2095.60    -0.90     -4.3   NSE     BSE
HDFCBANK      796.30    796.05    +0.25     +3.1   BSE     NSE

RELIANCE: NSE 1318.1 vs BSE 1318.25. A smart router buys on NSE (cheaper) and sells on BSE (dearer); gap 0.15 Rs (1.1 bps).

The output makes the logic concrete. RELIANCE was 1318.10 on NSE against 1318.25 on BSE - a router buys on NSE, the cheaper side, and would sell on BSE, the dearer side, for a 0.15 rupee (1.1 bps) edge. TCS showed a wider 0.90 rupee gap (4.3 bps), again NSE-cheap. But HDFCBANK flipped it: BSE was 25 paise cheaper, so the better buy was BSE. That flip is the whole lesson - no venue is permanently best. The right side changes by name and by moment, which is precisely why you need a router checking continuously rather than a fixed habit of "always send to NSE".

Best execution is a duty, not a courtesy

When you place an order through a broker, the broker is not free to fill you wherever is most convenient for them. Under SEBI's broker conduct rules, an intermediary owes its client best execution - a duty to take reasonable care to obtain the most favourable terms available, considering price, cost, speed and likelihood of fill. Routing to a worse-priced venue when a better one was visible is a breach of that duty, not a stylistic choice.

A word of honesty about the Indian structure. Unlike the United States, India has no mandated consolidated tape and no order-protection rule that legally forbids trading through a better price on another exchange. There is no official "national best bid and offer" you can point to. Best execution here is a principles-based obligation on the broker plus the constant pressure of arbitrage, not a hard-wired market rule that automatically reroutes your order. That makes the quality of your broker's routing logic something you should actually care about and, where you can, measure.

The catch: latency and a gap that will not sit still

Reading two prices is easy. Acting on the difference before it vanishes is the hard part. The gap between NSE and BSE is not a standing pool you can scoop from at leisure; it is a flicker. By the time your order reaches the cheaper venue, the quote you saw may already be gone, lifted by someone faster. This is why routing is a latency game: the value of seeing a better price decays in milliseconds, and a slow router is routing on stale information.

How big is the prize, and how often does it appear? Plot the daily NSE-minus-BSE close gap for RELIANCE and you can see the scale of it:

Copy

# The fleeting NSE-minus-BSE price gap over time - the tiny edge a smart router captures.
import os
from pathlib import Path

import matplotlib

matplotlib.use("Agg")
import matplotlib.pyplot as plt
import pandas as pd
import seaborn as sns
from openalgo import api

client = api(
    api_key=os.getenv("OPENALGO_API_KEY", "your_api_key_here"),
    host=os.getenv("OPENALGO_HOST", "http://127.0.0.1:5000"),
)

SYMBOL = "RELIANCE"
start, end = "2026-01-01", "2026-06-27"
cn = client.history(symbol=SYMBOL, exchange="NSE", interval="D", start_date=start, end_date=end)["close"]
cb = client.history(symbol=SYMBOL, exchange="BSE", interval="D", start_date=start, end_date=end)["close"]

px = pd.concat([cn, cb], axis=1, keys=["NSE", "BSE"]).dropna()
gap = px["NSE"] - px["BSE"]                       # rupees
bps = 10000 * gap / ((px["NSE"] + px["BSE"]) / 2)  # basis points of mid

sns.set_theme(style="whitegrid")
fig, ax = plt.subplots(figsize=(9.5, 4.6))
ax.axhline(0, color="#334155", lw=1.0)
ax.bar(bps.index, bps.values, width=1.0,
       color=["#16a34a" if v >= 0 else "#dc2626" for v in bps.values])
ax.set_title(f"{SYMBOL}: NSE close minus BSE close - small, fleeting gaps a router exploits")
ax.set_ylabel("Cross-venue gap (bps of mid)")
ax.set_xlabel("Trading day")

out = Path(__file__).with_suffix(".png")
plt.savefig(out, dpi=110, bbox_inches="tight")
print(f"{SYMBOL} {len(px)} days: mean |gap| {bps.abs().mean():.1f} bps, "
      f"max |gap| {bps.abs().max():.1f} bps, days NSE dearer {int((gap > 0).sum())} / "
      f"BSE dearer {int((gap < 0).sum())}. Saved {out.name}")

Live output

RELIANCE 118 days: mean |gap| 2.9 bps, max |gap| 19.0 bps, days NSE dearer 58 / BSE dearer 57. Saved 02_venue_gap_chart.png

Over 118 trading days the average absolute gap was just 2.9 bps, with a worst day of 19.0 bps, and the sign was almost a coin toss: NSE was dearer on 58 days, BSE on 57. Two things follow. First, the typical edge is tiny - a few basis points - so it is the kind of money that only matters when multiplied across large size and high turnover, which is why cross-venue capture is a professional, latency-sensitive game rather than a retail one. Second, because the sign keeps flipping, a router has to check both directions every time; there is no durable "NSE is cheaper" rule to lean on.

SOR for the retail quant

You will not build a microsecond router on a laptop, and you do not need to. For a retail or systematic quant, smart routing shows up in two practical places. First, your broker runs its own SOR, and best execution means it should be sending your order to the better-priced venue for you; this is a reason to prefer the more liquid listing for a given name, since deeper books give tighter spreads and better fills regardless of the headline last price. Second, when you control the venue yourself - choosing whether to send a RELIANCE order to NSE or BSE through OpenAlgo - the cheap, sane default is to trade the venue where the instrument is most liquid, because depth, not the last-traded price, decides what you actually pay once you cross the spread.

The deeper idea carries into the rest of Module D. A router decides where to send each slice; the next question is how to schedule a large order over time so it does not move the market against itself. That is the work of execution algorithms - VWAP, TWAP and implementation-shortfall scheduling - which we turn to next.