Read a bank statement like an
underwriter does.

What is "banking data" in Indian fintech?

"Banking data" in 2026 means more than a PDF statement. It's the live, consented, digitally-signed view of a customer's financial life — bank balances, transactions, recurring credits and debits, salary inflows, EMI outflows, bounced cheques, virtual account postings, and the cross-bank picture a single PDF can't show. Every Indian fintech that underwrites, disburses, or reconciles touches this surface: lenders use it for cash-flow underwriting, neobanks for in-app analytics, payment platforms for payout correctness, and treasury platforms for reconciliation.

The Indian stack is uniquely well-instrumented. The Account Aggregator framework (RBI, 2016) gave the country a consent-based data-sharing rail before most regions had one. The Unified Payments Interface (UPI) generates a transaction stream richer than any equivalent abroad. The Employees' Provident Fund Organisation (EPFO) holds a continuous employer-reported income register. And on top, the DPDP Act 2023 turned consent from a checkbox into an enforceable contract.

This guide walks the banking-data surface in the order an Indian fintech actually meets it: regulators first, the four practical data sources, AA vs statement-upload as the live debate, the statement-parsing signals underwriters actually read, the refresh cadence that keeps the data current, and the five implementation pitfalls every team trips on before they ship it right.

India regulatory map

The RBI Master Direction on NBFC-Account Aggregators (2016, last amended 2023) is the load-bearing rule. It defines what an AA is, what data it can pass, how consent must be captured and revoked, retention rules for the consent artefact, and the technical standards FIPs and FIUs must meet to participate. The industry body that publishes the technical specs and runs the inter-operator certification is Sahamati, a Section 8 not-for-profit chartered by the AA participants.

The Digital Personal Data Protection Act, 2023 sits on top. AA-fetched data is DPDP-compliant by construction — the consent layer DEPA prescribes is exactly the consent layer DPDP enforces — but everything outside the AA flow (statement uploads, customer-shared screenshots, screen-share assists) now has to clear DPDP's specific-purpose-and-retention bar separately. The Data Empowerment and Protection Architecture (DEPA) is the umbrella policy framework that ties them together; AA is its first sectoral rollout, with health (NDHM) and telecom AAs planned next.

For payments rails, NPCI owns UPI, IMPS, NEFT, NACH, and the RuPay scheme — every penny-drop, every virtual account credit, every NACH e-mandate routes through an NPCI rail. NPCI is technically a private-sector entity (an "Umbrella Organisation for Retail Payments" under the PSS Act 2007) but is regulated by RBI and, in practice, sets the operating standard for any fintech touching bank accounts.

Two further sources matter for income data. The EPFO runs the Universal Account Number (UAN) — a continuous employer-reported PF-contribution record that underwriters use as a tamper-evident income signal. And UIDAI's Aadhaar + DigiLocker stack provides the identity backbone that lets bank data be tied to a verified individual at consent time.

The practical takeaway: AA-first wherever you can, and bank-data sources outside AA (uploads, EPFO, payments rails) are each governed by their own statute. Build to the strictest regulator that touches your product; the audit will check each rail separately.

The 4 banking-data sources

Every banking-data pipeline in Indian fintech draws from one of four sources. Most mature stacks use three of the four; only a handful use all four.

1. Account Aggregator (AA)

The consent-based, RBI-regulated pipe. Customer authenticates on their AA (OneMoney, Finvu, NADL, CAMSFinServ), approves a consent artefact, and signed transaction data flows from the bank (the FIP) to the fintech (the FIU) through the AA. Best-in-class for tamper-evidence and refresh; constrained by coverage in smaller banks.

2. Customer statement upload

Customer downloads a PDF / Excel / CSV statement from their net-banking and uploads it into the fintech app. Universal coverage (any bank, any account), but lower consent grade and no tamper-evidence at the issuer level. The parser does the work of canonicalising 50+ bank templates into a single schema. Still the dominant source for accounts where AA coverage isn't yet live.

3. Direct FIP partnership

A small number of large fintechs hold direct bilateral data-sharing agreements with specific banks, predating or operating alongside AA. These are commercial agreements, not regulatory rails — they don't replace AA for new build-outs, but they continue to carry significant volume for established partnerships.

4. Customer-derived signals (payment rails + UAN)

For income, EPFO's UAN gives a continuous employer-reported PF deposit record — a tamper-evident signal that the customer is salaried, by whom, and for how much. Payment-rail data (UPI transaction stream, IMPS receipt logs, NACH mandate registry) complement bank-statement data with a real-time view of recent activity. These aren't bank statements, but they answer many of the same underwriting questions faster.

The 2026 default: AA-first, with statement-upload as the universal fallback, and UAN + payment-rail signals layered on for income and recency. Direct FIP partnerships fade where AA coverage catches up.

AA vs statement-upload — the live debate

AA crossed ~600M consents in market by early 2026 and continues to grow. It's the obvious answer for any fintech building today. But the live debate isn't AA vs nothing — it's AA vs statement-upload, and the right answer is "both," tuned to the customer base.

The pragmatic 2026 stack: AA-first for the cohorts where coverage is dense (urban, private-bank-heavy), with statement-upload as a transparent fallback for the cohorts where AA coverage isn't yet live (rural, co-op-bank-heavy, RRB-heavy). For products that need recurring data refresh (credit monitoring, ongoing-underwriting facilities, treasury reconciliation), AA wins on lifecycle cost even where its first-fetch latency is higher.

Statement-parsing primer — the signals every underwriter reads

A bank statement is not its rows; it's the patterns inside its rows. An underwriter who parses 12 months of statements is reading for a small, well-known set of signals.

Salary credits. A recurring inflow on or near the same day each month, tagged "SALARY" or with an employer narration. Salary credits anchor the income assessment and let the underwriter compute a stable monthly base. Multi-employer salary patterns are increasingly common — flag them, don't drop them.

EMI / recurring outflows. Loan EMIs, credit-card auto-debits, SIP investments, insurance premiums, BNPL repayments. Each is a fixed obligation that erodes the disposable monthly cash flow. The underwriter sums them to get the fixed-obligations-to-income ratio (FOIR) — the single most predictive variable in consumer lending.

Bounced cheques and failed mandates. A bounced cheque ("RTN" or "RETURN PER REQUEST") or a failed NACH mandate is a direct signal of cash-flow stress. One in 12 months is noise; three is a hard signal. The parser tags them explicitly.

Average monthly balance + balance trend. Average balance gives a working-capital snapshot; the trend (rising, flat, falling over 12 months) reveals whether the customer is accumulating or depleting reserves.

Anomaly events. Large unexpected inflows (gifts, asset sales, one-time bonuses), large unexpected outflows (medical, legal, property), inter-account transfers that wash out across the statement. Each tells the underwriter something about the customer's broader financial life that the recurring pattern doesn't.

A good parser doesn't just emit transactions — it emits these derived signals as first-class outputs, with confidence scores. Building the parser is an integration product (50+ bank templates, ongoing template drift, password formats varying by bank). Buying the parser is the answer for most teams.

Refresh cadence + consent windows

The single biggest difference between AA and statement-upload, operationally, is what happens at refresh.

AA consents carry a defined duration, set at consent-request time within RBI limits: typically 1 month for one-time pulls, 12 months for recurring use cases like ongoing credit monitoring, and up to 24 months for long-running products. The FIU re-fetches under the same consent on whatever cadence the use case needs — daily for active credit monitoring, weekly for treasury, monthly for portfolio review. At expiry, the FIP stops honouring the consent and the FIU must request a fresh one through the AA. The operational best practice: request consent renewal in-app before expiry, not after. Completion rates drop sharply once the data stops flowing and the customer has to re-authenticate on the AA cold.

Statement-upload has no equivalent. Each refresh requires the customer to manually download a fresh PDF from their net-banking and re-upload it. Completion rates on re-upload are 30–50% of the original upload's completion — friction wins almost every time. The result, in practice, is that statement-upload stacks degrade to stale data within months of the first onboarding, while AA stacks stay current automatically. That's why AA is structurally the right answer for any product that needs ongoing monitoring, even where its first-fetch latency or per-fetch cost is higher than upload.

UAN (EPFO) is its own thing — it's a continuous register, not a consent-bound feed. Re-querying the UAN at refresh confirms whether the customer is still employed and whether the employer / salary has changed. A UAN with no contributions in the last 3 months is the strongest signal available that the customer has stopped being salaried.

Implementation pitfalls — the 5 that bite

Every banking-data team hits the same five.

1. Trusting AA coverage in unbanked geographies. AA has ~600M consents but coverage of small co-operative banks, regional rural banks, and some state-private banks is still incomplete — roughly a 30% gap by customer count once you look outside metro and Tier-1 cohorts. Building a product that's AA-only ships beautifully in pilot and breaks in production when the rural cohort lands. Statement- upload fallback isn't optional; it's structural.

2. Skipping the digital-signature check on AA-fetched XML. The whole point of AA over upload is that the FIP signs the payload. If your FIU silently accepts the data without verifying the signature, you've thrown away the tamper- evidence guarantee and the audit will find it. Signature verification is one line; skipping it is one outage waiting to happen.

3. Statement parsing without bank-template canonicalisation. Every Indian bank emits a different PDF. A parser that handles SBI and HDFC and breaks on Karnataka Bank or RRB-issued statements degrades silently — transactions go missing, balances misalign, EMIs aren't tagged. Canonicalisation across 50+ templates is the load-bearing layer; treat it as a product, not a regex.

4. UAN lookup at onboarding only, not at refresh. The UAN signal is most valuable at refresh — it tells you whether the customer is still salaried, by whom, and at what compensation level. Teams that pull UAN once at onboarding and never again miss the moment a customer's employment changes, which is exactly when their repayment behaviour will change.

5. Penny-drop with name-match tolerance set too loose. Penny-drop confirms the account belongs to someone, but the value of the check is the name-match against the customer-claimed name. Loose tolerance (accepting "RAHUL K" as a match for "Rahul Kumar Sharma") lets payouts go to the wrong beneficiary; the recovery cost is borne by you, not the bank. Define the tolerance explicitly (initials, suffix elision, abbreviations) and log every decision.

How Deepvue ships banking-data

Every API in the catalog below sits on the same auth, the same SLA, the same decisioning layer underneath. AA consent orchestration, statement analysis, penny-drop, IFSC + name-match, cheque OCR, UAN — one contract for the full banking-data stack, with the AA-first / upload-fallback routing built in so you don't have to choose at integration time.

The parser ships across 50+ bank templates and improves with every new statement seen. Digital-signature verification on AA payloads is on by default. Refresh consents and UAN re-queries are scheduled as infrastructure, not orchestrated by the FIU. DPDP-compliant out of the box.

Sub-6-second response on the full 12-month statement-analysis path. Live across 60+ businesses processing 10M+ banking-data decisions per quarter.

See Deepvue parse a bank statement in 8 seconds →