Getting a consenting Dhanush account's holdings into your own platform

Where the regulated route actually goes

Ashika Stock Broking Limited runs Dhanush on India's depository rails, and that detail decides the cleanest way in. The app's own listing states a SEBI broking registration of INZ000169130; Ashika is also a depository participant, per SEBI's DP register references. The securities a user holds therefore sit in a CDSL or NSDL demat account, not only inside the app. That matters because SEBI's circular SEBI/HO/MRD/DCAP/P/CIR/2022/110, dated 19 August 2022, lets depositories act as Financial Information Providers in the RBI Account Aggregator network.

So the holdings half of this integration has a regulated, consent-based path that does not depend on the app at all. The order book, the IPO application tracker, the SIP schedule and the watchlists do depend on the app, and those we reach by authorized interface work. The page below splits the job along exactly that line.

What sits behind a Dhanush login

These are the surfaces the app exposes once a user is signed in, named the way Dhanush and Ashika name them. Granularity is what an integrator can realistically expect per record.

Three ways into a Dhanush account's records

1 · RBI Account Aggregator, securities FIP

A consenting investor's depository holdings, securities profile and transaction history move from the CDSL or NSDL FIP, through an RBI-licensed Account Aggregator, to a regulated Financial Information User. The data is encrypted end to end and the AA never reads it. Reach: holdings and securities transactions, not the app-only surfaces. Effort is moderate; durability is high because the schema is regulator-defined and stable. We set up the AA partner, the consent template and the FIU routing with you as part of the build.

2 · Authorized interface integration

For the records that live only in the product — IPO application and allotment status, SIP schedules, intraday positions, margin, pinned watchlists and alerts — we analyse the Dhanush app and web traffic under your authorization, against a consenting account, and reconstruct the request and response contract. Effort is higher; durability is medium because a front-end release can shift payloads. A periodic re-capture step that we own catches those shifts before they reach your feed.

3 · Native export

Ashika already issues contract notes, ledgers and P&L statements to investors. Where a static, point-in-time pull is enough, we parse those documents. Lowest effort, lowest freshness — useful as a backfill, not as a live feed.

For most teams the sensible shape is route 1 carrying holdings and transactions as the durable backbone, with route 2 filling the IPO, SIP, watchlist and intraday gaps the regulated path does not cover. Route 3 fills history that predates consent. We will say which split fits once we see what you need the data for.

What lands in your repository

Concrete artefacts, each tied to a Dhanush surface above:

• An OpenAPI / Swagger specification covering the holdings, positions, order-book, P&L, MF/SIP and IPO-status calls as a single normalized contract.
• A protocol and auth-flow report: the login, token issue and refresh chain the app uses, and the AA consent-artefact handshake on the regulated leg.
• Runnable source for the key endpoints in Python or Node.js — a client that authenticates, fetches and normalizes each domain.
• Automated tests against recorded fixtures, so a behaviour change is caught rather than discovered in production.
• Interface documentation: field-level notes, exchange/segment tagging rules, error and rate behaviour.
• Compliance and retention guidance covering consent records, audit logs and data minimization for the AA leg.

A holdings-and-IPO pull, sketched

Illustrative only — field names and the exact handshake are confirmed during the build, not asserted here. It shows how the two legs sit side by side: a consent-bound depository fetch and an app-session call for what the depository does not carry.

# Leg A — depository holdings via Account Aggregator (consent-bound)
consent = aa.fetch_consent(handle=CONSENT_HANDLE)        # SEBI FIP: CDSL/NSDL
assert consent.status == "ACTIVE" and consent.purpose_ok

fi = aa.fetch_financial_information(
        session=consent.session_id,
        fi_types=["EQUITIES", "MUTUAL_FUNDS"])           # securities scope
holdings = normalize_depository(fi)                      # -> [{isin, qty, avg, val}]

# Leg B — app-only surface (authorized interface work, consenting account)
tok = dhanush_login(refresh_token=RT)                    # token chain per build
ipos = http.get("/v1/ipo/applications",
                 headers={"Authorization": "Bearer " + tok.access})
# {"applications":[{"symbol","applied_qty","cutoff","status":"ALLOTTED|..."}]}

feed = merge(holdings, ipos, key="account_ref")          # one client view
        

What we handle on the Ashika stack

Engineering judgments we account for so you do not have to:

• Two depositories, one model. An Ashika demat account may sit with CDSL or NSDL, and the holdings payload differs subtly between the two FIPs. We normalize both into one schema before anything reaches you.
• Multi-exchange, multi-segment tagging. Ashika's disclosed segments cover cash, F&O, currency and commodity across NSE, BSE, MSEI, MCX and NCDEX. Every order and position row is stamped with its exchange and segment so an aggregate view never conflates an equity trade with a commodity one.
• Consent windows. An AA consent carries an explicit purpose, validity and revocation. We design the sync cadence to renew inside the consent's fetch window so a long-running integration does not quietly fall out of consent, and we retain the consent artefact and audit log with each pull.
• App-release drift. Access and the consenting test account are arranged with you during onboarding; from there the build runs against that account or an AA sandbox, and a scheduled re-capture flags a Dhanush release that shifts the request shape before it affects your data.

Where teams put this data

• A wealth dashboard that merges a client's Dhanush demat holdings with bank and MF data into one net-worth view, on the consented AA leg.
• An advisory tool that reads SIP schedules and MF folios to flag drift from a target allocation.
• A tax and reporting workflow that reconstructs realised P&L and contract notes for a financial-year filing.
• An internal risk monitor mirroring intraday positions and margin used for exposure alerts.

Screens this mapping was checked against

Public store screenshots used to confirm the surfaces named above. Tap to enlarge.

Other Indian broker apps in the same data picture

Neutral context. A team integrating Dhanush often wants the same shape from peer apps, and the depository and AA backbone is common to all of them.

• Zerodha (Kite) — large discount broker; holdings, positions and order book behind a single trading account.
• Upstox — equities, F&O and MF records under one login, same depository backing.
• Groww — started in mutual funds, now stocks too; folio, SIP and holdings data.
• Angel One — full-service broker with research, holdings and advisory data.
• Dhan — trader-focused; positions, order book and option data.
• Rupeezy — option-trader oriented; watchlists and technical-indicator state.
• HDFC Securities — bank-linked full-service broker; integrated demat and banking data.
• ICICI Direct — bank-linked broking with portfolio and SIP records.
• Paytm Money — stocks, MF and IPO records under a consumer wallet account.

Questions integrators ask about Dhanush

Can the demat holdings come through the Account Aggregator route, or does that need app-side work?

Securities holdings and the transaction history sitting in the depository can move through the regulated Account Aggregator path, because the depository acts as the Financial Information Provider for the securities market. The records that live only inside the Dhanush product — IPO application and allotment status, the SIP schedule, pinned watchlists, intraday positions and margin used — are reached through authorized interface work against the app's own traffic. Most builds we do for a broker app this shape combine both legs.

Which regulator and scheme govern the consented data path for an Ashika account?

SEBI governs the securities and broking side; the RBI licenses the NBFC-Account Aggregator that carries the consent and the encrypted data. SEBI's circular SEBI/HO/MRD/DCAP/P/CIR/2022/110, dated 19 August 2022, is the instrument that brought depositories in as Financial Information Providers, so a consenting investor's depository holdings can be shared with a regulated Financial Information User.

Does Dhanush's NSE, BSE, MCX and NCDEX coverage change the schema you hand over?

Yes. Ashika's disclosed segments span cash, F&O, currency and commodity, so order, trade and position rows are not uniform. We tag every row with its exchange and segment and normalize equity, derivative and commodity records into one model, so an aggregate P&L or exposure view downstream does not mix instrument types.

We hold an Ashika demat login but have no Account Aggregator setup yet — what can you map first?

The app name and what you want from its data is enough to begin. We can start mapping the in-app surfaces straight away against a consenting account, and bring the Account Aggregator leg up in parallel; the AA partner selection and consent flow are arranged with you during onboarding rather than asked of you first.

What was checked, and when

This mapping rests on Ashika's own product and regulatory disclosures, the Play Store listing for package com.rs.ashika, and SEBI's circular plus depository material on Financial Information Provider participation. The app's surfaces were cross-checked against its public store screenshots. Identifiers such as the SEBI registration are reported as the operator states them, not independently certified here. Reviewed 18 May 2026 by the OpenBanking Studio integration desk.

Primary sources opened:

• SEBI circular — participation as Financial Information Providers in the Account Aggregator framework (19 Aug 2022)
• Sahamati — depositories live as FIP on Account Aggregator
• CDSL — Financial Information Provider information
• Google Play — Dhanush: Demat, Stocks & IPOs listing