Net Banking Fetch vs PDF Upload vs Account Aggregator: Choosing a Statement Ingestion Route
Account Aggregator is the strongest route where it works — signed consent artefact, structured data, no tamper surface — but coverage gaps mean no Indian lender runs it alone. PDF upload is the universal fallback and carries the tampering problem. Credential-based net banking fetch has the widest reach and the weakest regulatory footing of the three.
Key facts
- YuSight benchmarks 95.2% extraction accuracy against a manual benchmark, which matters most in the PDF lane — the route where the data arrives as layout rather than as fields, and where the accuracy number decides how much analyst review each file costs.
- The Account Aggregator network is large and still uneven. Sahamati's public dashboard reported 538.32 million cumulative consents fulfilled against 326.30 million cumulative accounts linked as at July 2026 (Sahamati, AA Ecosystem Dashboard). Volume is not the same as coverage of the account you need on the file in front of you.
- Credential sharing shifts liability onto the customer. Where a loss arises from customer negligence, "such as where he has shared the payment credentials, the customer will bear the entire loss until he reports the unauthorised transaction to the bank" (RBI, Customer Protection – Limiting Liability of Customers in Unauthorised Electronic Banking Transactions, RBI/2017-18/15, 6 July 2017, para 7(i)). A journey that asks a borrower to type net banking credentials into your screen is asking them to accept that.
- Digital lending rules constrain what you may collect and keep. Any collection of data by a regulated entity's digital lending app or its LSP's app must be "need-based and with prior and explicit consent of the borrower having audit trail", and the RE must ensure LSPs "do not store personal information of borrower except some basic minimal data (viz., name, address, contact details of the customer, etc.)" (RBI (Digital Lending) Directions, 2025, RBI/2025-26/36, 8 May 2025, clauses 12 and 13).
- The data protection layer is now live. MeitY notified the Digital Personal Data Protection Rules, 2025 on 14 November 2025, with phased commencement of specific obligations — confirm the phasing dates applicable to your entity before you rewrite consent copy (Digital Personal Data Protection Act, 2023).
What are the three routes, precisely?
Net banking fetch (also sold as "statement fetch", "bank connect" or, less politely, screen scraping). The borrower enters net banking credentials in an embedded flow; a service logs in as the borrower, navigates to the statement page and extracts or downloads the data. Some implementations pass credentials through without storage; some store them for repeat pulls. The distinction matters enormously and is rarely visible from the borrower's side of the screen.
PDF upload. The borrower downloads a statement from their own net banking or collects it at a branch, and uploads or emails it. Universal, because every bank produces one.
Account Aggregator. The borrower authorises an RBI-licensed NBFC-AA to instruct their bank to send specified data to a specified lender for a specified purpose and period. The AA carries the payload but cannot read or retain it. The mechanics — consent artefact fields, purpose codes, FI types — are set out in the Account Aggregator framework explained.
How do the three compare on the dimensions that decide?
Dimension | Net banking fetch | PDF upload | Account Aggregator |
|---|---|---|---|
Data fidelity | Good where the page renders; loses value date, mode and reference number when the source is a screen rather than a download | Layout, not fields. Fidelity depends on the extraction stack and the bank's template version | Highest. Typed fields — type, mode (CASH/ATM/UPI/FT/CARD), amount, current balance, transaction and value timestamps, narration, reference |
Coverage | Widest. Any account the borrower has net banking for, including entity and joint accounts | Universal. Any account with a downloadable or branch statement | Narrowest. Only FIPs live with your chosen AA, only supported FI types. Entity and joint accounts remain the recurring gap |
Consent and regulatory standing | Weakest. Credential sharing sits against most banks' terms and against RBI's liability framework | Borrower's own act of sending a file. Adequate, but provenance must be argued | Strongest. Digitally signed consent artefact from an RBI-licensed intermediary |
Tampering risk | Low, but the credential exposure replaces it with a security risk | Real and live. Editable PDFs, re-rendered exports, doctored balances | Effectively nil. Data originates at the FIP |
Failure modes | Silent breakage after a bank UI or MFA release; OTP timeouts; account lockouts | Missing pages, password-protected files, cropped exports, discontinuous periods, unreadable scans | FIP unavailable, account not discoverable, FI type unsupported, discovery timeout |
Borrower friction | Low at first attempt, high on failure. Many borrowers refuse outright | Highest ongoing. Multi-step, multi-account, multi-day | Low, once the borrower's bank is live. Mobile-number-based discovery, single approval |
Freshness and reuse | On demand, if the integration still works | As at the borrower's download date. A fresh request each time | Repeatable under a periodic consent, to the consent's expiry |
Audit position | Difficult to defend to a supervisor | Document provenance is the whole argument | The consent artefact is the evidence |
Why is credential-based fetch the weak leg?
Three separate problems, and they do not cancel out.
One — liability sits with the borrower. RBI's 2017 limiting-liability framework is explicit that a customer who has shared payment credentials bears the entire loss until they report the transaction (RBI/2017-18/15, para 7(i)). You are designing a journey whose first instruction moves the customer into the least protected position the framework contemplates.
Two — storage is constrained. Under the Digital Lending Directions, 2025, an RE must ensure LSPs do not store personal information beyond basic minimal data, and all data must sit on servers in India, with anything processed abroad deleted there and repatriated within 24 hours (clause 13). Stored net banking credentials are not "name, address, contact details". A vendor that retains credentials for repeat pulls has created a compliance question you own, not one they own. The wider checklist is in the RBI digital lending guidelines working checklist.
Three — it breaks quietly. A bank ships a login redesign or tightens MFA and the integration stops working for that bank. Nobody is notified. The symptom reaches you as a drop in conversion for one bank's customers, two weeks later, discovered by someone reading a funnel report.
None of this makes credential-based fetch useless. It makes it a route you should be able to justify in writing, with a documented pass-through architecture, no credential storage, and an explicit fallback.
Where does PDF upload actually fail?
Not usually where people expect. In practice, four things:
- Format drift. Banks change statement templates without announcement. A parser tuned to last quarter's layout silently mis-maps a column. The failure looks like data, not like an error.
- Password protection. Statement PDFs are commonly locked to a PAN-and-date-of-birth pattern. The borrower's unlock step is a real drop-off point.
- Selective supply. The borrower gives you the account that looks best. This is not an ingestion failure; it is why the account list must be built independently from the GST registration, financials and bureau.
- Tampering. Editing a PDF is trivial and the results are frequently competent. Detection is a discipline of its own — see how to detect a fake or tampered bank statement.
Where does Account Aggregator actually fail?
Coverage, mostly. The FIP-to-AA relationship is a matrix rather than a list, so an account is only reachable if the borrower's bank is live with your AA. FI-type coverage lags account coverage. And the account types that fail most often are the ones MSME lending needs: partnership and private limited company accounts, joint accounts, NRE/NRO accounts. Entity-account coverage varies by FIP and improves month to month; confirm your AA's current live FIP list before writing a coverage assumption into policy.
The second failure surface is latency you did not budget for. Sahamati's ecosystem SLA sets discovery at under five seconds at p95 (Sahamati, AA Ecosystem SLAs v0.9.1). An eight-second spinner is inside spec, not a bug. Design the front end for it.
Worked example: cost per completed file — illustrative
An NBFC underwrites 4,000 MSME applications a month. Fully loaded analyst cost ₹520 per hour, or ₹8.67 per minute. All figures illustrative.
Route A — PDF only.
- Statement collection completes for 82% of applications: 4,000 × 0.82 = 3,280 files
- Review time 14 minutes per file: 14 × ₹8.67 = ₹121.33 per file
- Review cost: 3,280 × ₹121.33 = ₹3,97,962
- Tamper investigation on 1.2% of files, 45 minutes each: 39 files × ₹390 = ₹15,210
- Total ₹4,13,172 for 3,280 completed files = ₹126 per file
Route B — AA first, PDF fallback.
- AA completes fully for 61% of applications: 4,000 × 0.61 = 2,440 files
- AA fetch cost ₹35 per completed file: 2,440 × ₹35 = ₹85,400
- Failed AA attempts still billable at ₹8: 1,560 × ₹8 = ₹12,480
- Review time on AA files is 4 minutes — no parsing, no tamper check: 2,440 × ₹34.67 = ₹84,595
- PDF fallback completes for 82% of the 1,560 remaining: 1,279 files
- PDF review: 1,279 × ₹121.33 = ₹1,55,181
- Tamper investigation on 1.2% of the PDF lane: 15 files × ₹390 = ₹5,850
- Total ₹3,43,506 for 3,719 completed files = ₹92 per file
The comparison. Route B costs 16.9% less in absolute terms (₹3.44 lakh against ₹4.13 lakh) and completes 13.4% more files (3,719 against 3,280). The cost-per-file gap is wider still — ₹92 against ₹126, a 27% reduction.
The number that matters to the business is the 439 additional completed files. At a 22% approval rate and an average ticket of ₹18 lakh: 439 × 0.22 = 96.6 sanctions, × ₹18 lakh = ₹17.4 crore of incremental monthly disbursal. The ingestion route is a distribution decision wearing an operations costume.
Which route for which lender?
Lender profile and ticket | Primary route | Fallback | Why |
|---|---|---|---|
Digital NBFC, ₹50k–₹5 lakh, proprietor borrowers | Account Aggregator | PDF upload | Proprietor accounts have the best AA coverage; volume makes per-file cost decisive |
NBFC, ₹5 lakh–₹1 crore MSME | Account Aggregator | PDF upload with tamper checks | Entity-account coverage still patchy; the fallback lane must be properly instrumented |
Bank branch-sourced working capital, ₹1 crore+ | PDF or direct bank download | AA for the promoter's personal accounts | The RM already collects documents; AA adds value on the guarantor side |
Co-lending or partnership sourcing | Account Aggregator with a periodic consent | Partner-supplied PDFs | Monitoring reuse is worth more than the acquisition saving |
Supply chain or invoice finance | Account Aggregator plus GSTN as FIP | You need the return data alongside the statement |
Credential-based net banking fetch does not appear as a primary route in any row. If your stack still uses it, the defensible position is as a last resort, pass-through only, with no credential storage and a documented rationale in the file.
What does a production stack look like?
A waterfall, not a choice. Try AA discovery first. On discovery failure or unsupported FI type, fall through to a direct bank-download instruction with a password-unlock helper. On upload, run the integrity checks — running-balance footing, page continuity, font and object-level tamper signals — before anything reaches the analyst. Log which route produced each statement, because the evidentiary weight of the file depends on it.
Then, whichever route delivered the data, the analysis is the same problem: narrations are still free text, related parties are still unlabelled, and seasonality still needs twelve months. That work is set out in bank statement analysis for MSME loans and, for the general method, in the complete guide to bank statement analysis. The build-or-buy question around the pipeline itself is covered in bank statement analysis software for NBFCs.
FAQ
Which statement ingestion method is most reliable?
Account Aggregator, where the borrower's bank is live with your AA. The data is typed rather than parsed, it cannot be edited in transit, and the consent artefact is the audit evidence. Reliability collapses to zero for accounts outside AA coverage, which is why every production stack keeps a fallback.
Can bank statement analysis software integrate with the Account Aggregator framework?
Yes, but the lender must be a registered Financial Information User; the software sits behind that registration. What arrives is structured JSON or XML per FI type, which the analyser normalises exactly as it normalises a parsed PDF. The categorisation work is unchanged.
Which route has the lowest borrower drop-off?
Account Aggregator, when the bank is live — discovery is by mobile number and approval is one step. When the bank is not live, AA has the highest drop-off, because the borrower experiences a failed journey rather than a slow one. Measure drop-off per route per bank, not as a single number.
Is net banking credential fetch illegal in India?
No blanket prohibition exists. What exists is a set of constraints that make it hard to defend: RBI's liability framework puts the loss on a customer who shared credentials, most banks' net banking terms prohibit sharing, and the Digital Lending Directions restrict what an LSP may store. Treat it as a last resort with a documented architecture.
Does Account Aggregator eliminate the need for tamper detection?
For the AA lane, yes — the data comes from the FIP. For your fallback lane, no. As long as any share of files arrives as PDFs, you need the integrity checks running on that share.
How long can we keep data pulled through an AA?
For the data life the consent artefact specifies, used only for the purpose it names. Reusing an underwriting-purpose fetch for portfolio monitoring is a consent violation, not an efficiency. Take a periodic monitoring consent at onboarding if you intend to monitor.
What happens to files where every route fails?
They go to a manual lane — branch-certified statements, a banker's confirmation letter, or a physical passbook — and they should be counted. A route mix that leaves 8% of applications in the manual lane is a different business from one that leaves 2%, and the difference does not show up in an average cost-per-file.
Should we run more than one AA?
Most lenders at scale do, precisely because FIP coverage differs between AAs. The operational cost is a second integration and a routing rule; the benefit is coverage on banks your primary AA has not signed. Model it against your own borrowers' bank distribution rather than against the ecosystem total.
Key takeaways
- Account Aggregator wins on fidelity, consent standing and tamper risk, and loses on coverage. That combination makes it a primary route, never the only one.
- PDF upload is not obsolete and will not be for years. Instrument the lane properly — footing checks, continuity checks, tamper detection — instead of treating it as the sad path.
- Credential-based net banking fetch buys coverage with liability. If you use it, use it last, pass credentials through without storing them, and write down why.
- Cost per completed file is the wrong metric alone. Completion rate multiplied by approval rate multiplied by ticket size is what the route actually decides.
- Log the provenance of every statement. When a file is questioned, the route is the first thing that determines what the document is worth.
Run one borrower through the analyzer — bring a set that mixes AA JSON and bank PDFs, and see both lanes land in the same reconciled statement view with every figure cited to its source.