The Bank Statement Analyser Was Named After Its Easy Part

A bank statement analyser (BSA) is software that turns a borrower's bank statements, uploaded as PDFs or fetched through the Account Aggregator framework, into categorised transactions and credit metrics: income, obligations, balances, bounces and fraud flags. Banks and NBFCs use it to underwrite loans and, increasingly, to monitor them after disbursal. In Indian lending, BSA means this, not the US Bank Secrecy Act.

That is the definition. The more interesting point is where the name came from.

In the early 2010s, getting numbers off an Indian bank statement was genuinely hard.

Close to two thousand banks counting the co-operative sector, no standardisation, scanned pages from small branches, PDFs with text layers that lied about what was on the page, column structures that changed between two statements from the same bank. Solving that took real engineering, and the companies that solved it built substantial businesses on it. The category took its name from what they did: bank statement analysers.

That problem is now largely solved. Extraction above 99% on native PDFs is routinely advertised and rarely where a credit file goes wrong. Account Aggregator removes the problem entirely on the paths where it is available, delivering schema-defined structured data with nothing to parse at all.

The category is still named after it, and still largely bought on it. That mismatch is the subject of this post.

What actually got solved, and what did not

It is worth being precise about the layers, because the word "accuracy" is doing a lot of concealing.

Extraction asks whether the tool read the page correctly. Solved, commoditised, and still the number most prominently quoted.

Categorisation asks whether each transaction was assigned the right class. Not solved. This is where tools actually diverge, and the divergence is large: we published a head-to-head across 200,001 transactions on identical raw data showing 92.8% against 80.3%, which inverts to 64% fewer misclassifications.

Interpretation asks whether the categorisation preserved the credit signal. A transaction labelled "Transfer from ABC Enterprises" is not incorrect. It is empty. It passes a naive correctness check, it is counted as a success in most accuracy measurements, and it tells an underwriter nothing. Without the counterparty resolved, concentration cannot be computed, circularity cannot be detected, and a lost customer is invisible.

Monitoring asks whether any of this continues after the loan is disbursed. For most tools it does not, for reasons covered below.

A tool can be excellent at the first layer and poor at the third, and the figure on the datasheet describes the first.

Three things the original category design assumed

The architecture of a bank statement analyser encodes assumptions about how lending works. Three of them have stopped holding.

That the question is answered once, before sanction

The original design is one-shot: borrower applies, statements arrive, analysis runs, decision is made, file closes. Everything in the product follows: batch processing, a report as the output artefact, a pricing model per case.

But the same data answers questions that arrive much later. Whether utilisation is creeping toward the limit. Whether EMI timing is drifting later each month before any failure occurs. Whether related-party inflows are rising as a share of credits, meaning the promoter has started funding operations. Whether a top buyer has disappeared. These are the mid-sequence early warning signals, and they appear months before DPD registers and before bureau data reflects anything. RBI's fraud risk management directions for commercial banks, reissued on 31 July 2026, already expect an early warning system whose indicators include the transactional data of accounts, with alerts examined preferably within 30 days. A tool that stops at sanction cannot feed one.

The same data also answers the collections question. Sequencing a delinquent book by days past due treats two borrowers at 45 DPD identically when one has a presentation-date mismatch and the other has a dead account, a distinction visible in the account and absent from the bucket, as set out in our post on capacity and intent.

A one-shot tool cannot serve these. Not because it lacks a feature, but because continuous monitoring requires a different consent design, a different data cadence and a different output. The Account Aggregator ecosystem makes the separation explicit. Sahamati's fair use templates treat underwriting, monitoring and collections as three separate consents:

Sahamati's guidance is not to combine them under a single consent. A lender who takes only the one-time underwriting consent discovers after disbursal that they cannot look again, and going back to a stressed borrower for fresh consent is close to impossible. The monitoring consent has to be requested at origination, when the borrower is still motivated to grant it.

That one model fits every borrower

Most categorisation logic was built for the salaried borrower first, because that is where volume and standardisation are, then stretched to cover business segments.

It does not stretch. For a salaried applicant income is a single verifiable credit; for a business it is a figure that must be derived by subtraction. The personal-business boundary does not exist for a sole proprietor. Behaviour that is normal in one segment is diagnostic in another: a round-figure credit is routine inter-company settlement for a corporate and a circular-funding indicator for a micro-enterprise.

And some distinctions carry far more weight in business accounts. Indian banks name cheque returns from their own side of the clearing. An outward return is a cheque the borrower deposited that came back unpaid, which means the borrower's customer failed to pay. An inward return is the borrower's own cheque dishonoured. Punjab & Sind Bank's charges schedule defines them exactly this way. Many systems record both simply as "bounce", which penalises a borrower for their debtor's default and discards one of the earliest available indicators that a business's customers are in trouble. Some downstream feeds label them from the borrower's side instead, which reverses both, so the convention has to be established before any rule is wired to the field. The full set of segment differences is longer than most vendors acknowledge.

That the statement is the whole picture

A statement can only describe the accounts you were given. A borrower with five accounts can share three, and a clean structured feed from three accounts looks more complete than three PDFs do.

Coverage is a second boundary. Sahamati lists 176 financial information providers live on the Account Aggregator network as of October 2026, a figure that includes providers other than banks, against close to two thousand banks in the country. Statements from the rest still arrive as documents.

What catches the gaps is cross-verification. Declared GST turnover against banked credits, normalised properly, produces a residual that frequently reveals an account you were never shown, or a receivables collection failure invisible in either source alone. The method matters more than the comparison: a naive gross-to-gross check routinely points in the wrong direction, because aggregate turnover under section 2(6) of the CGST Act excludes tax while bank credits include it.

What the replacement actually requires

Not "AI", which has become a content-free claim in this market. Specifically:

Counterparty resolution on every transaction, not a narration string echoed back with a category prefix. This is the prerequisite for concentration analysis, related-party netting and circularity detection, and it is the capability that most separates outputs.

Segment-native logic. Distinct taxonomies, ratio sets and fraud rules per borrower type, rather than one ruleset with more entries.

Multi-account consolidation with both legs matched. Four accounts analysed separately and summed double-count every rupee of internal movement, and the inflation scales with how actively the borrower manages money across accounts.

Provenance. Every flag traceable to the page and line that produced it. A risk score with no attached evidence cannot be resolved by an analyst, only argued about.

Continuity. The same analysis running after disbursal as before it, on consent designed for the loan's tenure rather than the application window.

Multi-source. Banking, GST and bureau read together, with the residual between them treated as a signal in its own right. RBI's Unified Lending Interface, announced for national rollout in August 2024, rests on the same premise: consented data from many sources reaching the lender through standard interfaces. ULI moves the data. Interpreting it remains the lender's problem.

What has not changed, and will not

A category argument that claims everything is solved is a sales pitch. Several things are genuinely hard and remain so.

Some Indian bank narrations are truncated to a length that carries no recoverable information. In our own benchmark, 3.8% of transactions defeated both tools. A ₹5,000 debit narrated only as DOCUMENTATION C cannot be categorised correctly by anyone, and the right output is a low-confidence flag rather than a confident wrong answer.

Cash remains invisible, which matters most in exactly the segments where cash is most used.

A statement is a flow record. It says nothing about what the borrower owns, what security exists, what contingent liabilities are accruing, or whether the customers behind the credits are themselves solvent.

And the decision remains human. Better inputs make better judgment possible; they do not produce it.

The disclosure that belongs here

This is a vendor arguing that the category it competes in should be defined differently, which is a familiar move and deserves the obvious discount.

What makes it checkable rather than rhetorical is that the claims are testable on your own files in about a week. Assemble twenty to thirty of your own closed cases, weighted to your actual segment mix and including some that went bad. Run your incumbent and any candidate on identical raw inputs. Score only the disagreements, adjudicated by your analysts rather than either vendor. Then segment the errors by category (loan disbursals, EMI outflows, bounce charges, income credits) rather than reporting a single percentage.

The full evaluation protocol is published, including the questions that are difficult to answer convincingly without the underlying capability existing. If a vendor declines to run against an incumbent on live files, that is itself a finding.

The short version

The bank statement analyser solved a real problem and was named after it. The problem became a commodity. What remained (interpreting transactions correctly, reading the account differently for different borrowers, continuing past the sanction date, and checking the statement against sources outside it) is harder, less visible on a datasheet, and determines whether the output is a categorised list or a credit view.

Buying on extraction accuracy in 2026 is buying on the part that no longer differentiates anything.

Frequently asked questions

What is a bank statement analyser? Software that turns a borrower's bank statements, uploaded as PDFs or fetched through Account Aggregator, into categorised transactions and credit metrics such as income, obligations, balances, bounces and fraud flags. Banks and NBFCs use it to underwrite loans and to monitor them after disbursal. The term dates from a period when extraction itself was the difficult part.

What does BSA stand for in lending? In Indian lending, BSA stands for bank statement analysis or bank statement analyser, the software and process of reading a borrower's statements for credit assessment. It is unrelated to the US Bank Secrecy Act, which shares the abbreviation.

Is extraction accuracy a useful way to compare tools? Not any more. Vendors routinely advertise above 99% on native PDFs, and Account Aggregator removes the problem on paths where it is available. Categorisation accuracy is where tools diverge, and it is rarely published with a disclosed methodology. In our benchmark on identical data the two tools scored 92.8% and 80.3%.

What should a bank statement analysis tool do beyond categorising transactions? Resolve counterparties explicitly, apply distinct logic per borrower segment, consolidate multiple accounts with internal transfers netted on both legs, attach provenance to every flag, continue running after disbursal for monitoring, and cross-verify against GST and bureau data.

Does Account Aggregator make bank statement analysis unnecessary? No. AA replaces collection and extraction. Categorisation, income derivation, obligation identification, fraud detection and conduct analysis all still have to be performed, and none of them become easier because the input arrives as structured data. AA coverage is also partial: 176 financial information providers were live as of October 2026, so many statements still arrive as documents.

Can a lender keep reading a borrower's account after disbursal? Only on a consent designed for it. Under Sahamati's fair use templates, underwriting uses a one-time consent (purpose code 103) valid for a month, while monitoring needs a separate periodic consent (purpose code 104) that can run for the loan tenure, up to five years. It should be requested at origination.

Can a tool built for salaried borrowers be used for SME lending? Not without systematic error. Income must be derived rather than verified, the personal-business boundary differs, behaviour that is normal in one segment is anomalous in the other, and distinctions such as a returned deposit versus the borrower's own dishonoured cheque carry far more weight in business accounts.

---

Fiscus analyses banking data across salaried, self-employed and SME borrowers, from origination through the life of the loan, with counterparties resolved, bureau cross checks built in and GST benchmarked alongside, and every output traceable to the transaction behind it. Book a parallel evaluation on cases your team has already assessed.