Wealth and Advisory Build Sheet

How to read this build sheet

The Wealth and Advisory module explains why suitability is the obligation everything else hangs off. This page is the parts list: data sources, profiling and optimisation components, execution rails, what each costs, and the three builds.

Six jobs. The first one is the one product teams want to skip, and skipping it makes everything after it unlawful rather than merely bad.

What you are allowed to build

Before any tooling decision, settle what you are. The perimeter is sharper in wealth than anywhere else in this section, and disclaimers do not move it.

Two more boundaries that catch product teams:

• IAs cannot provide trading calls. That is a specific prohibition, not a matter of framing.
• Advice and execution are structurally segregated. Segregation at client level, and at group level for non-individuals. An individual cannot do both simultaneously, so a robo-advisory platform needs a separate entity — a company or an LLP. Adviser recommends, client authorises, execution happens through brokers or AMCs. Fee-only, no commission from product manufacturers.

The finfluencer framework closes the remaining gap: registered entities may not pay, refer to, or share data with unregistered finfluencers; educational content must not carry stock price data less than three months old; no performance claims, no return guarantees.

SEBI on AI: responsibility goes up, not down

Most regulators are still deciding what they think about AI. SEBI has decided, and its position runs opposite to the industry's hope.

The robo-specific expectations are the closest thing to a written build specification any Indian regulator has published for an AI product. Treat them as the acceptance criteria:

• The algorithm is tested for correctness and transparency, and the testing is documented.
• A qualified person oversees algorithm output — a named human, not a team.
• Clients are told the advice comes from a system.
• No commission conflicts anywhere in the recommendable universe.
• The whole thing is inspection-ready at all times, not preparable on request.

Read that list as an architecture. "Tested for correctness" means the suitability logic must be deterministic enough to have a correct answer. "Inspection-ready at all times" means the reasoning behind every past recommendation is stored, not reconstructible. Neither is achievable if a language model decides what a client may hold.

Raw materials — market and fund data

Raw materials — profiling, optimisation, record

The calculation layer is almost entirely open source, and that is the right answer here. A suitability engine you cannot read line by line cannot be "tested for correctness and transparency".

How to use each one — capacity and tolerance

The one-line rule the whole module rests on

Capacity is what the client can afford to lose. Tolerance is what they are willing to lose. They are different measurements with different evidence, and the binding constraint is the lower of the two.

from dataclasses import dataclass

@dataclass
class Profile:
    capacity: int      # 1-5. What the client can AFFORD to lose. Objective.
    tolerance: int     # 1-5. What the client is WILLING to lose. Subjective.
    required: int      # 1-5. What the stated goal would DEMAND. Not a permission.

def binding_risk(p: Profile) -> dict:
    # The whole module in one line. The binding constraint is the LOWER of what
    # the client can bear and what they are willing to bear. `required` never
    # raises it -- it is a property of the goal, not of the client.
    binding = min(p.capacity, p.tolerance)

    out = {"binding": binding, "capacity": p.capacity, "tolerance": p.tolerance}

    if p.required > binding:
        # THE GOAL CHANGES, NOT THE PORTFOLIO.
        # Optimising toward a stated goal is the natural engineering framing and
        # it inverts the obligation. A system that raises risk to reach a target
        # is not advising, it is rationalising.
        out["action"] = "renegotiate_goal"
        out["options"] = ["extend_horizon", "increase_contribution", "reduce_target"]
        out["forbidden"] = "increase_portfolio_risk_to_meet_target"
    else:
        out["action"] = "proceed"

    # Capacity far below tolerance is the dangerous asymmetry: a client happy to
    # take risk they cannot afford. Capacity always wins, and the gap is worth
    # recording because it predicts complaints after a drawdown.
    if p.tolerance - p.capacity >= 2:
        out["flag"] = "tolerance_exceeds_capacity"
        out["note"] = "document the conversation; expect regret risk in a fall"
    return out

# WHAT TO CHECK
# [ ] capacity is computed from FACTS -- income stability, dependants, emergency
#     fund, horizon, debt -- not from a questionnaire about feelings
# [ ] tolerance is measured with scenario questions ("your 10 lakh becomes 7
#     lakh in four months; what do you do?"), not a 1-10 slider. Stated tolerance
#     is weak evidence and collapses in a real drawdown
# [ ] `required` is stored but NEVER feeds the allocation ceiling
# [ ] no fact find on file => the function is not called at all. No advice
# [ ] the profile is versioned. When it changes, the change and its reason are
#     recorded, because the next question after a complaint is "on what basis"
# [ ] profiles expire. A three-year-old risk profile is not a current one
# [ ] the client sees their own capacity and tolerance scores and can dispute
#     them. An unexplainable score is not transparent advice

The gotcha nobody documents: the natural engineering framing is "the client wants ₹2 crore in fifteen years; solve for the portfolio that gets there". That framing is the violation. If the goal demands more risk than the client can bear, the goal changes — longer horizon, larger contributions, smaller target — not the portfolio. Automated advice systems get this wrong constantly, because goal-seeking is what optimisers are for and nobody notices that the constraint has been quietly relaxed to make the objective reachable.

How to use each one — suitability and allocation

The hybrid, and why it is not optional here

This is the same architecture as the credit module and for the same reason: a model never decides what is permitted, only how to allocate within what is permitted.

import cvxpy as cp
import numpy as np

# Two layers, and the order is the point. Deterministic rules decide WHAT IS
# PERMITTED. Optimisation decides HOW TO ALLOCATE within that. A model never
# expands the permitted set -- that is what makes the system testable for
# correctness, which is a stated SEBI expectation for robo-advisory.

def permitted_universe(profile, client, catalogue):
    allowed, excluded = [], []
    for f in catalogue:
        reasons = []
        if f.risk_band > profile["binding"]:
            reasons.append("exceeds_binding_risk")
        if f.min_horizon_years > client["horizon_years"]:
            reasons.append("horizon_too_short")
        if f.lock_in_years > 0 and client["needs_liquidity_within"] < f.lock_in_years:
            reasons.append("lock_in_vs_liquidity_need")
        if f.pays_commission:
            reasons.append("commission_conflict")   # fee-only: no exceptions
        if f.category in client.get("excluded_categories", []):
            reasons.append("client_exclusion")
        (allowed if not reasons else excluded).append(
            {"fund": f.id, "reasons": reasons})
    return allowed, excluded          # BOTH are stored. Exclusions are evidence.

def allocate(allowed, mu, sigma, max_single=0.25, cap_by_band=None):
    n = len(allowed)
    w = cp.Variable(n)
    constraints = [cp.sum(w) == 1, w >= 0, w <= max_single]
    for band, cap in (cap_by_band or {}).items():
        idx = [i for i, a in enumerate(allowed) if a["band"] == band]
        if idx:
            constraints.append(cp.sum(w[idx]) <= cap)
    # Objective only ever ranks INSIDE the permitted set.
    prob = cp.Problem(cp.Maximize(mu @ w - 0.5 * cp.quad_form(w, sigma)), constraints)
    prob.solve()
    if prob.status not in ("optimal", "optimal_inaccurate"):
        return {"ok": False, "reason": "infeasible", "action": "human_review"}
    return {"ok": True, "weights": np.round(w.value, 4).tolist()}

# WHAT TO CHECK
# [ ] the EXCLUSION LIST is persisted with the recommendation. "Why was this
#     fund not recommended" is a real question and the answer must already exist
# [ ] an infeasible optimisation goes to a human. It usually means the permitted
#     set is too small for the goal -- which is information, not an error
# [ ] no code path lets the optimiser add an instrument that permitted_universe
#     excluded. Assert it in a test, not in a comment
# [ ] covariance estimated over a stated window, and the window is a versioned
#     parameter. Changing it changes advice
# [ ] the recommendable universe contains NO commission-paying products at all.
#     Fee-only is a structural property, not a filter you can switch off
# [ ] every run stores: rule version, profile version, catalogue snapshot, mu/
#     sigma inputs, solver status, output. This is "inspection-ready"
# [ ] the named qualified person who oversees output is recorded per run

The gotcha nobody documents: store the exclusions, not just the recommendation. Every advisory product persists what it advised. Almost none persists what it declined to advise and why. "Why did your system never recommend this fund to this client" is a question with a correct answer, and if you have to recompute it from a catalogue that has since changed, you cannot answer it at all. The exclusion list is small, cheap to store, and it is the difference between inspection-ready and inspection-panicked.

Where the language model belongs

It belongs in three places, all of them either side of the decision rather than inside it.

• The fact find. A conversational intake that extracts structured facts is a good use, provided the extracted facts are shown back to the client and confirmed before they are used.
• Explanation. Turning a deterministic recommendation into prose the client understands, grounded strictly in the recommendation's own stored reasoning.
• Document reading. Parsing a consolidated account statement to discover existing holdings.

How to use each one — monitoring what you advised

The module's phrase for this is that glide paths beat periodic reviews, and the code above is what that means in practice. A horizon shortens every day. An allocation that steps down at an annual meeting is wrong for 364 days out of 365, and it is most wrong in the year before the client needs the money.

from datetime import date

# Advice is not an event. What you recommended becomes something you are
# responsible for watching -- as markets move, and as the client's life moves.

def review(holding, profile, today=None):
    today = today or date.today()
    events = []

    # 1. ALLOCATION DRIFT. Bands, not a fixed calendar. A quarterly rebalance
    #    that fires when nothing has drifted is cost without benefit; one that
    #    waits three months while equity runs to 80% is a control that missed.
    for asset, target in holding["targets"].items():
        actual = holding["actual"][asset]
        if abs(actual - target) > holding["band"]:
            events.append({"type": "drift", "asset": asset,
                           "target": target, "actual": actual})

    # 2. GLIDE PATH. Horizon shortens every single day; the suitable allocation
    #    should move continuously with it, not in a jump at a review meeting.
    years_left = (holding["goal_date"] - today).days / 365.25
    glide_target = max(0.20, min(0.80, 0.10 + 0.045 * years_left))
    if abs(holding["targets"]["equity"] - glide_target) > 0.05:
        events.append({"type": "glide_path_due",
                       "current": holding["targets"]["equity"],
                       "should_be": round(glide_target, 3),
                       "years_left": round(years_left, 2)})

    # 3. THE PROFILE ITSELF AGES. Facts go stale faster than portfolios.
    if (today - profile["as_of"]).days > 365:
        events.append({"type": "profile_stale", "as_of": str(profile["as_of"]),
                       "action": "re_verify_before_any_new_advice"})

    # 4. SUITABILITY REGRESSION. A holding that was suitable at recommendation
    #    can stop being suitable without anyone transacting -- the fund changed
    #    mandate, or the client's capacity fell.
    for f in holding["funds"]:
        if f["current_risk_band"] > profile["binding"]:
            events.append({"type": "now_unsuitable", "fund": f["id"],
                           "was": f["risk_band_at_advice"],
                           "now": f["current_risk_band"],
                           "action": "notify_client_and_review"})
    return events

# WHAT TO CHECK
# [ ] drift uses BANDS; a calendar review is a reporting cadence, not a control
# [ ] the glide path is continuous and its formula is versioned. Clients near a
#     goal date are the ones a market fall actually hurts
# [ ] every review RUN is recorded, including the ones that found nothing. "We
#     checked and there was nothing to do" is evidence; silence is not
# [ ] a fund changing mandate or risk band triggers a re-check of every client
#     holding it, not just the next person to log in
# [ ] the client is notified when something becomes unsuitable, even if you are
#     not recommending a change -- especially then
# [ ] tax and exit-load consequences are computed BEFORE a rebalance is
#     suggested. A suitable rebalance that destroys returns after tax is not
#     suitable advice
# [ ] notifications respect the education/advice boundary. "Your equity is above
#     target" is a fact; "you should switch to X" is advice and needs the rest
#     of this pipeline behind it

The gotcha nobody documents: record the reviews that found nothing. Advisory products log recommendations and log transactions, and log nothing at all on the days when the monitoring ran and everything was fine. Then a client's portfolio falls, they complain, and the question is whether you were watching. A run record with a null result answers it. An absence of records looks identical to an absence of monitoring, and you will be unable to tell the difference yourself.

Cost per unit

One structural note on eligibility, because it changes hiring. Since November 2025 a graduate in any discipline may register as an IA or RA provided they hold the required NISM certification — the finance, commerce, business or economics degree requirement is gone. The same qualification benchmark now extends to persons associated with investment advice. The constraint on building an advisory team has shifted from degrees to certification.

Best combinations

Combinations that conflict

• Advice plus commission. Structurally incompatible. Not a disclosure problem, an entity problem.
• Advice and execution in one individual. A robo platform needs a separate company or LLP.
• An LLM in the suitability path. Breaks reproducibility and the correctness test at once.
• Optimising toward the client's stated target. Silently relaxes the risk constraint to make the objective reachable. The goal changes, not the portfolio.
• “Educational” personalised recommendations. The disclaimer does not change what it is, and enforcement has been expensive.
• A customer-facing product on a personal broker data key. Redistribution needs a licence.
• Periodic-only review. Wrong for most of the year and most wrong close to the goal date.
• Trading calls from an IA. Specifically prohibited.

Three recommended builds

Strong and expensive

Build: registered non-individual IA with a separate execution entity, a commercial wealthtech platform for RTA and StAR MF plumbing and reporting, licensed market data with proper redistribution rights, a qualified oversight team, and full temporal audit infrastructure.

Use when: you are advising on meaningful assets, clients expect statements and reviews, and the fee per client can support a human in the loop.

Cost shape: registration and deposit, platform licensing, data licensing, and — dominating everything — the qualified people the regulations require.

Trade: the economics only work at higher ticket sizes. Against a ₹1.51 lakh ceiling and a realistic average far below it, this build needs either wealthy clients or a lot of them.

Strong and reasonable — the default

Build: registered IA → Account Aggregator and RTA statements for the fact find → deterministic capacity, tolerance and suitability rules you wrote and can read → cvxpy or PyPortfolioOpt allocating strictly inside the permitted set → AMFI NAV with a validation layer → execution through a broker or StAR MF via a separate entity → banded drift plus a continuous glide path → temporal tables recording profile, rule version, catalogue snapshot and exclusions on every run → an LLM for intake and explanation only.

Use when: you have engineers and you intend to be a real adviser rather than a distributor with a quiz.

Cost shape: registration, near-zero for the calculation stack, modest data costs, and the named qualified person.

Trade: you write and maintain the suitability rules. That is the right trade — those rules are your regulatory position, and a vendor cannot hold it for you.

Strong and lean

Build: stay outside the advisory perimeter deliberately — genuinely generic education with no personalisation → calculators that compute rather than recommend → execution-only access if you have the licence for it → no "recommended for you" anywhere in the product.

Use when: you are pre-registration, or advice is not the business you actually want to be in.

Cost shape: data and hosting.

Trade: no personalisation at all, and that boundary needs active defence.

What next

Two things to settle before you write code, because both take longer than the build.

Registration. Three to six months, realistically. Discovering it at launch is the most common sequencing mistake in this module, and the recent amendments cut in both directions — the qualification bar is lower and the corporatisation threshold is higher, but the compliance audit and disclosure obligations are heavier.

Accessibility. Obligations under the Rights of Persons with Disabilities Act apply to regulated entities' digital platforms. It is routinely missed by product teams, it is cheap to design in from the start, and it is expensive to retrofit into a completed advisory journey.

What this feeds

Sources

Every figure, rule and date on this page, and where to check it. Entries are typed so you can see which numbers are primary-sourced and which are industry reporting — they are not equivalent, and treating them as if they were is how a confident wrong number gets repeated.