Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
Lenders receive bank statements through two routes, Account Aggregator data and PDF uploads, which need different verification work before credit review.
Account Aggregator data arrives structured and signed from the bank on consent, so checks focus on completeness; PDFs need tampering checks, parsing and sometimes OCR first.
Route Account Aggregator data straight to normalisation; route PDFs through password handling, integrity checks and parsing; then merge both into one review queue.
One consistent credit review regardless of source, with a consent record for Account Aggregator files and an integrity record for PDF files.
With Account Aggregator (AA), the lender receives structured transaction data straight from the borrower’s bank once the borrower approves a consent, so there is no PDF to edit, parse or unlock. With a PDF upload, the lender must read the document, check that nobody has altered it and sometimes run OCR (optical character recognition, which turns a scanned image into text) before any credit review can begin.
Both routes end in the same place: a list of credits and debits the analyst reads for income, obligations and cash flow. What changes is the work needed before that point.
How do the two routes compare?
The AA framework runs under the RBI Master Direction for NBFC Account Aggregators, first issued on 2 September 2016. Banks act as Financial Information Providers (FIPs), lenders act as Financial Information Users (FIUs), and the data follows the ReBIT technical specification, currently v2.0.0.
| Point | Account Aggregator | PDF upload |
|---|---|---|
| Data source | The bank’s own system, sent on consent | A file the borrower downloads and uploads |
| Tampering risk | Very low: data is signed and encrypted in transit | Real: edited PDFs and fake templates exist |
| Parsing effort | Low: data is already structured | Medium to high: layouts differ by bank; scans need OCR |
| Borrower effort | Approve a consent on a phone | Find, download, sometimes unlock and upload files |
| Bank coverage | Only banks live as FIPs | Any bank that issues a statement |
| Consent record | Built in: purpose, range and duration are recorded | Separate: the lender records how it received the file |
| Months of history | Whatever the consent requests and the bank holds | Whatever the borrower uploads; gaps are common |
Why do lenders still accept PDFs when AA exists?
Three reasons come up again and again.
- Coverage. Sahamati’s certified-entities list, retrieved in August 2026, showed 2 of about 1,457 urban co-operative banks and none of roughly 1,01,524 primary agricultural credit societies (PACS) on the network. Sahamati’s FIP dashboard counted about 142 FIPs live on at least one AA as of May 2026. A trader who banks with a small co-operative bank simply cannot use AA.
- Journey failures. A live bank can still time out, the mobile number may not match the account, or the borrower may abandon the consent screen.
- Borrower preference. Some applicants, particularly older business owners, trust a statement they can see.
So a lender that accepts only AA turns away good borrowers. Most keep the PDF route as a fallback.
Worked example: 1,000 applications in a month
An NBFC receives 1,000 MSME loan applications in a month, with an average request of ₹8,00,000. 700 applicants finish the AA journey; 300 upload PDFs. That is ₹56 crore of requests on the AA path (700 × ₹8,00,000) and ₹24 crore on the PDF path (300 × ₹8,00,000).
AA path (700 files):
- Confirm the consent covers the requested range, say 12 months.
- Check every account named in the application was included.
- Normalise the data and send it to credit review.
PDF path (300 files):
- Unlock password-protected files (often the applicant’s date of birth or customer ID).
- Check file metadata and the creating software.
- Recompute the running balance line by line. If an opening balance of ₹1,42,300 plus credits of ₹6,18,000 minus debits of ₹5,90,450 does not equal the printed closing balance of ₹1,69,850, the file is flagged.
- Read the layout or OCR the scan, then check for missing pages and date gaps.
- Send the clean data to credit review.
Here ₹1,42,300 + ₹6,18,000 − ₹5,90,450 = ₹1,69,850, so this statement passes the balance test. If 30 of the 300 PDFs (10 percent) need manual follow-up, those 30 files can take more analyst time than all 700 AA files together. That is why lenders push AA first but cannot drop PDFs.
How do both routes feed one review?
The aim is that the credit analyst should not care which route a file came from. Once both are turned into the same transaction format, the same rules for salary or business credits, EMI debits, cheque returns and cash deposits apply. The manual vs automated bank statement review guide shows how teams set that up, and bank statement OCR in India covers the PDF side in detail.
What to read next
- Next in this series: Why is my bank not showing in Account Aggregator, and what do lenders do instead?
- Manual vs automated bank statement review
- Bank statement OCR in India
- Account Aggregator bank statement analysis
TransactIQ takes Account Aggregator data and PDF statements, including scanned and co-operative bank formats, into one review with 40+ engineered credit signals, run as a managed service on AWS Mumbai.