Wealth Elite holdings, mapped for advisor and platform integrations

The screen an investor sees inside Wealth Elite is white-labelled — the data behind it sits in a RedVision-hosted distributor portal, ticketed against a single ARN and reconciled with BSE StAR MF and NSE NMF II for the order side and with CAMS and KFintech for the position side. That tenancy boundary is the first thing any integration has to respect. Two investors with identical-looking apps from two different distributors are, in practice, two different data sources.

The bottom line is straightforward. For an integrator that already holds the investor's authorization — or, more often, sits on the distributor's side of the relationship — the data you would want from Wealth Elite splits cleanly into two halves: positions and statements, which are addressable through the Account Aggregator channel, and the in-app concepts (Goal GPS tags, Online ATM redemptions, the per-tenant onboarding state) that live only inside RedVision's portal. Our recommended path is to run both — AA for the durable, regulated half, and authorized interface integration for the in-app half — and reconcile them at the folio level.

What sits inside an investor's Wealth Elite account

Per the app's Play Store description and the wealthelite.in product copy, the surfaces that actually carry per-user records are these. Granularity is what the app exposes today; an integrator can usually normalize each row down further.

Four authorized routes into the data

Each of these is a real channel, sized to a different problem. We pick the route per surface, not per app — and on most engagements we run two together.

1. RBI Account Aggregator (consent-bound, regulated)

Mutual funds are Financial Information Providers in the RBI's NBFC-AA framework, and a consenting investor's folios — across both CAMS- and KFintech-serviced AMCs — flow as encrypted, data-blind packets through a licensed AA to a Financial Information User. Consent is purpose-limited, expiry-bound and revocable. This is the cleanest channel for positions, statements and transaction history; it does not carry the in-app Goal GPS tag or the Online ATM event class because those are not RTA-side data.

2. Authorized interface integration with the RedVision back-office

Working from the distributor's own authenticated portal — under their ARN, their consent, their NDA — we map the auth chain (OTP, token, cookie state) and the in-app endpoints that drive the screens the app actually renders. This is where the white-label, per-tenant detail lives: the goal mapping, the Online ATM cap, the mandate setup, the risk score. We arrange this access with the distributor as part of onboarding; it is not something the reader has to set up before talking to us.

3. RTA mailback and CAS parsing (cross-RTA consolidation)

Where AA enrolment is not yet in place for a particular AMC or where a historical view is needed, CAMS and KFintech still produce a Consolidated Account Statement on email request, and tools in the CASParser family will turn that PDF into structured JSON for all nine asset classes. We use this as a fallback or as a backfill behind the AA channel, never as the primary live source.

4. Native exports the investor can download

The app already lets a logged-in investor download Wealth and P&L reports. For a one-off or low-frequency need with a single investor in the loop, scripted ingestion of those exports is the smallest viable route, with a re-up cycle whenever the report layout shifts.

For most engagements we recommend route 1 for positions, statements and transactions, and route 2 alongside it for the in-app concepts the AA channel cannot see. Routes 3 and 4 stay in the bag for backfill and contingency, not as the primary feed.

The deliverables for this app

What you receive at the end of a Wealth Elite engagement, tied to the surfaces above:

• An OpenAPI 3.1 specification covering the resolved endpoints — investor login, holdings, transactions, mandate register, goal mapping, redemption submit — with response schemas matched to the table above.
• A protocol and auth-flow report: the OTP / token / cookie handshake the app uses against its RedVision tenant, with the failure modes named.
• Runnable source for the key endpoints in Python (httpx) and Node.js (undici / axios), with the AA-side flow stubbed against a licensed AA SDK of your choice.
• A normalized output schema (sample below) that flattens RTA-side and in-app fields into one folio-keyed structure your downstream code can consume without a per-source branch.
• Automated tests against a recorded fixture set, plus a contract test that runs against a live consenting account on a schedule you set.
• Interface documentation written for the engineer who picks it up after the build — auth chain, error catalogue, retry policy, AA consent template.
• A short compliance note covering ARN scoping, SEBI's investor-data expectations and the AA consent artefact you keep on file.

A normalized output shape

{
  "investor": { "pan": "AAAPL1234C", "arnTenant": "ARN-123456" },
  "asOn": "2026-05-19",
  "folios": [{
    "folioNumber": "9876543/00",
    "rta": "CAMS",
    "amc": "ICICI Prudential Mutual Fund",
    "scheme": {
      "name": "ICICI Prudential Bluechip Fund - Growth",
      "isin": "INF109K01480",
      "category": "EQ-LARGE-CAP"
    },
    "units": 1245.671,
    "nav": 96.42,
    "marketValue": 120125.85,
    "goalTag": "child-education-2034",
    "sip": { "amount": 5000, "frequency": "monthly", "nextDate": "2026-06-05" },
    "source": ["aa", "wealth-elite"]
  }]
}

An example of the auth and holdings call

Illustrative only — the exact field names and the OTP / cookie shape are confirmed during the build against the specific distributor tenant. The point is the shape: a per-tenant base URL, an OTP-then-token handshake, and a portfolio call keyed by an as-on date.

import httpx

ARN_TENANT  = "ARN-123456"        # distributor tenancy
INVESTOR_PAN = "AAAPL1234C"
TENANT_HOST = "app..wealthelite.in"

session = httpx.Client(
    base_url=f"https://{TENANT_HOST}",
    headers={"X-Tenant": ARN_TENANT},
    timeout=20,
)

# OTP request, then verify (the live chain has two more legs we map during the build)
ref = session.post("/auth/v1/otp/request",
                   json={"pan": INVESTOR_PAN}).json()["ref"]
auth = session.post("/auth/v1/otp/verify",
                    json={"otpRef": ref, "otp": "******"}).json()
session.headers["Authorization"] = f"Bearer {auth['accessToken']}"

holdings = session.get(
    "/portfolio/v2/holdings",
    params={"asOn": "2026-05-19"},
).json()

for folio in holdings["folios"]:
    print(folio["folioNumber"],
          folio["amc"], folio["scheme"]["name"],
          folio["units"], folio["nav"], folio["marketValue"])

Consent rails and the SEBI / AA picture

Two distinct regulators sit behind a Wealth Elite integration. SEBI regulates the instruments and the distributor: every transaction is booked under an ARN, KYC is anchored in CKYCR, and the distributor-investor relationship is on record. The RBI's NBFC-Account Aggregator framework governs the consent rail for sharing that financial data with a third party — AAs are licensed, data-blind intermediaries, and the consent artefact carries a purpose, a frequency, an expiry and a revocation hook.

The dependable basis for any integration we build is the consenting investor's or distributor's own authorization, captured in writing and logged. The AA channel is how that consent travels for holdings and statements; for the in-app concepts the distributor's authorization, scoped to one ARN, is what permits the interface integration. Data is minimized to the surfaces called out in scope, kept on encrypted storage, and retained only as long as the contract requires. NDAs are routine.

Things we account for on the build

• White-label tenancy. Every Wealth Elite install is keyed to one distributor's ARN; we partition the build per tenant from the first day, so two advisors on different RedVision tenancies do not bleed into a single dataset. The tenant id is a first-class field, not an environment variable.
• AA consent windows. A consent artefact has a fixed duration, a frequency cap and a revocation channel. We size the sync schedule against those numbers so the integration does not silently lapse mid-quarter; renewal nudges land in the consenting party's app on our side, not buried in a log.
• Online ATM is not a regular redemption. The Rs. 50,000 / 90% cap and the 30-minute target settlement are product behaviour, not API constants. We surface that as a distinct event type with the cap captured as metadata, so downstream cash-flow code does not treat it as a standard liquidation.
• RTA reconciliation. Holdings inside the app are RTA-mapped through CAMS and KFintech; we run a periodic diff against the consenting investor's CAS so a missed corporate action or a delayed dividend does not let the position drift quietly.
• Front-end churn. Wealth Elite is a vendor product on a release cadence — the auth chain tends to move first when a release ships. Our build contract carries a regression probe after each release window and a separate monitor on the login leg, so a UI change shows up as a flagged check, not a silent failure.

Other apps in the same Indian MFD pocket

For breadth, these are the apps a unified Indian mutual-fund integration usually touches alongside Wealth Elite. Naming them here is descriptive, not a ranking.

• Groww — direct-plan investor app holding folio holdings, SIPs and goal labels for a self-directed audience.
• Kuvera — direct-plan platform with strong goal planning and CAS-driven cross-RTA aggregation.
• Zerodha Coin — direct mutual funds living inside the Zerodha demat account, so positions land in the demat ledger.
• Paytm Money — combined SIP, equities and NPS folios under a single investor profile.
• ET Money — mutual funds, NPS and insurance under one onboarding flow.
• Scripbox — curated portfolio app with goal-tagged folios and a recommendation engine.
• AssetPlus Partner — distributor-side app, ARN-scoped book of clients, in the same shape as Wealth Elite.
• IFA-Planet — IFA back-office with BSE and NSE order rails wired in.
• theMFBox — back-office for distributors blending research overlays with the order side.
• Investwell Mint — cloud back-office for IFAs and RIAs, leaning analytics-first.
• JezzMoney — distributor software in the same competitive set.

Interface evidence

Screenshots from the Play Store listing, retained here as visual reference for the surfaces named above. Click to enlarge.

Questions integrators ask first

Is the data inside Wealth Elite the same across every distributor?

No. The app is white-labelled by RedVision and keyed to one distributor's ARN per tenant, so the folios, SIPs and Goal GPS tags a given login can see are the ones booked under that ARN. We build the integration per tenant and partition state at the ARN boundary.

Can the build use the Account Aggregator channel instead of touching the app's traffic?

Yes, for the holdings and statement side. Mutual funds are Financial Information Providers in the RBI AA framework, so a consenting investor's folios across CAMS- and KFintech-serviced AMCs can flow through an AA into the integrator's system without going through the Wealth Elite app at all. SIP mandates, redemption status and the Goal GPS tag are still in-app concepts and need authorized interface integration.

How is the Online ATM redemption represented in the output?

It is a distinct event type in our model — a same-day liquid-scheme redemption with a hard cap of Rs. 50,000 or 90% of the invested amount, whichever is smaller, per the product description. The 30-minute target settlement and the underlying liquid fund's NAV cut-off are kept as metadata so downstream cash-flow code does not mistake it for a standard redemption order.

What happens when RedVision ships a UI change to Wealth Elite?

The interface-integration path is the one that feels it. Our build contract carries a regression probe after each release window, and the auth chain is monitored separately because the login leg is what tends to move first. Where the AA path covers the surface (holdings, transactions, statements), the integration falls through to that channel while we patch the in-app capture.

What was checked, and when

For this brief we read the Wealth Elite product page on wealthelite.in and the matching feature page on the RedVision corporate site, the Play Store listing for com.redvision.wealth_elite (App Store id 1518518606 on iOS), the published BSE StAR MF web-services specification and the NSE NMF II API documentation pages, and reference material on the RBI Account Aggregator framework. Specifics that are not publicly disclosed — distributor counts, the exact in-app endpoint shape, the live auth chain — are noted as such in the body. OpenBanking Studio · integration desk, mapping reviewed 2026-05-19. Citations:

• wealthelite.in — Wealth Elite product page
• RedVision Technologies — Wealth Elite feature page
• BSE StAR MF — Web Services Structure (PDF)
• NSE NMF II — API Documents

From here it is straightforward. Send the Wealth Elite tenant you are working with and what you want to do with the data, and the rest — sandbox access on the RedVision side, AA enrolment, NDA, the consent template — is arranged with you during onboarding. Source-code delivery starts at $300: runnable code for the resolved endpoints, the OpenAPI specification, the auth-flow report and the test suite, paid only after delivery once you have taken the build and confirmed it works for your tenant. If hosting any of it is not where you want to spend time, call our hosted endpoints and pay only for the calls you make — no upfront fee, no minimum. The standard delivery cycle is one to two weeks. Reach the integration desk at /contact.html.