Pulling bank, UPI and investment data out of PhonePe

A single PhonePe login sits in front of more record types than most Indian consumer apps carry: money sent and received over UPI, balances on several linked bank accounts, a digital gold and silver holding, mutual fund and SIP positions, insurance policies, and active loans. The History view alone lists every payment, transfer and bill with its date and time, amount, counterparty, instrument used and status. Industry tallies put PhonePe at close to half of India's UPI transaction volume through late 2024, so for a lot of users this one app is the most complete picture of their day-to-day money.

The route we would actually take here is split by data type. For the regulated bank-account layer — statements and balances on the linked SBI, HDFC, ICICI, Axis and other accounts — consent flows through India's Account Aggregator network. For everything that lives inside the app's own surfaces (UPI history, gold and fund holdings, loan status), we work from authorized interface analysis under the account holder's consent, with the downloadable statement as a backstop for older records.

What sits behind a PhonePe account

Each row below is a real surface in the app, not a generic feature list. Granularity reflects what the History view, statement and product screens actually expose.

Authorized routes to the data

Three routes apply to PhonePe, and a serious build usually uses two of them together.

Account Aggregator consent (regulated bank layer)

India's RBI-regulated Account Aggregator network moves bank-held financial data between institutions on a single revocable digital consent. For the linked-bank statements and balances behind a PhonePe account, this is the durable, audited path — consent is purpose-bound and time-bound, and nothing transfers without it. Onboarding to a live NBFC-AA as a Financial Information User is arranged with you during the project. Reach is limited to what the banks publish as Financial Information Providers, so it is strong on statements and balances, not on the app's own gold or fund ledgers.

Authorized interface analysis (in-app surfaces)

For the UPI history, gold and silver wallet, fund holdings, insurance and loan screens — the data that lives in PhonePe's own product surfaces — we map the app's authenticated traffic under the account holder's consent and rebuild the relevant calls as a documented interface. This is the widest-reaching route for PhonePe specifically, because so much of its value is in surfaces a bank never sees. It carries more maintenance, since the front end changes; we plan for that below.

Native statement export (history backstop)

PhonePe lets a user download a statement as a PDF for a chosen period. That export is the simplest fallback for historical records and the cleanest source for data older than the in-app History window. We treat it as a complement, not the primary feed.

For most clients the working combination is Account Aggregator consent for the regulated bank statements where it genuinely fits, with authorized interface analysis carrying the in-app investment, lending and UPI surfaces that the AA network does not reach — and statement ingestion filling the historical tail. We pick the split per client once we know which records you actually need.

What a PhonePe build hands you

The output is a working integration for the surfaces you asked for, not a report. Concretely:

• An OpenAPI/Swagger specification covering the endpoints we implement — transaction history, balance, holdings, policy and loan reads — with the request and response fields documented.
• A protocol and auth-flow report: the session, token and consent chain as it actually works for PhonePe, including the UPI-PIN / OTP gating and how sessions refresh.
• Runnable source for the key endpoints in Python or Node.js, with the normalization layer that flattens multi-instrument records into one schema.
• An automated test suite, including fixtures captured during the build so a front-end change shows up as a failing test rather than silent data loss.
• Interface documentation, plus data-retention and consent-handling guidance aligned to RBI localization and the DPDP Act.

What a transaction pull looks like

Field names below were confirmed against the app's History view and the downloadable statement during a build; this is illustrative of the shape, not a published contract.

# 1. Authenticated session — device + account, UPI-PIN / OTP gated
POST /auth/session            -> { session_token, account_ref }

# 2. Pull history with the same filters the app exposes
GET  /txn/history?from=2026-01-01&to=2026-06-24
       &instrument=upi,linked_bank,wallet&status=success
     Authorization: Bearer <session_token>

# 3. Normalized record we emit downstream (one shape for every instrument):
{
  "txn_id":       "T2406...",                 # PhonePe reference
  "ts":           "2026-06-20T14:03:11+05:30",
  "amount":       { "value": 1299.00, "currency": "INR" },
  "direction":    "debit",                    # debit | credit
  "counterparty": { "name": "...", "vpa": "...@ybl" },
  "instrument":   "upi",                       # upi | linked_bank | wallet
  "funding_src":  "HDFC ****4471",
  "category":     "merchant_payment",
  "status":       "success"
}

# Older than the in-app window? Same shape, parsed from the PDF statement,
# then de-duplicated against the live pull on txn_id.
      

Working inside India's consent rules

Two regimes govern this work. The first is the RBI Account Aggregator framework, built on the NBFC-AA Master Direction the central bank issued in September 2016 and live commercially since September 2021; the network crossed 140 million consents by December 2024 per public figures. It splits the world into Financial Information Providers (the banks that hold data), Financial Information Users (who consume it), and the licensed Account Aggregator that moves it — only on the user's explicit, granular, revocable consent, with a defined purpose and expiry.

PhonePe's own place in that framework is worth noting, because it shapes the route. Its subsidiary PhonePe Technology Services held an NBFC-AA certificate dated early 2023 and launched Account Aggregator services that June, then announced in February 2025 that it was winding the business down and surrendering the licence, citing onboarding difficulties (per Business Standard). So we do not route consent through PhonePe's AA; we use other live aggregators, and the consent layer stays swappable.

The second regime is the Digital Personal Data Protection Act, 2023, whose implementing Rules were notified in late 2025. It requires explicit, informed consent and clear privacy notices. Where there is a conflict, the sectoral RBI rules prevail, and RBI payment-data localization keeps payment records stored within India. We operate authorized, logged and data-minimized: only the records you need, consent and access events recorded, and an NDA in place where the engagement calls for one.

Notes specific to a PhonePe build

A few things about this app shape how we build, and we handle each as part of the work:

• Six-month History edge. The in-app History view surfaces roughly the last six months per PhonePe's help pages, while the PDF statement reaches further back. We design the sync to read the live feed and ingest statements on a schedule, so records do not fall off the six-month cliff.
• Multi-instrument under one account. One login spans several linked banks, the wallet, and gold and fund holdings. We normalize across all of them and tag every record with its funding source, so a payment from a linked SBI account and one from the wallet land in a single consistent schema.
• A moving consent layer. Because PhonePe surrendered its own AA licence, the regulated bank-data path now depends on third-party aggregators that come and go. We keep that layer pluggable and arrange the FIU onboarding with you, rather than hard-wiring one provider.
• Front-end drift. The app's surfaces change. The parser ships with fixtures captured during the build and a diff check that flags a layout change before it corrupts a sync, so maintenance is a known, contained job.

Where this data gets used

• Lending underwriters reading consented bank statements plus UPI cash-flow to score a thin-file borrower.
• Personal-finance and wealth apps building a consolidated view that folds PhonePe's gold, fund and loan holdings in beside bank balances.
• Accounting and reconciliation tools matching merchant UPI receipts against invoices.
• Expense and subscription trackers detecting recurring bills and EMIs from the payment history.

Screens we worked from

Store screenshots used while mapping the surfaces above. Tap to enlarge.

Comparable India fintech apps and what they hold

Same data orbit, useful when an integration needs to span more than one app. Listed for context, not ranked.

• Google Pay — UPI transfers and bill payments; transaction history tied to linked bank accounts, similar in shape to PhonePe's.
• Paytm — UPI plus a wallet, a payments bank, and a commerce and ticketing ledger, so it holds order data alongside transfers.
• BHIM — NPCI's own UPI app; a clean record of UPI sends, requests and linked-account activity.
• Amazon Pay — UPI and card payments plus balance, with spending concentrated around Amazon's marketplace.
• Navi — UPI payments alongside lending and insurance products, with loan and policy records inside the app.
• CRED — UPI and credit-card bill payments aimed at cardholders; holds card-repayment and reward-ledger data.
• MobiKwik — wallet, UPI and lending, and one of the first to carry an e-Rupee CBDC wallet.
• BharatPe — merchant-side UPI acceptance with interoperable QR settlements, so its records skew to collections and payouts.

Questions integrators ask about PhonePe

Can the integration reach data across the linked bank accounts, or only PhonePe's own wallet?

Both. A PhonePe account fronts several linked bank accounts plus the PhonePe wallet, and the History view already mixes them. We normalize across all of them and tag each record with its funding source, so a debit from a linked HDFC account and one from the wallet end up in the same schema with the instrument labelled.

How far back does PhonePe transaction data go when pulled this way?

The in-app History view exposes roughly the last six months per PhonePe's own help pages, while the downloadable statement covers a longer window. We pair a live read of the History feed with periodic statement ingestion so older records are not dropped at the six-month edge.

Does PhonePe surrendering its Account Aggregator licence change the bank-data route?

It changes which consent manager we route through, not the route itself. PhonePe's NBFC-AA subsidiary surrendered its licence in early 2025, so for regulated bank-statement consent we use other live Account Aggregators rather than PhonePe's. We keep the consent layer pluggable for exactly this reason.

Beyond UPI, do gold, mutual fund and loan holdings carry into the feed?

Yes. Digital gold and silver balances, mutual fund and SIP holdings, insurance policies and loan or repayment records are distinct surfaces inside the app, each with its own granularity. We map them as separate domains so a portfolio view and a payments view can be built independently or merged.

We already keep PhonePe statement PDFs — can those be turned into a structured feed?

They can. The PDF statement is a fixed layout, so we build a parser that emits the same normalized record shape as the live pull, then reconcile the two so a transaction present in both is not counted twice.

What we checked, and where

This write-up draws on PhonePe's own help and press pages for the History view, statement export and Account Aggregator timeline, the Indian government's Account Aggregator reference for the framework roles, news coverage of the licence surrender, and the DPDP Act text. Checked June 2026.

• PhonePe — transaction statement help
• Dept. of Financial Services — Account Aggregator framework
• Business Standard — PhonePe to surrender NBFC-AA licence
• MeitY — Digital Personal Data Protection Act, 2023

OpenBanking Studio integration desk · mapping reviewed 2026-06-24.

Source-code delivery starts at $300, billed only after we hand over the runnable build and you have checked it works on your side; the alternative is our hosted endpoints, billed per call with nothing upfront. A typical PhonePe build runs one to two weeks. Tell us which records you need and how you want them delivered at /contact.html.