Portfolio Construction

Selection and Sizing Decay at Different Speeds

Saral Team · 1 August 2026

Every strategy in this catalogue so far does two things on one schedule: it decides what to hold and how much of each, then waits until the next rebalance.

That is a compromise, and it is worth seeing why.

Two questions, two clocks

“Which companies deserve to be in this portfolio?” is a question about businesses. Its inputs are fundamentals that update quarterly, index membership that changes semi-annually, momentum measured over twelve months. The answer moves slowly, and it should — a screen whose constituents turn over every week is not identifying quality, it is chasing noise.

“How much risk is each position contributing?” is a question about markets right now. Its inputs are realised volatility and correlation, both of which move fast and cluster. A position that was 8% of your risk budget last month can be 20% of it today because that stock’s volatility tripled, without the company changing at all.

Run both monthly and the weights sit stale for weeks while risk quietly concentrates. Run both weekly and you re-derive a selection that has not changed, churning constituents and paying costs for the privilege.

Neither frequency is right, because there is no single right frequency for two different questions.

Splitting them

The fix is to run two components with different schedules on the same canvas:

[A] monthly:  universe -> screen -> rank -> rebalance -> broker
[B] weekly:   held book -> re-weight        -> rebalance -> broker -> alert

Component A is an ordinary strategy: it reads the universe, applies the screen, and establishes positions. It fires once a month.

Component B is the interesting one. Its source is not a universe — it is the portfolio that A established. It fires weekly, reads whatever is currently held, recomputes risk-parity weights against current volatility and correlation, and re-sizes. It never adds or removes a name.

The constituent list therefore changes monthly, on a business question. The weights change weekly, on a risk question. Turnover from component B is small — it is trimming and topping up existing positions, not entering and exiting.

Why the source node matters

The mechanism that makes this expressible is a source node that produces the held portfolio rather than a universe.

That is a genuinely different primitive. A universe source answers “what could I own?” A portfolio source answers “what do I own?” Almost every strategy is built on the first, but a large class of real portfolio management is built on the second: rebalancing, risk overlays, tax-loss harvesting, drift correction, trailing stops. None of those are selection problems.

One structural requirement: each component needs its own effect node — something that rebalances, routes to a broker, or fires an alert. A component that fetches data and filters it but never commits a portfolio is a no-op, and the engine rejects that at run start rather than producing a silently empty equity curve.

The watchlist universe

This template’s universe is not a screen at all. It is twelve named tickers.

That is the right shape for a specific and common situation: you have already decided what you are willing to own — through research, or conviction, or a mandate — and what you want the system to handle is timing and sizing, not discovery.

It is also the most honest universe for a small portfolio. Screening the Nifty 500 down to 30 names is only meaningful if you would genuinely have bought any of those 500. If in practice you would only ever hold large, familiar businesses, a screen over 500 names is theatre and a watchlist of twelve is the real universe.

The trade-off is that a hand-picked list carries your own selection bias, and backtesting over a list chosen today is a survivorship problem: you know which of those twelve did well. Treat the result accordingly.

Costing against a real broker

Most backtests apply a flat percentage commission. That is a placeholder, not a cost model.

An actual Indian equity delivery trade pays a stack: brokerage (often zero for delivery at discount brokers), STT at 0.1% on both legs, exchange transaction charges, SEBI turnover fees, stamp duty on the buy side, GST at 18% on brokerage and transaction charges, and DP charges per scrip on sale. Each has its own base and its own rate, and several are asymmetric between buy and sell.

Modelling a named broker’s actual charge schedule instead of a flat rate matters most for exactly the strategy shape described here — one that trades often in small increments. A flat 0.1% on a small rebalancing trade can be far off in either direction: it overstates cost where brokerage is genuinely zero, and understates it where fixed per-order and per-scrip charges dominate a small ticket.

Alerts as a first-class output

The final node is an alert on the order stream.

During a backtest an alert records the event and sends nothing. In live deployment it delivers. Having it in the graph means the same strategy definition that produced the backtest is the one that notifies you in production — the notification is not bolted on afterwards, it is part of the tested pipeline.

That matters for a two-speed strategy specifically, because component B fires weekly and produces small adjustments that are easy to miss. A rebalance you do not know happened is a rebalance you cannot sanity-check.

Try it

The Watchlist template picks the eight strongest of twelve watchlist names monthly, re-sizes the held book to equal risk contribution weekly, costs against Zerodha’s charge schedule, and alerts on every order.

The comparison that shows the point: build the same strategy as a single monthly component with risk-parity weighting, and compare turnover and the stability of risk contribution over time. The single-speed version will either churn constituents or let weights drift — and seeing which one happens tells you which question you had been answering on the wrong clock.