What a Navi account holds, and the consented way to reach it

One Navi login crosses four regulators at once. UPI sits under the RBI through NPCI; the mutual fund folios answer to SEBI; the health and motor policies answer to the IRDAI; and a consenting user can route the asset-side records out through the RBI's Account Aggregator rail. That spread is the whole integration problem in one sentence: a single account holds payment flows, investment holdings, a gold ledger, and insurance contracts, and no two of them are reached the same way.

Navi Limited (formerly Navi Technologies Limited) was founded by Sachin Bansal and Ankit Agarwal in December 2018, per its Play Store listing and the Navi Group entry. The bottom line for an integrator: the cleanest, most durable pull is the consented Account Aggregator route for folios and policies, paired with authorized interface work against a live session for the UPI passbook and digital-gold lots that the AA rail does not carry. The rest of this page is how those two halves fit together.

Consent, and the rail this data rides

India already has a regulated answer for moving someone's financial data with their permission: the Account Aggregator framework, run under the RBI as a class of NBFC-AA consent managers. It went commercially live in September 2021. A licensed Account Aggregator sits between a Financial Information Provider that holds the data and a Financial Information User that wants it, and moves nothing without the holder's explicit, revocable consent. The government's own framework page describes the FIP/FIU/AA split and the consent-artefact model.

For Navi this matters because the asset-side entities are exactly the kind the rail was built around. Navi Mutual Fund is a SEBI-registered AMC; Navi General Insurance is an IRDAI-registered general insurer, per the Navi Group record. Both classes — AMCs and insurers — are named FIP categories. So a consenting Navi customer can authorise a folio-and-policy pull through an AA without anyone touching a password. Consent there is scoped, time-boxed, and revocable, and every fetch is logged against a consent ID. What the AA rail does not yet carry is granular UPI transaction history; the framework's live data set is asset-based. We treat that gap as a design fact, not a surprise.

What sits behind a Navi login

Six domains, each with its own origin inside the app and its own granularity. The figures below are as the app describes itself on its listing.

Getting to the data: the routes that apply

Consented Account Aggregator pull

This reaches the asset side cleanly: mutual fund folios, insurance policies, and any deposit accounts the user holds. The customer approves a consent artefact through a licensed AA; the FIU receives a structured, contract-defined response. Effort is moderate and front-loaded into onboarding the AA connection. Durability is high — the schema is defined by the rail, not by Navi's UI, so it does not move when the app reskins. We set up the AA/FIU side and the consent handling with you.

Authorized interface work against a live session

The UPI passbook and the Navi Gold ledger are not on the AA rail, so we read them the way the app does: by analysing the authenticated session of a consenting account and replaying the same calls. This covers per-transaction UPI history, Lite spends, and gold lots. Effort is higher and the surface can shift with app updates, which is why we wrap it in re-validation. Access is arranged with you during onboarding, against a consenting account.

Native export as a backstop

Where Navi exposes a statement or passbook download for the user, that file is a low-effort reconciliation source and a useful cross-check against the session pull. It is periodic rather than real-time, so it backs up the live route rather than replacing it.

For most Navi briefs the sensible build runs the consented AA connection for folios and policies and reserves authorized session work for the UPI and gold ledgers the rail omits — the two together cover the account, and each carries the half the other cannot. Which one leads depends on what you actually need: a net-worth product leans on the AA pull, a spend-analytics product leans on the UPI session.

A statement pull, end to end

Illustrative shape only — exact paths and field names are confirmed during the build against a consenting account, not asserted here. It shows the two halves side by side: an AA-mediated holdings fetch and a session-mediated UPI passbook read.

# 1) Asset side — consented, via a licensed Account Aggregator (FIU role)
POST https://<aa-gateway>/v2/FI/fetch
Authorization: Bearer <fiu_token>
{
  "consentId": "a7c1...",            # scoped + revocable, logged
  "sessionId": "f93d...",
  "fiTypes": ["MUTUAL_FUNDS", "INSURANCE_POLICIES"]
}
# -> per-folio units, NAV date, scheme code; per-policy sum insured, renewal

# 2) Payment side — authorized session read of the Navi UPI passbook
GET https://<navi-session-host>/upi/passbook?from=2026-04-01&cursor=<next>
Authorization: Bearer <session_token>      # device + SIM bound; refreshed
X-Device-Id: <bound_device>

def normalize(txn):
    return {
        "id": txn["utr"],
        "ts": txn["txnTime"],
        "amount_inr": txn["amount"],
        "direction": "debit" if txn["drcr"] == "D" else "credit",
        "rail": "UPI_LITE" if txn.get("lite") else "UPI",
        "counterparty_vpa": txn.get("payeeVpa"),
    }

# Error handling that actually matters here:
#   401 -> session token expired: refresh against device binding, retry once
#   409 -> consent revoked or expired: stop, surface to user, do not retry
#   429 -> back off; NPCI-side rate limits apply to passbook reads

The shape we normalize to

Four product lines do not belong in one flat table. We hand over typed objects, each keyed so a snapshot is unambiguous in time.

{
  "holding": {
    "type": "MUTUAL_FUND",
    "scheme": "Navi Nifty 50 Index Fund - Direct Growth",
    "units": 184.226,
    "nav_date": "2026-06-26",      # NAV cutoff matters; same-day NAV before 3pm IST
    "invested_inr": 20000,
    "current_inr": 21934.5
  },
  "gold_lot": { "type": "DIGITAL_GOLD_24K", "grams": 1.842, "bought_inr": 50 },
  "policy": { "type": "HEALTH", "insurer": "Navi General Insurance",
              "renewal": "2027-02-11", "claim_status": "none" }
}

What lands in your repository

• An OpenAPI/Swagger spec covering the normalized endpoints — UPI passbook, MF holdings, gold lots, insurance policies, loan accounts — with request/response models.
• A protocol and auth-flow report: the AA consent-artefact flow on the asset side, and the device/SIM-bound token and refresh chain on the session side, written up with the failure modes.
• Runnable source for the key reads in Python or Node.js — the holdings fetch, the passbook pagination, and the normalizer above — not pseudo-code.
• Automated tests, including the consent-expiry (409) and token-refresh (401) paths, because those are where a long-running Navi sync actually breaks.
• Interface documentation a second engineer can follow, plus data-retention and consent-record guidance aligned to the DPDP Act and the AA logging model.

Things we account for on a Navi build

These are the app-specific details that make or break the integration. We carry them; they are not a checklist for you.

• The AA covers assets, not the UPI ledger. The rail returns folios and policies but not granular UPI history, so we split the build cleanly: a consented AA pull for the asset side, authorized session work for the passbook and gold lots. One pipeline, two sources, reconciled.
• UPI Lite settles differently. Lite is NPCI's low-value, PIN-free balance, and small spends can clear on-device and reconcile to the main passbook later. We model the Lite balance as its own stream so the synced ledger neither double-counts nor drops those transactions.
• NAV date is the truth for holdings. Navi advertises same-day NAV for orders placed before the 3 PM IST cutoff, which means a folio's value changes meaning across that line. We timestamp every holding to its NAV date so a portfolio snapshot is never ambiguous.
• Session binding outlives a single login. The UPI registration binds to a device and SIM through the PSP handshake; we replicate the token and refresh handling so a scheduled sync stays authorized, and re-validate when Navi ships a front-end change.

Screens we worked from

The mapping above was read against the app's own listing imagery. Tap to enlarge.

Where Navi sits among India's money apps

Navi competes in the same UPI-plus-investments space as a crowd of other Indian apps, and most integration jobs end up spanning several of them. Neutral context, not a ranking:

• PhonePe — the volume leader on UPI; holds payment history, wallet, and a growing insurance and mutual fund surface.
• Google Pay — high-volume UPI with payment and bill records keyed to linked bank handles.
• Paytm — UPI plus wallet, with a broad bill-payment and merchant ledger.
• CRED — credit-card-bill and UPI activity for a high-value user base, plus a credit and rewards ledger.
• BHIM — NPCI's own reference UPI app; a clean payment-only data surface.
• Amazon Pay — UPI and wallet spending tied to a commerce account.
• super.money — a newer UPI-first app pairing payments with savings and rewards.
• Groww — mutual funds, stocks, and folios; an investment-heavy counterpart to Navi's asset side.
• Freo — UPI alongside credit lines, loans, and insurance, much like Navi's loan and cover stack.

The reason this list matters: aggregating a user's money across several of these means normalizing each app's quirks to one schema — the same job, repeated, which is what the AA rail standardises on the asset side and what session work covers on the payment side.

Questions an integrator tends to ask

Does the Account Aggregator rail return a full UPI transaction history from Navi?

No. The AA rail returns asset-side records consented through a licensed Account Aggregator: mutual fund folios, insurance policies, and any deposit accounts. Granular UPI passbook entries and the digital-gold ledger live in the app session, so we reach those through authorized interface work against a consenting account.

Can the four Navi product lines be split into clean, separate schemas?

Yes. We normalize the UPI ledger, the mutual fund folios, the Navi Gold lots, and the insurance policies into distinct objects rather than one flat blob, each timestamped, with fund holdings keyed to NAV date so a portfolio snapshot is unambiguous.

Which Indian regulators sit behind a Navi integration?

Four touch it: the RBI for UPI through NPCI and for the Account Aggregator rail, SEBI for Navi Mutual Fund, and the IRDAI for Navi General Insurance. Data protection runs under India's DPDP Act, 2023. The dependable legal basis we build on is the account holder's own consent.

If Navi ships an app update mid-project, does the sync break?

A front-end change can move fields or endpoints, so we wrap the session-side captures in a re-validation step that runs on a schedule and flags drift before it reaches your data. The consented AA pull is more stable because it is contract-defined.

How this brief came together

Drafted on 27 June 2026 from the app's own store listing and the public record on India's data-sharing rails: the app's data domains and the ₹-figures from the Play description, the Account Aggregator FIP/FIU model from the Department of Financial Services framework page, the Navi entity structure (SEBI-registered AMC, IRDAI-registered insurer) from the Navi Group record, and NPCI's UPI and TPAP material for the payment side. Primary sources, opened directly:

• Department of Financial Services — Account Aggregator framework
• Navi Group — corporate and licensed-entity record
• Navi: UPI, Payments, Insurance — Google Play listing
• NPCI — UPI product and statistics

Reviewed June 2026 by the OpenBanking Studio integration desk.

One way to run this: source-code delivery starts at $300 — you get the runnable reads, the OpenAPI spec, the tests and the docs, and you pay only after delivery, once the build does what you needed. The other way skips the build entirely: call our hosted endpoints for Navi's holdings and passbook and pay per call, with nothing upfront. Either path runs on a 1–2 week cycle. Tell us the app and what you want out of it, and we arrange access and compliance with you — start a conversation here.