The Statement That Parses Incompletely Is Worse Than the One That Fails

Bank statement format coverage is a fraud control, not a convenience feature. A statement that fails to parse goes to manual review, where the tamper checks never run. A statement that parses incompletely is worse: it produces a complete looking analysis built on a subset of the data, and nothing in the output says so. Published format counts measure neither problem. Your own rejected files do.

Format coverage is usually discussed as a procurement checkbox: how many bank formats does the tool support, with a number in the hundreds or thousands attached. It is a weak way to think about the problem, and it misses where the actual risk sits.

A statement that fails to parse is a nuisance. It announces itself, someone deals with it, and the cost is time. A statement that parses incompletely is a credit risk, because the analysis looks finished when it is not.

Trace what actually happens to a file that will not parse

The failure is not a technical event. It is an operational one with a predictable chain.

The file arrives at a credit operations desk. Someone opens it, reads it, and keys the figures into a spreadsheet. More commonly they key the summary figures and skip the transaction detail, because transcribing 400 transactions by hand is not a thing that happens at volume. The analysis proceeds on monthly totals and an eyeballed read of the conduct.

That file has now bypassed every control the institution built. No categorisation, so no obligation discovery and no related-party netting. No tamper verdict, so no balance-trail reconciliation and no metadata check. No bounce classification, so the distinction between the borrower's own dishonoured cheques and deposits that came back is lost. The borrower's file looks like every other file in the system, and the exception is invisible once the figures are entered.

Two consequences follow, and the second is the one that matters.

Turnaround time. Manual handling adds hours to days per case, concentrated in the segments where it is hardest to afford.

Fraud exposure. Manual review at volume is where tampering survives. The forensic checks that catch an edited amount (balance-trail reconciliation across page boundaries, font and rendering inspection, metadata anomalies) are mechanical tests nobody performs by hand on a Tuesday afternoon with eleven files pending. A statement that routes to manual review is a statement where the tamper controls did not run.

Format coverage is therefore a fraud control, not a convenience feature. That is the inversion worth making.

The partial parse is the real problem

Hard failures are visible. The file errors out, someone handles it, the institution knows it happened.

Partial parses are silent, and they are more common. Specific failure modes:

Dropped transactions. A continuation page with a header the parser does not recognise is skipped. The analysis runs on 360 of 400 transactions and reports a clean result. The 40 missing transactions are not randomly distributed. They are whatever sat on that page.

Truncated narration. Multi-line narration that wraps is read as the first line only. NEFT-CR-HDFC0001234-SRI LAKSHMI AGRO TRADERS-... becomes NEFT-CR-HDFC0001234, and the counterparty is gone. The transaction is categorised as a generic transfer, which means concentration cannot be computed and circular flows cannot be detected, the exact related-party analysis that depends on counterparty resolution.

Column misalignment. Debit read as credit, or a continuation balance column read as a transaction amount. This one is usually caught by the balance trail if the trail is checked, and silently catastrophic if it is not.

Date misparsing. DD/MM read as MM/DD on a statement that uses an unexpected format, which scrambles the monthly series. Every month-on-month reading in the analysis is then wrong while every total remains correct.

Opening balance assumed. A statement whose opening balance sits in an unrecognised position is inferred from the first transaction rather than read, which shifts the entire balance series by a constant.

None of these produces an error. Each produces a confident, plausible, wrong analysis. This is why a parse should be followed by explicit completeness assertions rather than treated as successful because it did not crash.

One check catches more of these than any other: the closing balance must reconcile from opening plus credits minus debits across every page boundary, not just for the document as a whole.

A tool that cannot show these checks has not demonstrated that the parse succeeded, only that it completed.

Why the published format count is a weak metric

Vendors publish coverage figures that run from around a hundred banks to more than four thousand formats, sometimes counting banks outside India. The numbers are not comparable and not especially meaningful, for four reasons.

No disclosed denominator. India has close to two thousand banks once cooperative banks and regional rural banks are counted (more than 1,450 urban cooperative banks alone, per the RBI), and each issues multiple statement variants: net banking export, branch print, scanned, mobile app, legacy core banking migration. Nobody publishes what they count as one format, so 850 and 4,000 may describe the same coverage or wildly different coverage.

No weighting by volume. Supporting 400 formats that cover 95% of your applications is better than supporting 2,000 that cover 80%. The distribution of your own book is the only weighting that matters, and it is not the vendor's distribution.

No distinction between parsed and parsed well. "Supported" can mean the transactions come out with full narration, confidence and position, or it can mean the file does not error. These are different claims presented identically.

Formats change. A bank migrates core banking systems and its statement layout changes. A count is a snapshot; what matters is how quickly a new variant is handled when it appears, and that is a process question rather than a number.

That applies to our own published figure of 1000+ banks as much as to anyone else's. The useful question to any vendor, us included, is not how many formats they support. It is: here are forty files our current tool rejected or mangled. What happens to these?

What actually makes a format hard

Worth being specific, because this is where the engineering difficulty genuinely lives and where generic claims fall apart.

Scanned statements with skew, shadow, variable resolution and compression artefacts, particularly branch-printed statements photographed rather than scanned.

No running balance column. Some formats omit it, which removes the single most reliable integrity check available and forces reconstruction from transaction order.

Multi-line wrapped narration, where a single transaction's description spans two or three rows and must be reassembled before classification.

Continuation and summary rows interleaved with transactions (brought-forward balances, page subtotals, month dividers) which look like transactions and are not.

Regional language headers, or mixed-script narration.

Password-protected PDFs, routine for net banking exports.

Mobile app exports and screenshots, increasingly common and structurally different from a statement export.

Bank-specific transaction abbreviations. Every bank has its own vocabulary, and a code that means one thing at one institution can mean something else elsewhere. Resolving these correctly is the categorisation problem, and it is where tools diverge most. We measured the spread across 200,001 transactions.

Statements spanning a core banking migration, where the layout changes mid-document.

The segments that get skipped, and why it is commercially expensive

Format coverage decisions are economic. Building and maintaining a parser for a bank that appears in 200 applications a year is harder to justify than one that appears in 200,000, so the long tail gets deprioritised: cooperative banks, small finance banks, regional rural banks, and older institution-specific layouts.

That is precisely the tail that matters most for where lending is growing. Semi-urban and rural markets now account for more than 58% of NBFC loans by volume, according to FIDC and TransUnion CIBIL, and the borrowers there frequently bank with exactly the institutions that get skipped. A lender expanding into Tier 2 and Tier 3 geographies with a tool tuned to large private bank formats will find its rejection rate rising in the segment it is trying to grow.

The Account Aggregator path has gaps of its own, and they fall in much the same place. Bank data on AA covers savings accounts and, at some banks, sole proprietor current accounts; current accounts held by partnerships, companies and LLPs are not covered at all. Cooperative banks are almost absent: in Sahamati's September 2025 review, two of roughly 1,500 urban cooperative banks were live as data providers, and no state or district cooperative bank was. Regional rural banks, by contrast, are well connected. That is one reason AA is an additional channel rather than a replacement, and why document-based capability has to be maintained regardless.

How to test coverage on your own book

Three steps, and none of them involve a vendor's format list.

1. Measure your current rejection rate, segmented. Not the blended figure. By bank category (large private, public sector, small finance, cooperative, regional rural) and by borrower segment. Most institutions have never computed this, and the blended number conceals the problem because large-bank files dominate the volume.

2. Keep your rejects. Every file that failed to parse or required manual handling over the last quarter is your real test set, and it is the only one that represents your actual difficulty distribution. A vendor evaluation run on files that already parse tests nothing.

3. Test for partial parses, not just failures. On twenty files that parsed successfully, reconcile the output transaction count and closing balance against the source document by hand. This is the check almost nobody runs, and it is where silent errors surface. A tool with a low rejection rate and a high silent-partial rate is worse than one that rejects honestly.

That third step belongs in any tool evaluation, and it is the one most likely to change the result.

The honest position

Full coverage of every Indian bank format is not a credible claim from anyone, and a vendor asserting it should be asked about the last format they could not handle.

What is a credible claim is this: a defined completeness check on every parse, an explicit and visible failure when a document cannot be read reliably, and a turnaround commitment for a new format when one appears. A tool that admits it cannot read a file leaves the institution with a known exception to handle. A tool that reads it incompletely and reports success leaves the institution with a credit decision built on partial data and no indication that anything went wrong.

The first is an operational cost. The second is a loss nobody attributes correctly, because the file looked fine.

Frequently asked questions

How many bank statement formats exist in India? There is no authoritative count. With close to two thousand banks including cooperative banks and regional rural banks, each issuing several statement variants (net banking export, branch print, scanned, mobile export), the realistic number runs into the thousands and changes as banks migrate core banking systems. Published vendor counts use undisclosed definitions and are not comparable.

What happens when a bank statement cannot be parsed? It routes to manual handling, where figures are typically keyed in at summary level. That file bypasses categorisation, obligation discovery, tamper detection and bounce classification, and the exception becomes invisible once the numbers are entered.

Why is a partial parse more dangerous than a parsing failure? A failure is visible and gets handled. A partial parse (dropped continuation pages, truncated narration, misaligned columns, misread dates) produces a complete looking analysis on incomplete data, with nothing in the output indicating that anything is missing.

How do you verify that a statement parsed correctly? Reconcile the output transaction count and page count against the source, confirm date continuity, check that the opening balance was read rather than inferred, and verify that the closing balance reconciles from opening plus credits minus debits across every page boundary.

What makes a bank statement format hard to parse? Scanned or photographed pages, formats with no running balance column, narration that wraps across several lines, page subtotals and brought-forward rows that look like transactions, password protection, mobile app exports and screenshots, bank-specific abbreviations, and statements that span a core banking migration with a layout change midway.

How should a lender test a vendor's format coverage? With the files the current tool rejected or mangled over the last quarter, not a sample that already parses. Measure the rejection rate by bank category, then reconcile transaction count and closing balance by hand on twenty files that parsed successfully, to catch silent partial parses.

Does Account Aggregator eliminate format problems? On the paths where it is available, yes. The data arrives structured, with nothing to parse. But coverage is incomplete: current accounts of partnerships, companies and LLPs are not available through AA, and cooperative banks are largely absent as data providers. Lenders serving business borrowers and semi-urban and rural segments need document-based capability alongside it.

---

Fiscus reads scanned, native and screenshot statements across banks and formats, with every field carrying page, position and confidence, and flags documents it cannot read reliably rather than reporting a partial result as complete. Book a parallel evaluation using the files your current tool rejected.