If you're building a robo-advisor in India, start with CAS, not Account Aggregator
Founders ask us this every week: AA or CAS for portfolio data? The honest answer, based on what wealth-tech teams are actually shipping in 2026, is to build on CAS first and add AA only where it pays off.
We get this question almost every week from founders building robo-advisors, portfolio trackers, and wealth-management platforms in India. Account Aggregator or CAS? Both, eventually? Which one first?
The default assumption for the last two years has been “AA, obviously, it’s the government-backed standard.” But when we look at what wealth-tech teams are actually shipping in 2026, a different pattern shows up: they build investment features on CAS, and they bring in AA only where AA genuinely solves something CAS can’t.
This post explains why, and where the lines fall. We’re not anti-AA. AA is excellent at what it covers. The point is that for an investment-focused product, AA’s gaps are bigger than most founders realize, and CAS gets you to a usable product faster, cheaper, and with broader coverage.
Where Account Aggregator actually shines
Let’s start with the case for AA. We’re not going to pretend it doesn’t have one.
If you need bank transaction data for credit underwriting, cash-flow analysis, or income verification, AA is the right answer and CAS can’t help you. CAS doesn’t cover bank accounts at all. The same goes for GST returns through the GSTN FIP, which is genuinely useful for MSME lending and B2B underwriting.
The other place AA wins cleanly is recurring data fetches with active consent. If your product needs automated monthly pulls without the user doing anything each time, that’s exactly what AA was built for. And for bank balances specifically, AA gets you closer to “real-time” than any document-based approach can.
If any of that describes your product, you’re building on AA. You can skip the rest of this post.
The gaps that bite wealth-tech specifically
For investment portfolio data, AA has a set of limitations that are documented but underdiscussed. These come from Sahamati and the RBI Master Direction, current as of early 2026.
The big one is joint accounts. Every bank in the AA network shows “not supported” for joint account discovery. AA requires individual consent, and no AA has built a multi-party consent mechanism. Joint demat accounts and joint MF folios are common in Indian households, so this is not a minor edge case. It’s a structural blind spot.
Then there’s the long “Proposed” list. Bonds, debentures, G-Secs, EPF, PPF have all been listed as “Proposed” since the framework launched. No FIPs provide that data today. If your customer base includes anyone with corporate bonds or government securities (which most HNI portfolios do), their portfolio will look incomplete through AA.
Depository transaction history through AA is capped at two years. So if you want to compute a clean XIRR on a five-year SIP, or reconstruct grandfathered LTCG cost basis from pre-2018 holdings, AA’s demat data doesn’t go back far enough. CAMS and KFintech CAS, by contrast, can pull mutual fund transaction history going back decades.
FIP fragmentation is a quieter problem but a real one. Not every FIP is on every AA. LIC, for example, is on exactly one AA (OneMoney). If your customer’s insurer or RTA isn’t connected to the AA they use, that data is invisible to you. You either route customers to specific AAs or accept partial data.
And then there’s the regulator question, which is where most founders hit a wall. Per the RBI Master Direction, only NBFCs, SEBI-registered advisors, IRDAI-licensed entities, or similar regulated participants can become FIUs. Pre-licensing startups, B2B SaaS vendors, and most international entrants simply can’t integrate AA directly. They need a regulated partner.
Add up the actual cost: Sahamati certification, the FIP-first mandate (you must publish your own data to consume), quarterly self-tests, biennial IS audits. Industry estimates put first-year AA implementation at â‚ą5-25 lakhs and 5-10 months of work. We covered the full breakdown in State of Account Aggregator in 2026.
None of this makes AA “wrong.” It makes AA a poor fit for one specific job: shipping comprehensive investment-data features in weeks rather than quarters.
What CAS gives you, and what it doesn’t
CAS PDFs are issued by the SEBI-regulated depositories (CDSL, NSDL) and RTAs (CAMS, KFintech). The format has been stable since 2009. Every Indian investor receives a CAS by email each month if there was activity, and on a half-yearly basis regardless.
Here’s what CAS covers cleanly for investment data: all demat holdings (including joint accounts, since the primary holder receives the statement); mutual fund folios across every AMC via CAMS and KFintech; corporate bonds, debentures, AIFs, REITs, InvITs, and SGBs held in demat form; insurance policies held in e-Insurance accounts; and NPS balances.
What CAS does not cover: bank accounts, real-time price updates, intraday positions. If your product needs those, CAS is the wrong primary source.
The cadence question is where founders sometimes get confused, so it’s worth being precise. CAMS and KFintech CAS contain lifetime mutual fund transaction history and can be generated on demand. CDSL and NSDL CAS are generated monthly — holdings are current as of statement date, but the transaction list is limited to the last month. Our CDSL Fetch endpoint retrieves the existing monthly CDSL statement programmatically via OTP; it doesn’t generate fresh data on demand. KFintech CAS Generator triggers an async email mailback. Neither is “real-time” in the AA sense.
Here’s the thing, though: for most robo-advisor use-cases, monthly is fine. Holdings are always current. MF transaction history is deeper than anything AA gives you. Demat transactions arrive at monthly cadence, which is plenty for asset allocation, tax-loss harvesting, and rebalancing. The cases where monthly is genuinely insufficient, like intraday tracking or active trading, are outside the typical robo-advisor scope.
The pattern we’re seeing
The architecture most wealth-tech teams are converging on looks like this.
For onboarding, they use CAS. The user signs up and shares their CAS once, through whichever path has the lowest friction for that user. Some users upload the PDF they already have in their inbox. Others forward the CAS email to a unique inbound address (ie_xxx@import.casparser.in) that the SDK provisions per user. Others connect Gmail via OAuth and let the SDK pull CAS files from the inbox automatically. Whichever path the user takes, the result is one parsed JSON response with their demat accounts, MF folios, bonds, insurance, and NPS. No regulator approval required to call the API.
For ongoing refresh, most teams set up the per-user inbound email address at signup and let it sit there. The next monthly CAS lands automatically. The SDK parses it and posts to the platform’s webhook. The user does nothing. For CDSL-only refresh on demand, CDSL Fetch handles it via OTP. The user receives the OTP on their registered mobile and submits it once per fetch.
Where AA enters the picture is for the things CAS genuinely doesn’t do. If the product needs bank account data (cash positions, SIP debit tracking, income verification), that’s where AA earns its place. The teams doing this well request AA consent only for bank FIPs and keep investment data on CAS. That keeps the AA implementation scope small enough to not block product launches.
The split, in table form:
| What you need | Where you get it |
|---|---|
| Demat holdings (incl. joint accounts) | CAS |
| MF folios with full transaction history | CAS |
| Bonds, debentures, AIFs | CAS |
| Insurance held in demat | CAS |
| NPS | CAS or AA |
| Bank balances and statements | AA |
| GST returns | AA |
| Real-time MF NAV | Market data API |
This split lets you ship investment features in weeks. AA gets pulled in later, with the regulatory work timed to a specific business need rather than blocking your launch.
When CAS-first is the wrong call
A few situations where this pattern doesn’t apply, and we want to be clear about them.
If you’re building a lender, you need bank statements, not portfolio holdings. AA is your primary integration and CAS is barely relevant. Same goes if your product depends on intraday data. Neither CAS nor AA gives you tick-level prices; you need broker APIs or market data feeds.
If you already have AA in production and it serves your existing use-case well, switching wholesale doesn’t make sense. The thing worth doing is adding CAS as a fallback layer to cover joint accounts and bonds, which AA still doesn’t handle.
And if your users are brand-new investors who just opened their first demat, they won’t have meaningful CAS data yet. For first-month users, you’ll need direct broker integrations or you wait for the first statement. This is the one case where CAS-first genuinely doesn’t work, and we mention it because we’ve seen teams not account for it.
What integration actually looks like
For the onboarding flow, the Portfolio Connect SDK does the UI work:
import PortfolioConnect from '@cas-parser/connect';
<PortfolioConnect
accessToken={accessToken}
enableInboundEmail={true}
enableInbox={true}
enableCdslFetch={true}
onSuccess={(result) => {
// result.investor, result.summary,
// result.demat_accounts, result.mutual_funds,
// result.insurance, result.nps
savePortfolio(result);
}}
/>The accessToken is a short-lived token (at_ prefix) generated from your backend via POST /v1/token. Never expose your raw API key to the browser.
For the monthly refresh, create a per-user inbound email at signup and store it:
curl -X POST https://api.casparser.in/v4/inbound-email \
-H "x-api-key: $CASPARSER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"callback_url": "https://yourapp.com/webhooks/casparser",
"alias": "user-42"
}'The user forwards future CAS emails to the returned address. Each parsed CAS is POSTed to your webhook. If you’d rather pull than receive, polling is available via GET /v4/inbound-email/{id}/files.
AA integration is TSP-dependent (Setu, Finvu, OneMoney, and others) and out of scope for this post. The point is that you can build the whole investment portfolio experience without AA, and bring AA in when banking data becomes a product requirement, not before.
The honest cost and timeline comparison
For the investment-data portion of your stack:
| AA-first for investment data | CAS-first | |
|---|---|---|
| Regulator approval needed | Yes (NBFC, SEBI, IRDAI, or PFRDA) | No |
| Sahamati certification | Required | Not applicable |
| Time to live | 5-10 months (industry estimate) | Days to weeks |
| First-year cost | â‚ą5-25 lakhs+ | API credits plus integration eng. CASParser plans start at â‚ą999/month |
| Joint accounts | Not supported | Included via primary holder |
| Bonds, AIFs, debentures | ”Proposed,” not live | Included |
| Demat transaction history | 2 years | Up to 50+ years for MF via CAMS/KFintech |
| Usable without an AA handle | No | Yes |
These numbers come from the State of Account Aggregator in 2026 post, which is sourced from Sahamati and the RBI Master Direction.
The pragmatic call
If your product is investment-focused (robo-advisor, portfolio tracker, wealth-management dashboard, financial planning tool), the order we recommend is:
Build investment data on CAS. You can be live this week. Validate the product with real users. Add AA later, only if and when you need bank data, lending workflows, or GST returns.
If your product is bank-data-focused (lending, neobank, expense tracking), flip the order. AA first, CAS only if you also need investment data.
The mental model worth letting go of is that AA is the “modern” answer and CAS is the “legacy” one. They solve different problems. For comprehensive investment portfolio data in 2026, CAS is genuinely the faster and more complete option for most teams, and it’s the path we’d suggest for anyone starting fresh.
Want to try CAS-first? Get a CASParser API key (production keys are free on signup), or explore the Portfolio Connect SDK. For a deeper look at the AA ecosystem, read State of Account Aggregator in 2026.