How Do You Detect a Fake or Tampered Bank Statement?

Run four checks in order: read the PDF's metadata and producer string, test whether the running balance foots line by line, look for font and spacing breaks inside a single row, and then verify the statement against the bank itself. The first three catch amateurs. Only the fourth is conclusive.

Key facts

• Advances-related fraud is where the money is. The RBI reported 10,114 fraud cases involving ₹48,021 crore in FY2025-26, of which 84.9% by value — ₹40,774 crore — sat in the advances category, up 34.3% year on year (Reserve Bank of India, *Annual Report 2025-26*, 29 May 2026). Loan fraud is a documents problem before it is a collections problem.
• YuSight's Bank Statement Analyzer extracts at 95.2% accuracy against a manual benchmark, with every transaction traced back to the source page — which matters here because a footing test is only as good as the numbers you fed it.
• Consent-based source data is now mainstream in India. The Account Aggregator ecosystem showed 2.88 billion accounts enabled and 1.97 billion consents raised as at June 2026, across 17 AAs, 176 FIPs and 1,076 FIUs (Sahamati, RBI-recognised SRO for the AA ecosystem).
• And in the UK. Open banking passed 15.1 million active users and over 2 billion API calls in a single month (July 2025) — roughly one in three UK adults (Open Banking Limited, 2 September 2025).
• A doctored statement usually breaks in exactly one place. In the worked example below, a single altered balance line inflates the average daily balance by 67,742 units and passes every check except arithmetic.

Why does this land on the credit analyst rather than a forensics team?

Because by the time a forensic examiner sees the file, the loan is already on the books. The analyst is the only person who reads the statement while the decision is still open, and the analyst is working with a PDF, a spreadsheet and about twenty minutes.

So the tests below are the ones a credit person can actually run. None of them require a lab. All of them are things a determined forger can defeat if they are patient enough — which is why the last section exists.

What does PDF metadata tell you about a bank statement?

Every PDF carries a document information dictionary and, usually, an XMP metadata packet. Four fields do most of the work.

Two practical warnings.

Absence of metadata is not proof of anything. Plenty of legitimate banks strip metadata, and plenty of legitimate borrowers re-save a statement to compress it before emailing. A stripped producer string is a prompt to look harder, not a rejection.

Presence of clean metadata is not proof of anything either. Metadata is trivially editable. A forger who knows what a /Producer field is will set it correctly. Treat metadata as a cheap first filter that catches the careless, and nothing more.

The same logic applies to the digital signature. Many banks now sign statements. A valid signature that chains to the bank's certificate is genuinely strong evidence. An invalid or missing signature tells you very little, because signatures break on ordinary re-saves.

How do you spot font and rendering inconsistency?

This is the single most reliable visual test, and it works because editing a PDF text layer almost never reproduces the original typesetting exactly.

Look for these, inside one row rather than across the page:

• A mixed font within a single amount. The digits "2" and "1" rendered in one face, "2,000.00" in another. Zoom to 400% and the difference is usually obvious.
• Kerning that changes mid-number. Genuine statement engines set every amount in the same monospaced or tabular-figure font with identical inter-character spacing. An edited amount frequently has one character pair sitting a fraction too close or too far.
• Baseline drift. The edited amount sits one or two points higher or lower than its neighbours in the same row.
• Right-edge misalignment in the amount column. Statement engines right-align on a fixed decimal position. Edited numbers drift by a pixel or two.
• A different black. Original text is usually pure black or a specific greyscale value; replacement text pasted from another application may carry a slightly different colour value.

There is a related check for statements that claim to be system-generated. If the file is a "digital" statement, there should be no image layer over the transaction table at all. Text should be selectable, searchable and copyable. If you can select the header and the footer but the transaction block comes out as an image — or if a single row is an image while its neighbours are text — someone rasterised an edit to hide the font mismatch. That is close to conclusive.

Watch for the reverse too: a genuinely scanned statement that is uniformly an image is normal. A scanned statement in which one row is sharper than the rest, or has a different JPEG compression signature, has had a patch pasted in.

Why does the running balance test catch most tampering?

Because a forger has to edit two things consistently — the transaction amount and every balance after it — and most do not.

Here is a real-shaped example. A borrower submits a March statement to support a working capital limit. Opening balance 486,210.00.

Now foot it, line by line. Prior balance, plus credit, minus debit, equals stated balance.

04 Mar: 486,210.00 + 128,400.00 = 614,610.00 stated 614,610.00 ✓ 07 Mar: 614,610.00 − 96,750.00 = 517,860.00 stated 517,860.00 ✓ 11 Mar: 517,860.00 − 212,000.00 = 305,860.00 stated 405,860.00 ✗ +100,000.00 14 Mar: 405,860.00 + 74,500.00 = 480,360.00 stated 480,360.00 ✓ 18 Mar: 480,360.00 − 63,180.00 = 417,180.00 stated 417,180.00 ✓ 22 Mar: 417,180.00 + 155,000.00 = 572,180.00 stated 572,180.00 ✓ 27 Mar: 572,180.00 − 41,900.00 = 530,280.00 stated 530,280.00 ✓

Exactly one line fails, by exactly 100,000.00. Everything after it re-foots perfectly, because the forger changed the 11 March balance and then let the rest of the column compute forward from the doctored figure. That signature — one break, clean arithmetic on both sides of it — is what a manual edit looks like. Random OCR noise does not behave that way; it produces scattered small errors, not one round number.

What did it buy the borrower? The true closing balance is 530,280.00 − 100,000.00 = 430,280.00. And because the inflation runs from 11 March to 31 March, that is 21 of the month's 31 days:

Average daily balance overstatement = 100,000.00 × (21 ÷ 31) = 67,741.94

On a lender that sizes an overdraft at four times the average daily balance, that single edited cell is worth roughly 270,968 of extra limit.

Three more arithmetic checks belong alongside the footing test:

1. Page carry-forward. The closing balance on page 3 must equal the opening balance on page 4. Statements are edited page by page, and this is where the seam shows.
2. Summary block versus transactions. Most statements print total debits, total credits and closing balance in a header or footer. Re-add the transaction column and compare. A forger who edits the table often forgets the summary.
3. Period totals versus the interest or charges line. Ledger interest credited on a current account, or overdraft interest debited, should be broadly consistent with the balances actually held. A statement showing large sustained balances and negligible ledger interest is internally inconsistent.

What behavioural patterns suggest a fabricated statement?

Fabrication — building a statement from scratch rather than editing a real one — leaves a different fingerprint. It is a distribution problem, not an arithmetic one.

• Round numbers cluster. Real business receipts are 128,437.60, not 128,000.00. Count the transactions ending in "000.00". In a genuine trading account that share is usually low; in a fabricated one it is often a third or more. A high share is a flag, not a finding — cash-heavy retail and round-lot wholesale genuinely produce round amounts.
• Ordering anomalies. Transactions on the same date should carry a value-date and, in most systems, a stable within-day sequence that never runs backwards. A row dated 14 March sitting between two rows dated 18 March is a paste.
• Weekend and holiday clearing. NEFT, RTGS and cheque clearing entries dated on a bank holiday, or a salary credit on a Sunday, are worth a question.
• Reference numbers that do not follow the bank's format. UTR, cheque and transaction reference numbers have fixed lengths and structures per bank. One short reference in a column of correct ones is a paste.
• Counterparty names that never repeat. A genuine operating account has a recurring cast — the same three suppliers, the same utility, the same payroll batch. Fabricated statements tend to be a long list of one-time names.
• Suspiciously smooth balances. No account ever goes overdrawn, no charge is ever levied, no cheque ever bounces, and the balance never dips below the number the credit policy needs. Real accounts are messy.
• The narration vocabulary is too narrow. Real statements carry a wide mix of channel codes, truncated merchant strings and system abbreviations. Fabricated ones read like someone typed them.

None of these is decisive alone. Two or three together, in a file where the arithmetic also breaks, is a decline.

What is the strongest control, and why is it not a detector?

Verify against the source. Everything above is inference from a document the borrower controls. Source verification removes the borrower from the chain entirely.

There are four practical routes, and which one you use depends on your market:

There is a related control worth naming: reconcile the statement against a second, independent source. Compare the EMI debits on the statement against the trades on the bureau report — every serviced loan on the bureau should have a matching debit, and every regular EMI-shaped debit should have a matching bureau trade. A borrower who doctors a bank statement rarely thinks to reconcile it against a bureau file they cannot edit. The method is set out in bureau report analysis for credit teams.

Be honest about what this means. No document-level detector is complete. A patient forger with a decent PDF editor, a correct producer string, consistent fonts, footed arithmetic and plausible counterparties will pass every test in this article. The detectors raise the cost of fraud; they do not eliminate it. The only control that removes the borrower from the evidence chain is data that never passed through the borrower's hands.

How should a lender sequence these checks?

Run them cheapest-first, and stop when you have enough.

1. Source check. Can you get this account through AA, open banking or a bank fetch? If yes, do that and skip most of what follows.
2. Automated footing and carry-forward. Machine work. Every line, every page seam, every summary block.
3. Metadata and layer inspection. Producer, dates, incremental updates, whether the transaction table is text or image.
4. Visual inspection at 400% on the rows the footing test flagged, plus a random sample of five rows it did not.
5. Cross-source reconciliation. Bureau trades versus EMI debits; GST or VAT filings versus credit turnover; declared salary versus payroll debits.
6. Ask the borrower. A genuine borrower with a re-saved PDF explains it in one call and re-sends from net banking. A fabricator negotiates.

Where the statement sits in the wider file — and why the bank statement check belongs at document collection rather than at credit memo stage — is mapped in the complete guide to commercial loan underwriting in US banks. And once the statement is trusted, it becomes the basis of the cash flow work, including the household spend used in global DSCR for SBA 7(a) loans.

Steps 2 and 5 are where automation earns its place. Footing 900 transactions across twelve months and four accounts is not analyst work, and an analyst doing it by eye will miss the one line that breaks. Once the transactions are extracted with page-level citation, the arithmetic tests are deterministic — and the analyst's twenty minutes goes to step 6, which is the only step that requires judgement. That extraction and citation discipline is the same one described in what financial spreading is, and the audit trail it leaves is what an examiner asks for when reviewing an AI-drafted credit memo.

FAQ

How do you detect a fake bank statement?

Foot the running balance line by line, check that each page's closing balance carries into the next page's opening balance, read the PDF's producer and modification metadata, and zoom in on the amount column looking for font or alignment breaks inside a single row. Then verify the account against the bank through an aggregator, open banking or a net-banking fetch.

What PDF metadata reveals tampering?

The /Producer and /Creator strings tell you which application wrote the file — a desktop PDF editor where you expected a bank's statement engine is a flag. A ModDate later than the CreationDate means the file was saved again after it was made, and multiple incremental update sections mean it was saved more than once. All of these are editable, so treat them as prompts to look harder, not as proof.

Can a doctored statement pass an OCR check?

Easily. OCR reads whatever is on the page and has no opinion about whether it is true. A cleanly edited PDF gives OCR perfect text, which is exactly why OCR accuracy and fraud detection are different problems. What catches the edit is the arithmetic run on top of the extracted numbers, not the extraction itself.

Is a missing digital signature enough to reject a statement?

No. Signatures break on ordinary re-saves, compressions and email gateway processing, and many banks do not sign statements at all. A signature that validates against the bank's certificate is strong positive evidence. Its absence is close to neutral.

What does it mean when only one line fails to foot?

It usually means a manual edit rather than an extraction error. A forger changes one balance and lets the column compute forward from it, so exactly one line breaks and everything on both sides of the break is arithmetically clean. Extraction noise looks different — small scattered errors across many lines, not one round discrepancy.

Do round-number transactions mean the statement is fake?

Not on their own. Cash-heavy retail, wholesale round-lot trading and inter-company transfers all produce genuinely round amounts. What matters is the share: if a third of a trading account's credits end in three zeros and the counterparty names never repeat, that is a pattern worth challenging.

Does Account Aggregator data remove the need for statement analysis?

It removes the need to authenticate the statement, not the need to analyse it. You still have to classify transactions, identify undisclosed borrowings, compute average balances and test turnover against filings. What you no longer have to do is prove the borrower did not edit the file.

What should you do when a statement fails one check but passes the rest?

Ask, before you conclude. Re-request the statement directly from net banking or through an aggregator and compare the two. A genuine borrower resolves it in a call; the discrepancy either disappears or gets a coherent explanation. If it does neither, document the finding and treat it as a credit decision, not a technical one.

Key takeaways

• Footing the running balance line by line catches more tampering than any other single check, and it is deterministic — either the arithmetic works or it does not.
• Page carry-forward is where multi-page edits break. Check every seam, not just the first page.
• Metadata is a cheap filter that catches the careless. It proves nothing in either direction.
• A "digital" statement whose transaction table is an image, or whose single row is an image, has been rasterised to hide an edit.
• Fabricated statements fail on distribution — round numbers, non-repeating counterparties, no charges, no dips — rather than on arithmetic.
• No document test is conclusive. Source data through Account Aggregator, open banking or a bank fetch is the only control that takes the borrower out of the evidence chain.
• Reconciling statement debits against bureau trades catches the fraud that edits the one document the borrower controls and forgets the one they do not.

Automate the arithmetic. Spend the analyst's time on the conversation.

Run one borrower through the analyzer — [book a live demo](https://yuverse.ai/yusight).