Fund Manager Mode
Fund Manager Mode is the Enterprise way to run an optimization under a written mandate. You state the rules your portfolio must obey, and the optimizer solves inside them rather than producing a portfolio and being corrected afterwards. The one exception is Hierarchical Risk Parity under a sector or market-cap limit: a second solve on top of the HRP weights meets that limit, and the run says so.
What it requires
An Enterprise plan, and at least one constraint. A fund-manager run without a mandate is refused rather than accepted and ignored, because a run that claims to follow rules it was never given is worse than a run that admits it had none.
Two separate entitlements sit behind it. One allows constraints; one allows the mode. They move independently on purpose, so constraints can reach another plan later without the mode moving with them.
The run records its mode. Your history, a saved comparison and the results page each show a fund-manager run as one, and an account that leaves the Enterprise plan can still read its earlier fund-manager runs.
The three things a mandate can say
Sector limits and market-cap limits are one family here, not two. They differ only in which classification you attach, and no solver distinguishes them.
| Rule | In plain terms | Methods that solve it directly |
|---|---|---|
| Per-stock bounds | A floor and a ceiling on each holding | 34 of 38 |
| Excluded stocks | Names the portfolio may not hold at all | 33 of 38 |
| Group limits | A cap or floor on a sector or a market-cap segment | 30 of 38plus Hierarchical Risk Parity, by a second solve on top of its weights |
The Portfolio Constraints page carries the full per-method table, the mathematics each family uses, and the reason the hierarchical methods handle group limits differently.
Three answers, and each one is stated
For any method and any rule, the answer is one of three:
- Solved directly: the rule entered the program the method actually solves.
- Met by a second solve: the method does not take the rule itself, and a second solve on top of its weights meets it. Only Hierarchical Risk Parity's sector and market-cap limits are answered this way. The result is no longer a pure HRP allocation and can have higher turnover, and the run, the results page and the backtest page say so.
- Unsupported: the rule cannot be expressed for that method at all.
There used to be a different answer: a method could allocate without the rules and then clip the result toward them afterwards. Every such path was removed, because a repaired allocation is not a constrained optimum and presenting one as the other is the mistake this whole feature exists to avoid. HRP's second solve is not that: it is an exact solve under every rule, a mandate it cannot meet is refused by name and never relaxed, and it is never presented as a direct solve.
An unsupported combination is refused before the run is spent. The optimize form and the API both read the same server-side table, so a method that cannot take your mandate says so before you submit.
What happens before a run is spent
The whole mandate is checked at once. Every rule is compiled into one linear program over the filtered universe. Checking rules one at a time cannot see a conflict between two rules that each pass alone, and those are the conflicts that actually happen.
An impossible mandate names the conflict. The question after a refusal is not “is this impossible” but “which number do I move, and by how much”. The preflight answers the second one.
Reachable ranges are computed from your universe. A 40% technology cap means nothing if the names you selected can only reach 22%. The preflight reports what the universe can actually support, so a cap that can never bind is visible as such.
The preflight spends no run and no quota. You can check a mandate as often as you like. A fund-manager request that is refused at submission also costs no monthly run.
The mandate is checked again when the run starts. The submission check reads the stocks you selected. A stock with too little price history is removed before the solve, and a smaller universe can make a mandate impossible that passed at submission, so the run checks it once more on the stocks that remain.
What the reports attest to
Every PDF and workbook carries a Constraints section stating what was requested, what was enforced, and where the two differ. The stored weights are validated against the mandate they claim to satisfy, so a run cannot report a rule as enforced and store a portfolio that breaks it.
A backtest is the case to read carefully. A group rule needs a classification for each name, and a classification recorded today cannot be applied to a rebalance from years ago without knowing what was true then. Where that would happen the group rules are dropped for the backtest, and the report says so rather than quietly applying today’s sectors to the past.
What it does not add
Stated plainly, because the absence of a number is easier to plan around than a number that turns out to mean something else.
- Active share and active attribution. Both need dated benchmark constituent weights, which the platform does not hold.
- A forward tracking-error distribution, or a probability of underperforming the benchmark. Neither ships. A probability from the simulator is conditional on the model, the frozen inputs, the configuration, the engine version and the seed, and no generator has passed out-of-sample validation. A Monte Carlo simulation of a fund-manager portfolio is an ordinary simulation of its weights, and it holds the weights the run stored rather than re-optimizing along each path.
- SEBI category rules. These key to a sector or size definition the platform cannot yet assert.
- An authoritative sector or market-cap taxonomy. You supply the sector list. Market-cap segments come from a market-capitalisation snapshot on absolute thresholds, which is not the SEBI rank-based large, mid and small cap list.
- Market impact or execution cost. The liquidity measures report how long an exit would take at a stated participation rate. They do not price the trade.
Information ratio and tracking error are computed, on every plan and in either mode, against the run’s own benchmark. The mode adds nothing to those two numbers. Every surface states which series the benchmark is: the price index, or the Total Return Index, which also counts the dividends of the index companies.
The default benchmark
A fund-manager run that names no benchmark measures against NIFTY 500 on its Total Return Index. A run that names a benchmark but not its series uses that benchmark’s Total Return Index where one exists. SENSEX has no Total Return Index here, so a fund-manager run on SENSEX stays on the price index.
On the optimize form, turning on Fund Manager Mode moves an untouched NIFTY 50 or SENSEX price benchmark to NIFTY 500 TRI. A benchmark or a series you chose yourself stays as you set it. A retail run is not changed, and keeps the price index unless you select the Total Return Index.
The benchmark is recorded with the run, so a backtest or a Monte Carlo simulation of that run uses the same series. Against a price index, alpha and the information ratio are overstated by approximately the index dividend yield, and each affected value is marked on the results page and in every export. Tracking error, beta and M2 are not affected.
Using it from an assistant
The mode and the mandate are both settable over MCP: submit_optimization takes a mode argument, and the config://fund_manager_mode resource states the three rules, the plan it needs and what the mode does not add. preview_constraints runs the same feasibility check the website runs, without spending a run, which is the right call before submitting anything carrying a group rule.
A sector map can be sent inline with the request, or saved and referenced by id. list_classification_maps returns the saved ones. Read AI Assistants for the full tool surface.
Not investment advice. Past performance is not indicative of future results.