Slicing large orders

Chapter 63 splits orders because the exchange *forces* you to (freeze limits). This chapter slices orders because *you choose to*, to reduce market impact — a large order hitting the book at once can move the price against you before it's fully filled.

Iceberg orders — broker-native slicing

order_id = kite.place_order(
    variety="iceberg",
    exchange="NSE",
    tradingsymbol="RELIANCE",
    transaction_type="BUY",
    quantity=1000,
    iceberg_legs=10,       # splits into 10 legs of 100 each
    iceberg_quantity=100,   # visible quantity per leg
    product="CNC",
    order_type="LIMIT",
    price=2945.00,
    validity="DAY",
)

Only a fixed amount (iceberg_quantity) is visible in the order book at a time — as each visible chunk fills, the next chunk is automatically released. This hides your true order size from other market participants, reducing the chance of adverse price movement caused by visible large-size signaling.

Manual slicing (TWAP-style) when iceberg isn't available/appropriate

import time

def twap_slice_order(kite, exchange, symbol, total_qty, num_slices, interval_seconds, **order_kwargs):
    slice_qty = total_qty // num_slices
    remainder = total_qty % num_slices
    order_ids = []
    for i in range(num_slices):
        qty = slice_qty + (remainder if i == num_slices - 1 else 0)
        oid = kite.place_order(
            exchange=exchange, tradingsymbol=symbol, quantity=qty, **order_kwargs
        )
        order_ids.append(oid)
        if i < num_slices - 1:
            time.sleep(interval_seconds)
    return order_ids

This spreads execution over time (a simple Time-Weighted Average Price approach) rather than space (iceberg's visible-quantity approach) — use whichever mechanism, or combine both, based on how much of your impact concern is about visible size vs. speed of execution.

When slicing matters vs when it's overkill

For retail-scale position sizes on liquid large-caps or index F&O, market impact from your own order size is usually negligible — slicing adds complexity (more orders to track, more chances for partial-fill bugs) without real benefit. Reserve this for genuinely large orders relative to typical book depth (check chapter 26's depth data before deciding you need this).

Next: 065 — Tagging orders by strategy