Reaching the demat, order and mutual-fund records held inside Angel One

India quietly turned the Account Aggregator network into a securities pipe in 2023, when SEBI-regulated entities and the depositories began joining as Financial Information Providers. That matters for Angel One. A demat account at a depository participant now sits inside a consent-based sharing rail that already carried bank data, which gives a clean, regulated way to read an investor's holdings without scraping a screen. More than 2.88 billion accounts were enabled to share over the network as of 31 March 2026, per the Department of Financial Services. For an integrator, the practical question is narrower: which Angel One surfaces hold the records you want, and which authorized route reaches them with the least breakage.

How the data is reached

Three routes apply to this app, and they are not equal. We name the one we would actually run, then keep the others as backstops.

Account Aggregator consent (the route we recommend)

Because depository and securities data now flows through the AA network, an investor's Angel One holdings can be requested as a consent artefact with a defined purpose, scope and validity window. This is the durable path: it is regulator-sanctioned, it survives front-end redesigns, and the consumer can revoke it. We set up the Financial Information User side of the flow and the consent UX with you during the build.

Authorized session analysis

Where a record lives only in the app's own portal — the detailed tax P&L, the sauda summary, granular ledger lines — we map the authenticated session a consenting account holder establishes and turn the relevant calls into documented, repeatable endpoints. The session is short-lived and second-factor gated, which shapes how the refresh is built rather than whether it works.

Consolidated statement and native export

The NSDL/CDSL Consolidated Account Statement, keyed on PAN, plus the app's own Excel/PDF report downloads, give a reconciliation source and a fallback. Useful for back-filling history and for cross-checking that a live feed matches the depository of record.

For most briefs we anchor on AA consent for holdings and positions, and fold in authorized session analysis only for the portal-only reports it cannot supply. That mix is regulated where it can be and pragmatic where it must be.

What sits behind the account

What you get back

The output is working code, not a slide deck. For Angel One that means:

• An OpenAPI/Swagger spec covering the holdings, order-book, ledger and P&L surfaces you choose, with field names normalised across equity, MF and SGB.
• Runnable source for the key endpoints in Python or Node.js, including the session establishment and token-refresh logic.
• A protocol and auth-flow report documenting the login, TOTP step and the auth/feed token chain as confirmed during the build.
• Automated tests against recorded responses, so a portal change surfaces as a failing test rather than a silent gap.
• Interface documentation plus consent and data-retention guidance keyed to the AA purpose you operate under.

On the wire

The authenticated session is the part most integrators underestimate, so here is the shape of it. Login takes a client code, a PIN and a time-based one-time code; the session it returns is valid only until midnight, which we account for in the refresh loop.

# Establish session — client code + PIN + TOTP (observed during build)
POST /rest/auth/.../user/v1/loginByPassword
{ "clientcode": "...", "password": "<pin>", "totp": "493021" }

-> 200 OK
{ "status": true,
  "data": { "jwtToken": "...", "refreshToken": "...", "feedToken": "..." } }

# Read holdings with the session token
GET /rest/secure/.../portfolio/v1/getAllHolding
Authorization: Bearer <jwtToken>

-> { "data": { "holdings": [
      { "tradingsymbol": "TATAMOTORS-EQ", "quantity": 40,
        "averageprice": 612.5, "ltp": 944.1, "profitandloss": 13264.0 } ] } }

# Session expires at 00:00 IST -> refresh routine re-auths each cycle

Error handling is mundane but load-bearing: expired tokens, a rejected TOTP window, and depository records that appear under one depository but not the other. The build treats each as a named failure path.

Consent and the regulatory frame

The governing rail here is the RBI Account Aggregator framework, launched 2 September 2021 under a Master Direction, with consent as the hard gate — no financial information moves without an explicit, purpose-bound artefact. Brokers and depositories participate as Financial Information Providers under SEBI's umbrella, so securities data shares the same consent plumbing as bank statements. Every consent we operate carries a stated purpose, a validity period, a fetch frequency, and a revocation path the holder controls. We log consent records, minimise the data pulled to what the purpose needs, and work under an NDA where the engagement calls for it. That is how the studio runs, not a checklist handed to you.

Engineering notes specific to Angel One

• Daily session expiry. The authenticated session lapses at midnight and is TOTP-gated. We build the refresh around that fixed expiry so an unattended sync re-establishes itself each cycle instead of caching a token that will be dead by morning; the second-factor access is arranged with the consenting holder at onboarding.
• Cross-depository reconciliation. Holdings consolidate on PAN, with the older depository as default consolidator. We reconcile securities that sit across NSDL and CDSL so the unified feed never double-counts a scrip or quietly drops one held in the other depository.
• Segment sprawl. Angel One spans equity, F&O, commodities, currency, bonds and direct mutual funds. We scope the schema per segment up front, because an order field that is meaningful for an MCX commodity contract is not the one that matters for an ELSS unit.
• Front-end drift. Portal-only reports change layout periodically. The recorded-response test suite is wired so a layout change shows up as a red test during maintenance, not as a data hole found weeks later.

Interface evidence

Screens from the store listing, used to map the surfaces above. Select to enlarge.

Comparable apps in the same ecosystem

A unified investment feed rarely stops at one broker. These neighbours hold the same shape of data and are common second integrations:

• Zerodha (Kite) — India's largest broker by active clients; demat holdings, order book and P&L behind a similar depository-participant account.
• Groww — stocks plus heavy direct mutual-fund and SIP holdings, popular with first-time investors.
• Upstox — discount broker with equity, F&O and MF positions in an authenticated portal.
• ICICI Direct — full-service broker tying demat data to a bank relationship.
• HDFC Sky — broking arm holding holdings, ledger and CAS-linked records.
• Motilal Oswal — full-service broker with research, advisory and portfolio data.
• Dhan — trader-focused platform with order history and positions data.
• m.Stock — Mirae Asset's broker app with demat and MF holdings.

Sources and how this was checked

Mapped on 27 June 2026 against Angel One's own support and knowledge-centre pages for the Portfolio, P&L, ledger and trade-history surfaces, the RBI/Government of India material on the Account Aggregator network, and NSDL's Consolidated Account Statement documentation. Primary references:

• Angel One — Profit & Loss statements
• Angel One — Portfolio user manual
• Dept. of Financial Services — Account Aggregator framework
• NSDL — Consolidated Account Statement

Compiled by the OpenBanking Studio integration desk · June 2026.

Questions integrators ask

Which Angel One records can be reached through a consented integration?

The demat holding statement (equity, bonds, SGBs, mutual-fund units), the order and trade book, ledger entries, and the detailed tax P&L. These map to the Portfolio and Reports areas of the app, and to the depository CAS held at NSDL and CDSL keyed on PAN.

Does the RBI Account Aggregator network cover securities data from a broker like Angel One?

Yes. Since 2023 entities regulated by SEBI, IRDAI and PFRDA joined the AA network as Financial Information Providers, so depository and securities holdings can be shared through a consent artefact alongside bank data. We design the consent scope, purpose and validity to match the data you actually need.

The Angel One session expires at midnight — how is an unattended sync kept alive?

The authenticated session is short-lived and TOTP-gated. We build the token-refresh routine around that daily expiry so the job re-establishes its session each cycle rather than caching a stale token, with access arranged with the consenting account holder during onboarding.

How are holdings reconciled when they sit across both NSDL and CDSL?

Consolidation in the Indian system is keyed on PAN, with the older depository acting as the default consolidator. We reconcile holdings that span both depositories so the unified feed neither double-counts a security nor drops one held in the other depository.

One way to take delivery: pay from $300 for the runnable source plus its spec, tests and docs, settled only after it lands and you have checked it works. The other: skip the build fee entirely and call our hosted endpoints, paying per call. Either way the cycle is one to two weeks, and either way you start by telling us the app and what you want out of it — tell us at /contact.html and we arrange the access and compliance side with you.