Building automated advice itself? The eight steps, why advice and execution cannot sit in one entity, and what Regulation 16C means for a bought model: Robo-Advisory: How to Build It →
Every tool for this module, how to use each one, what it costs, the best combinations and three recommended builds: Wealth Build Sheet →
What counts as advice
This is the whole module in one question, and getting it wrong is the most common way a wealth product becomes illegal.
| Statement | What it is |
|---|---|
| "A mutual fund pools money from many investors" | Education. General, impersonal, no recommendation. |
| "Index funds have historically had lower expense ratios than active funds" | Education. A fact about a category. |
| "Investors your age often hold more equity" | Borderline. Personalised framing around a general claim. |
| "Based on your profile, you should put 60% in equity" | Advice. Personalised recommendation. |
| "Consider buying X fund" | Advice. Specific product recommendation. |
| "Users like you chose X" | Advice in substance, whatever the wording suggests. |
A disclaimer does not change what something is. SEBI enforcement has been explicit that "for educational purposes only" does not excuse unregistered advisory activity. If you make trading or investment recommendations — including inside a course, a private group, or a chatbot reply — you need registration. The label on the box does not determine the contents.
Suitability, and why it is the core obligation
Advice is not judged on whether it made money. It is judged on whether it was suitable for that client when it was given.
A recommendation to put a 62-year-old’s entire retirement corpus into small-cap equity is unsuitable even if it triples. A conservative allocation that underperforms a bull market is suitable even though the client is unhappy.
Suitability rests on three things you must establish and record before advising:
- Capacity for loss — what could this person actually afford to lose without material harm?
- Risk tolerance — what volatility will they tolerate without abandoning the plan at the worst moment?
- Objectives and horizon — what is the money for, and when is it needed?
These are frequently conflated, and they are different. A wealthy client may have high capacity and low tolerance. A young client may have high tolerance and a two-year horizon, which makes equity unsuitable regardless.
What AI can and cannot do here
| Task | How well AI does it |
|---|---|
| Optimise a portfolio against constraints | Very well. This is deterministic maths, not judgement. |
| Rebalance to a target allocation | Very well. Rules, tax lots, thresholds. |
| Explain a concept to a client | Well, if grounded in approved material. |
| Summarise a portfolio for a human adviser | Very well. High value, low risk. |
| Infer risk tolerance from a questionnaire | Moderately. Stated tolerance is a poor predictor of behaviour under loss. |
| Predict market returns | No. Claims otherwise should be treated as a red flag. |
| Judge whether a recommendation is suitable | Partially. It can apply your rules; it cannot own the judgement. |
| Give personalised investment advice unsupervised | It must not. A qualified person is required to oversee the output. |
The structural fact: AI increases your responsibility
Most regulated activities treat automation as neutral. SEBI has taken the opposite position explicitly.
Under its framework for AI use by advisers, using AI does not reduce responsibility — it increases it. An adviser deploying AI or algorithmic tools must take full legal responsibility for AI-generated advice, is accountable for anything incorrect or misleading it produces, must ensure data security, integrity and transparency of the advice derived from those tools, and must disclose the extent of AI usage to clients.
For robo-advisory platforms specifically, the additional expectations are concrete: test the algorithm for correctness and transparency, have a qualified person overseeing the algorithm’s output, tell users they are receiving advice from a system, avoid recommending products you earn commission on, and be ready for inspection at any time.
Read that list as a build specification, not as compliance paperwork. Algorithm testing, human oversight, disclosure and conflict-free product selection are architectural decisions. Retrofitting them after launch means rebuilding the recommendation path.
The advisory pipeline
Nine steps. Two of them are safe to automate fully, one of them is the regulated act, and the boundary between them is the design decision that matters.
CLIENT
|
1. ONBOARDING + KYC Module 01. Also: are they eligible for
| this service at all?
|
2. FACT FIND income, assets, liabilities, dependants,
| existing holdings, goals, horizon, tax status
| -> incomplete fact find = no advice. Full stop.
|
3. RISK PROFILING capacity for loss (objective, from finances)
| risk tolerance (behavioural)
| risk required (what the goal demands)
| -> the BINDING constraint is the LOWEST of the three
|
4. SUITABILITY ENVELOPE permitted asset mix range, product exclusions,
| concentration limits
| -> deterministic RULES, not model output
|
5. OPTIMISATION construct within the envelope
| -> maths. Safe to automate.
|
6. RECOMMENDATION specific products + rationale + risks
| -> REGULATED OUTPUT. Human oversight required.
|
7. DISCLOSURE + CONSENT fees, conflicts, AI usage extent, risk warnings
|
8. EXECUTION SEPARATE. Client authorises. See below.
|
9. ONGOING REVIEW drift, rebalancing, changed circumstances
|
AUDIT everything at every step, with the suitability reasoning attached.
Steps 4 and 5 are safe to automate.
Step 6 is where the regulated judgement lives.No fact find, no advice
An incomplete fact find is not a reason to give cautious advice. It is a reason to give no advice.
This is where digital products drift, because every additional onboarding question costs conversion. The temptation is to infer what you did not ask. Resist it: a recommendation built on assumed circumstances is unsuitable by construction, and the record will show exactly which facts you never established.
Risk profiling done properly
Most risk questionnaires measure one thing badly. There are three things, and they constrain differently.
from dataclasses import dataclass
@dataclass
class RiskProfile:
capacity: int # 1-5, objective, derived from finances
tolerance: int # 1-5, behavioural, from questionnaire
required: int # 1-5, what the goal actually demands
horizon_years: float
@property
def binding(self) -> int:
"""The constraint is the LOWEST of capacity and tolerance.
'Required' is NOT a permission to take more risk - if the goal
demands more risk than the client can bear, the GOAL changes,
not the portfolio. This is the single most common error in
automated advice."""
return min(self.capacity, self.tolerance)
@property
def goal_is_unrealistic(self) -> bool:
return self.required > self.binding
def capacity_for_loss(f) -> int:
"""Objective. What could they lose without material harm?
Deliberately conservative - capacity errors are unrecoverable."""
score = 3
months_buffer = f["liquid_savings"] / max(1, f["monthly_expenses"])
if months_buffer < 3: score -= 2
elif months_buffer < 6: score -= 1
elif months_buffer > 18: score += 1
surplus_ratio = (f["monthly_income"] - f["monthly_expenses"]
- f["monthly_emi"]) / max(1, f["monthly_income"])
if surplus_ratio < 0.05: score -= 2
elif surplus_ratio > 0.30: score += 1
if f.get("dependants", 0) >= 3: score -= 1
if f.get("income_stability") == "irregular": score -= 1
if f.get("job_sector_risk") == "high": score -= 1
if not f.get("health_insurance"): score -= 1 # one illness away
return max(1, min(5, score))
def horizon_cap(years: float) -> int:
"""Time in the market is the real risk control.
A short horizon caps risk regardless of appetite or wealth."""
if years < 1: return 1
if years < 3: return 2
if years < 5: return 3
if years < 10: return 4
return 5
def build_profile(fact_find, questionnaire_score, goal_required, years):
cap = min(capacity_for_loss(fact_find), horizon_cap(years))
return RiskProfile(capacity=cap,
tolerance=questionnaire_score,
required=goal_required,
horizon_years=years)The rule buried in that code
binding = min(capacity, tolerance), and required is not a permission.
If a client needs 14% annual returns to hit their goal and can only bear a risk level consistent with 8%, the answer is that the goal must change — longer horizon, larger contributions, or a smaller target. It is not that the portfolio takes more risk.
Automated advice systems get this wrong constantly, because optimising toward a stated goal is the natural engineering framing and it inverts the obligation.
Stated tolerance is weak evidence
Questionnaire tolerance measures what someone believes about themselves in a calm moment. Behaviour under a 30% drawdown is a different thing, and the gap is where clients abandon plans at the worst possible time.
Better signals if you have them: what they actually did in past drawdowns, how they responded to previous volatility in their own portfolio, and whether their stated answers are internally consistent. Where tolerance and observed behaviour disagree, weight the behaviour.
Suitability as rules, optimisation as maths
The architecture that keeps this defensible separates the two completely.
ENVELOPE = {
# binding_risk -> (min_equity, max_equity, max_single_holding,
# max_illiquid, permitted_categories)
1: (0.00, 0.15, 0.10, 0.00, {"liquid", "ultra_short_debt"}),
2: (0.10, 0.35, 0.10, 0.00, {"liquid", "short_debt", "large_cap", "hybrid"}),
3: (0.30, 0.60, 0.10, 0.05, {"debt", "large_cap", "flexi_cap", "hybrid", "index"}),
4: (0.50, 0.80, 0.15, 0.10, {"debt", "large_cap", "flexi_cap", "mid_cap",
"index", "international"}),
5: (0.65, 0.95, 0.20, 0.15, {"large_cap", "flexi_cap", "mid_cap", "small_cap",
"index", "international", "sectoral"}),
}
def suitability_check(profile, proposed, holdings_universe):
"""Runs BEFORE a recommendation is shown and AFTER optimisation.
A breach is a hard block, never a warning the client can dismiss."""
lo, hi, max_single, max_illiq, allowed = ENVELOPE[profile.binding]
breaches = []
equity = sum(w for p, w in proposed.items()
if holdings_universe[p]["asset_class"] == "equity")
if equity < lo: breaches.append(f"equity_below_floor:{equity:.2f}<{lo}")
if equity > hi: breaches.append(f"equity_above_cap:{equity:.2f}>{hi}")
for p, w in proposed.items():
cat = holdings_universe[p]["category"]
if cat not in allowed:
breaches.append(f"category_not_permitted:{cat}")
if w > max_single:
breaches.append(f"concentration:{p}@{w:.2f}>{max_single}")
if holdings_universe[p].get("illiquid") and w > max_illiq:
breaches.append(f"illiquid_exposure:{p}")
# Horizon rule that overrides everything above
if profile.horizon_years < 3 and equity > 0.20:
breaches.append("equity_with_short_horizon")
# Conflict rule: never recommend a product you earn commission on
for p in proposed:
if holdings_universe[p].get("pays_us_commission"):
breaches.append(f"conflicted_product:{p}")
return (len(breaches) == 0), breachesEverything in that envelope is an explicit, versioned rule that a compliance officer can read and approve. The optimiser then works inside it. A model never decides what is permitted; it decides how to allocate within what is permitted.
This is the same hybrid pattern as the credit module: the model produces a candidate, an explicit policy layer decides whether it is allowed. It is defensible for the same reason — you can explain the decision as policy, with the optimisation as one documented input.
The advice and execution separation
In India this is not a design preference, it is structural.
Under the SEBI investment adviser framework, advisory and distribution activities must be segregated at client level — and at group level for non-individual advisers. A SEBI circular dated 23 September 2020 established that an individual cannot provide advisory and execution services at the same time, which means an individual intending to run a robo-advisory platform must set up a separate entity, a company or an LLP.
The practical shape: the adviser recommends, the client authorises, and execution happens through brokers and asset managers. The adviser earns fees from the client and takes no commission from product manufacturers.
That separation is a conflict control, and it constrains the business model directly. If your revenue depends on which product the client buys, you cannot give advice about which product to buy. Many otherwise sensible product ideas fail on this point, and it is better to discover it before building than after.
Robo-specific expectations
- Algorithm testing for correctness and transparency — documented, repeatable, with results retained
- Qualified human oversight of algorithm output — a named person, not a policy
- Disclosure that advice comes from a system, and the extent of AI usage
- No commission conflicts in the recommendable universe
- Inspection readiness at all times
Registration as an RIA typically takes several months. Build that into the plan rather than discovering it at launch.
The registry
India — regulatory and market data
Verified May 2026Portfolio construction and analytics
Verified May 2026Platform and infrastructure
Verified May 2026Registry reflects what was publicly visible in May 2026. SEBI has been unusually active in this area — the AI accountability framework, finfluencer rules and adviser regulations have all moved recently. Verify the current position with a qualified securities lawyer before building on any of it.
A prompt for testing where your product sits
You are a securities lawyer who advises Indian fintech firms on
whether their product constitutes investment advice under the SEBI
Investment Advisers Regulations.
My product: [DESCRIBE WHAT IT SHOWS THE USER, IN DETAIL - the exact
screens, the exact wording, whether anything is personalised, and what
data you use to personalise it]
Assess:
1. Does this constitute investment advice, research analysis, or
neither? Reason through the specific features that push it either
way - do not give a general answer.
2. Which exact wording or feature is most likely to be the thing that
makes it advice, and what would have to change to move it out.
3. Whether any disclaimer could keep this on the education side, or
whether the substance decides regardless of labelling.
4. If it IS advice: what registration is required, what the fee model
must look like, and what the advice/execution segregation means
for my architecture.
5. What I must disclose about AI usage, and what human oversight of
algorithm output looks like in practice.
6. Three features I might add later that would silently cross the
line, so I can avoid designing toward them.
Be specific about which regulation or circular each point rests on,
and flag clearly where I must take formal legal advice rather than
rely on this.The education boundary in product design
Every wealth product drifts toward advice, because personalisation improves engagement and personalisation is what makes something advice.
The drift pattern
- Launch with general education. Clearly compliant.
- Add "popular funds" — still arguably general.
- Add "popular with investors like you" — now personalised.
- Add a risk quiz that outputs a suggested allocation — now advice.
- Add a one-tap buy button next to it — now advice plus execution, in one entity.
No single step feels like crossing a line. Step five is a different regulated business from step one.
Three tests worth applying to any screen
- Would this differ for another user? If yes, it is personalised.
- Could a reasonable person act on it directly? If yes, it influences a decision.
- Does it name a specific product? If yes, it is very hard to argue it is general.
The finfluencer enforcement is instructive on how seriously this is being taken. SEBI has drawn a hard line between education and advice, prohibited registered entities from paying or associating with unregistered finfluencers through money, referrals or data sharing, restricted use of stock price data less than three months old in educational content, and banned performance claims and return guarantees outright. A December 2025 order impounded ₹546 crore alongside a market ban.
LLMs in an advisory product
Generative models are genuinely useful here and the safe surface is narrower than teams expect.
PERMITTED - no recommendation crosses the boundary
Explaining a concept from approved material, with citations
Summarising a client's own portfolio for a human adviser
Drafting a review note for an adviser to edit and sign
Answering "what does expense ratio mean"
Translating an approved explanation into another language
Extracting structured facts from an uploaded statement
REQUIRES HUMAN SIGN-OFF BEFORE THE CLIENT SEES IT
Drafting the rationale for a recommendation
Explaining why an allocation changed
Client review commentary
PROHIBITED - do not build these
Generating the recommendation itself
Choosing products
Interpreting whether something is suitable
Answering "should I buy X"
Commenting on whether a specific holding is good
Any forward-looking statement about returns
THE TEST
If the output, read by a reasonable client, would influence a
specific investment decision, it is advice - regardless of
hedging language, disclaimers, or the fact that a model wrote it.
WHY NOT JUST PROMPT IT CAREFULLY
Non-determinism. The same question can produce a compliant answer
on Monday and a recommendation on Tuesday. Suitability obligations
do not tolerate a distribution of outcomes; they require a
reproducible, defensible decision with a named person behind it.The determinism argument
Worth stating plainly because it is the strongest reason, and it is not about model quality.
A suitability decision must be reproducible and defensible. If the same client, the same facts and the same portfolio can yield different reasoning on different days, you cannot evidence that the advice was suitable — only that it was generated. A generative model produces a distribution of outputs; a suitability obligation requires a decision.
That is why the recommendation itself comes from the deterministic envelope and optimiser, and the model only ever writes about a decision that has already been made and approved.
Monitoring what you have already advised
Advice is not a transaction, it is an ongoing relationship, and portfolios drift away from suitability without anyone doing anything.
| What drifts | Signal | Response |
|---|---|---|
| Allocation drift | Equity share moves outside the envelope through market movement alone | Rebalance, with tax and cost thresholds respected |
| Horizon shortening | A 2036 goal is now four years away — the horizon cap has tightened | De-risk on a glide path, automatically |
| Circumstance change | Job loss, illness, new dependant, inheritance | Re-run the fact find. Capacity may have changed materially. |
| Concentration creep | One holding grows past the single-name cap | Trim, unless there is a documented reason not to |
| Product change | Fund mandate, manager or expense ratio changes | Re-check the product still fits the envelope |
| Behavioural signal | Client panic-selling, or repeatedly overriding advice | Tolerance was measured wrong. Reprofile, do not just re-advise. |
The last row is the one automated systems miss. A client who overrides the recommendation three times has told you something about their real risk tolerance that no questionnaire captured. Treat repeated override as profiling evidence, not as user error.
Glide paths beat periodic reviews
An annual review catches horizon shortening a year late. A glide path that tightens the envelope continuously as the goal approaches catches it by construction, and it is easier to evidence because the rule is explicit rather than dependent on a review happening.
Disclosure, and what must actually be told
Disclosure obligations in Indian advisory are broader than most teams assume, and AI adds to them rather than replacing anything.
- Fees — transparent, disclosed up front, in rupees not just percentages
- Conflicts — any commission, any related party, any incentive
- That advice comes from a system, where it does
- The extent of AI usage — what role it plays in producing the advice
- Risks specific to the recommendation, not generic market warnings
- Accessibility — digital platforms of regulated entities are expected to meet accessibility obligations under the Rights of Persons with Disabilities Act
What an honest AI disclosure looks like
Not "we use AI to serve you better". Something a client can actually act on: which parts of the process are automated, which parts a qualified person reviews, what data the system uses, and what the client should do if they disagree with the output.
The accessibility obligation is routinely missed by fintech product teams and is a live expectation for regulated entities. It is also cheap to meet if designed in and expensive to retrofit.
The audit record, and where this module ends
{
"advice_id": "adv_01HYC...",
"client_ref": "cl_4412",
"given_at": "2026-05-23T12:30:00Z",
"adviser": {"ria_reg_no": "INA...", "reviewed_by": "adviser_09",
"reviewed_at": "2026-05-23T12:41:00Z"},
"fact_find": {
"version": "ff-v6", "completed_at": "...", "completeness": 1.0,
"monthly_income": 185000, "monthly_expenses": 96000,
"monthly_emi": 32000, "liquid_savings": 900000,
"dependants": 2, "health_insurance": true,
"income_stability": "salaried_regular"
},
"risk_profile": {
"capacity": 4, "capacity_basis": ["9.4_months_buffer", "surplus_31pct",
"insured", "stable_income"],
"tolerance": 3, "tolerance_source": "questionnaire_v4",
"required": 4, "horizon_years": 11,
"horizon_cap": 5,
"binding": 3,
"goal_is_unrealistic": true,
"goal_conversation_held": true,
"goal_adjusted_to": "extended_horizon_to_14y"
},
"envelope": {"version": "env-v7", "binding_risk": 3,
"equity_range": [0.30, 0.60], "max_single": 0.10},
"recommendation": {
"allocation": {"...": "..."},
"optimiser": {"method": "mean_variance_constrained", "version": "opt-3.1"},
"suitability_check": {"passed": true, "breaches": []},
"conflicts_checked": true, "commission_products_excluded": true
},
"ai_usage": {
"used_for": ["rationale_drafting", "portfolio_summary"],
"not_used_for": ["product_selection", "suitability_determination"],
"draft_edited_by_adviser": true,
"disclosed_to_client": true
},
"disclosure": {"fees_shown": true, "fee_amount_inr": 12000,
"conflicts_declared": [], "risk_warnings_shown": true,
"system_advice_disclosed": true},
"client_action": {"accepted": true, "authorised_execution_at": "...",
"executed_via": "broker_api", "overrides": []}
}Two fields do work the others do not. goal_is_unrealistic with goal_conversation_held records that the system refused to solve an unsuitable goal by taking more risk, and that the conversation happened. And ai_usage separates what AI did from what it did not — which is precisely the disclosure obligation, made evidenceable.
Where this module ends
- Client onboarding and KYC is Module 01. Securities onboarding adds its own requirements.
- Suitability for credit is a different obligation with different rules — Module 02.
- Client communications and complaints are Module 06, and advisory complaints have their own escalation path.
- Model validation, algorithm testing and documentation are Governance — and the algorithm testing expectation here is explicit rather than inferred.
- Jurisdictional detail is in the India and global regulatory spine pages. Note that SEBI, not RBI, is the regulator for this module.
Illustrative throughout. Investment advice is a registered activity and giving it without registration is an offence, not a compliance gap. Nothing here is legal or investment advice, and any product in this space needs formal advice from a qualified securities lawyer before launch.
Sources
Every figure, rule and date on this page, and where to check it. Entries are typed so you can see which are primary-sourced and which are industry reporting.
- officialSEBI (Investment Advisers) Regulations, 2013 and amendments — registration, the advice/distribution separation, and the prohibition on trading calls. www.sebi.gov.in
- officialSEBI guidelines for investment advisers — the fee cap, fee modes, and risk-profiling obligations. www.sebi.gov.in
- officialSEBI circular on AI/ML use by intermediaries — responsibility resting solely with the adviser, and the disclosure duty. www.sebi.gov.in
- officialSEBI finfluencer framework — the restrictions on association with unregistered persons. www.sebi.gov.in
Tooling, pricing and cost sources for this module are on its build sheet: sources →
Checked September 2026. Regulation in this area is actively developing; the date is part of the claim.
Ask an AI about this page
Opens your assistant with this page as the source, and a question rather than a summary. It will ask what you are building before it answers.
Nothing is sent from here. The link carries only this page’s title and address.