Bank statement analyser for loan agents, NBFCs and banks
A borrower sends six months of statements; the credit file needs income, obligations and a repayment read. CleanStatement rolls the cleaned rows into the four signals a lender looks at first — income, FOIR, bounces and average balance — plus an authenticity check that surfaces whether the printed balances actually reconcile. The statement is analysed on your own device and is never uploaded.
The loan-file snapshot
Every cleaned statement produces an underwriting one-pager, on screen and as a sheet in the downloaded workbook:
- Monthly income — salary credits, the number of distinct months they landed in, and whether the pattern has a regular payroll shape.
- Obligations — EMI outflows grouped per counterparty with a monthly average, so each existing loan is visible separately.
- FOIR — the fixed-obligation-to-income ratio, benchmarked against the typical lender ceiling: at or below 40% comfortable, 40–50% borderline, above 50% over.
- Bounces — cheque, ECS and NACH return flags, plus the rupee total of return charges actually debited.
- Average monthly balance — computed time-weighted across days rather than as a simple average, per month, with the minimum and maximum, and a rising, steady or falling trend across the window.
- Cash intensity — the share of total flow moving in and out as cash, which is what separates a documented income profile from an undocumented one.
- Authenticity — the running-balance recomputation surfaced as an explicit tamper signal.
Why the balance recomputation matters for credit teams
An edited PDF statement is one of the more common frauds in retail lending, and it is usually caught by arithmetic rather than by eye. CleanStatement recomputes the running balance from the opening figure and every debit and credit, then compares each result to the balance printed on the statement.
If someone has inflated a salary credit or removed a bounce, the printed balances stop reconciling from that row onward, and the file is flagged. A statement that verifies cleanly is not proof of authenticity, but a statement that fails is a clear reason to ask for a bank-verified copy.
Works with or without classification
The snapshot falls back to narration keywords when the classifier has not been run, so a bare cleaned statement still renders income, EMIs and balance trend. Running the classifier improves precision but is not a prerequisite — useful when you are triaging a large number of files quickly.
Multiple accounts can be merged into one continuous ledger before the snapshot is computed, so a borrower who splits salary and EMIs across two banks is still read correctly, with cross-statement duplicates flagged rather than double-counted.
Frequently asked questions
Is the borrower's statement uploaded anywhere?
No. Analysis runs entirely in your browser. This matters for lending, where handling borrower financial data through a third-party server creates data-protection exposure that on-device processing simply avoids.
How is FOIR calculated?
Detected fixed obligations — EMI and loan outflows, grouped per counterparty and averaged monthly — are divided by detected monthly income from salary credits. The result is colour-tagged against the ceiling most lenders apply: at or below 40% comfortable, 40 to 50% borderline, above 50% over.
Can it detect a tampered or forged statement?
It detects arithmetic inconsistency. If figures have been edited, the recomputed running balance stops matching the printed balance and the file is flagged. It cannot detect a forgery where every balance was recalculated consistently, so treat a clean pass as one signal among several, not as verification.
Can I analyse several months or accounts at once?
Yes. Upload multiple statements and merge them into a single chronological, de-duplicated ledger before computing the snapshot. Each row keeps its source bank and file.