Getting a consenting user's holdings out of Kotak Cherry

Open Cherry's “Import your Mutual Funds” flow and the app reconciles folios bought anywhere — across roughly 2,500 schemes, as its Play and Kotak listings describe it — into one tracked book. That imported-and-native consolidated view is the asset an integrator actually wants from this app: a single investor's entire mutual-fund position, the SIP and SWP mandates feeding it, and the per-fund health flags Cherry computes on top. Kotak Cherry is published by Kotak Mahindra Bank Ltd (package com.kotakcherry.app per its Play listing), so the data sits behind a bank-grade login with a second factor. The route to it is consent, not scraping a password.

Behind a Cherry login

Each row below is a surface the app actually exposes to a logged-in investor, where the value originates, how fine-grained it is, and what a third party does with it once normalized.

Authorized routes to the holdings

Four routes apply here. They differ in what they reach, how long they hold up, and what we stand up to run them.

1 — Account Aggregator consent (RBI / SEBI)

India's consent-driven data network is the right spine for the core position. A 2022 SEBI circular brought asset management companies and depositories into the AA framework as Financial Information Providers through their registrars, so a consenting investor's mutual-fund and demat holdings flow under an explicit, time-boxed consent — whatever app they happened to buy through. Reach: holdings and transactions. Durability: high, because the FI schema is standardized and the source is the registrar, not Cherry's front end. We handle the AA/TSP onboarding with you so the build talks to a live consent.

2 — Authorized interface integration

Cherry's own client-server traffic carries everything the screens show, including the things AA never will: the Portfolio Health verdict, basket definitions, and the analysis figures before they are flattened into a PDF. We map the login and token chain, including the Cherry PIN second factor, against a consenting account. Reach: full app surface. Durability: medium — front-end revisions need a re-validation pass, which we account for in maintenance.

3 — User-consented registrar fetch (MF Central)

MF Central, run jointly by KFintech and CAMS with AMFI, returns a consolidated holdings and transaction picture against a PAN and an OTP. It is a clean fallback for the cross-AMC book when an AA pipe is not yet provisioned, and it is registrar-backed so the numbers reconcile with route 1.

4 — Native export

Cherry's downloadable Portfolio Analysis PDF and the emailed consolidated account statement are parse-only inputs. Useful for a one-off reconciliation; not a feed.

What we would actually build: route 1 as the standing source for holdings and transactions, route 2 layered on for the Cherry-computed analytics, with route 3 kept as the reconciliation check. That split keeps the durable data on the regulated rail and isolates the brittle part to a small, well-understood surface.

What you receive

Concrete artifacts, scoped to Cherry's real surfaces:

• An OpenAPI 3 specification covering the holdings, mandate and transaction reads, plus the AA consent lifecycle as it applies to mutual-fund FIPs.
• A protocol and auth-flow report: the Kotak login, the Cherry PIN factor, token issue and refresh, and the consent-handle exchange on the AA side.
• Runnable source for the key endpoints in Python and Node.js — consent request, FI fetch, folio and mandate normalization, transaction pagination.
• Automated tests against recorded fixtures, including the de-duplication of imported-vs-native folios.
• Interface documentation and a data-retention note keyed to SEBI/AMFI distributor conduct and the DPDP Act, 2023.

A holdings pull, sketched

Illustrative, not a transcript — field names and the exact handshake are confirmed during the build against a consenting account. The shape below shows the AA consent then a normalized folio read.

# 1. Request an AA consent for this investor (mutual-fund + depository FI types)
POST /aa/consent
{
  "fiTypes": ["MUTUAL_FUNDS", "EQUITIES"],
  "purpose": "wealth aggregation (consent code 101)",
  "fetchType": "PERIODIC",
  "frequency": {"unit": "MONTH", "value": 1},
  "consentExpiry": "2027-05-19T00:00:00Z"
}
-> 202 { "consentHandle": "c-9f3a...", "status": "PENDING" }   # user approves in their AA app

# 2. After approval, fetch financial information
POST /aa/fi/fetch  { "consentId": "ci-77b2...", "sessionId": "s-41e0..." }

# 3. Normalize the registrar payload to one folio record
{
  "investor": { "panMasked": "ABptated-by-build" },
  "folios": [
    { "amc": "Kotak Mahindra MF", "scheme": "Equity Hybrid - Direct - Growth",
      "folioNo": "910xxxx", "units": 1843.221, "nav": 41.86,
      "currentValue": 77152.30, "source": "registrar" }
  ],
  "mandates": [
    { "type": "SIP", "scheme": "...", "amount": 5000,
      "frequency": "MONTHLY", "nextDebit": "2026-06-05", "status": "ACTIVE" }
  ]
}

# Route 2 only: Cherry-computed signals the AA feed never carries
GET /cherry/portfolio/health   -> { "fund": "...", "verdict": "MONITOR" }
# 401 -> re-establish session, replay Cherry PIN factor, retry once
      

Consent under the AA framework and SEBI's rules

This is an Indian financial app, so the basis for every read is the investor's own consent, captured and logged. The RBI NBFC-Account Aggregator Master Direction defines the consent-manager model: no financial information moves without an explicit, scoped, revocable consent artifact. SEBI's 2022 circular is what makes mutual-fund and demat data reachable on that network at all — it lets asset managers and depositories act as Financial Information Providers through their registrars. On the distribution side, SEBI and AMFI conduct rules make client consent and consent record-keeping mandatory for anyone handling an investor's holdings, and India's Digital Personal Data Protection Act, 2023 frames retention and minimization. We operate inside that: authorized access only, consent and access logs kept, only the fields the use case needs, and an NDA where the engagement calls for one.

Quirks we plan around

Two things about Cherry specifically that the integration has to account for, and how we handle each:

• Imported vs native folios double-count. Because Cherry's External Portfolio Import pulls in holdings the investor also transacts on natively, the same folio can appear twice. We de-duplicate on AMC plus folio number plus scheme code so the unified ledger reflects one true position, not an inflated one.
• The Cherry PIN sits on top of the Kotak login. It is a second factor with its own timeout. We design the session handler so an unattended periodic sync re-establishes that factor cleanly and backs off rather than tripping a lockout on the user's real account.
• AA consents are scoped and they expire. The consent carries FI types, a purpose code, a fetch cadence and an expiry. We build the pull around that validity window so it renews ahead of lapse instead of failing silently mid-month.
• The analysis arrives as a PDF. Portfolio Analysis is a document, not a feed. We parse it into structured fields and reconcile those against the per-folio read so the machine summary matches what the investor sees on screen.

Where teams put this data

• A net-worth or wealth dashboard ingesting a client's full mutual-fund book nightly over AA, normalized to one schema alongside other accounts.
• An advisory tool that reads Cherry's Portfolio Health verdicts to open review tasks only for funds flagged Immediate Action.
• A rebalancer that reconciles active SIP/SWP mandates so it knows committed monthly cashflow before it proposes changes.
• A tax or bookkeeping pipeline pulling the full transaction stream for capital-gains computation at year end.

Keeping the sync honest over time

Mutual-fund NAVs post once a day, so we time the registrar pull after NAV publication and valuations are never a day stale. Ingestion is idempotent, keyed on folio plus transaction id, so a re-run never duplicates a buy. When Cherry revises its app, route 2 is the only part that can drift; a scheduled re-validation pass catches an interface change and flags it before the data goes wrong rather than after.

Screens we worked from

Published store screenshots used while mapping the surfaces above.

What we checked, and where it came from

Surfaces were read from Kotak Cherry's store and product pages; the regulatory path was traced from SEBI's own circular, the Sahamati AA reference material, and the MF Central registrar service, in May 2026. Primary sources opened:

• SEBI circular — SEBI entities as Financial Information Providers in the AA framework (Aug 2022)
• Sahamati — Account Aggregator framework FAQ
• MF Central — KFintech and CAMS consolidated mutual-fund services
• Kotak — Kotak Cherry product page

Mapped by the OpenBanking Studio integration desk · May 2026.

Other India MF apps in the same orbit

Same data shape, same regulated network — useful context for anyone unifying a market across providers, not a ranking.

• Groww — broad retail platform holding mutual-fund folios, stocks and SIPs behind one login; the same registrar-backed holdings reachable via AA.
• Zerodha Coin — direct-plan mutual-fund holdings tied to a Zerodha demat account, so positions surface on both the depository and registrar legs.
• Kuvera — zero-commission direct plans with goal tracking; per-goal folio and SIP records.
• ET Money — mutual funds alongside NPS and insurance, with consolidated portfolio and transaction history.
• Paytm Money — SIP-tracked low-cost investing with order and mandate data behind an authenticated account.
• Scripbox — advisory-led fund portfolios with goal-mapped holdings and recommendations.
• INDmoney — family net-worth aggregation that itself consumes the AA network for holdings.
• MFCentral — the KFintech/CAMS registrar app; the upstream consolidated source the others reconcile against.

Questions integrators ask about Cherry

Does the Account Aggregator route carry folios a user imported from outside Kotak, or only Kotak-held funds?

It carries them. Under the AA framework, mutual-fund and demat holdings are shared by the asset managers and depositories through their registrars, so a folio bought anywhere shows up at the registrar layer regardless of where the user transacts. Cherry-only signals such as the Portfolio Health flags and the curated baskets are not part of that feed and come from the authorized interface route instead.

Can the extract tell a SIP or SWP mandate apart from a one-off purchase?

Yes. Transaction records carry the type and the mandate metadata, so recurring Aspire mandates, lump-sum buys, switches and redemptions arrive as separate, labelled streams with amount, units, NAV and date.

Which Indian rules govern sharing this data?

Consent is the basis. The RBI NBFC-Account Aggregator Master Direction sets the consent-manager model; a 2022 SEBI circular brought asset managers and depositories in as Financial Information Providers through their registrars; SEBI and AMFI distributor conduct rules together with India's Digital Personal Data Protection Act, 2023 shape what may be retained and for how long.

Is this a per-user consented pull, or can it run as one bulk feed across many investors?

It is per investor by design. Each person grants an AA consent or an authorized session against their own Cherry account; a portfolio-wide feed is simply many such consents collected through your own onboarding, which we wire up with you as part of the build.

Pricing stays plain. Source-code delivery starts at $300, billed only after we hand over the runnable integration and you are satisfied with it; or skip the build and call our hosted endpoints instead, paying per call with nothing upfront. Most Cherry builds close inside one to two weeks. Tell us the app and what you want out of its data at our contact page and we will scope the route with you — access and compliance are arranged together as part of that.