What to Check Inside a Bank Statement: A Field-by-Field Verification Checklist

There are two different questions you can ask about a bank statement. The first is "is this fake?" - and we have answered that one at the technique level in the seven forensic signals reviewers miss. The second is "what do I actually look at, and in what order?"

This guide answers the second. It walks the document top to bottom, region by region, and for each one sets out what to check, what fraud characteristically lands there, and - importantly - the point at which a manual check stops being reliable. That last part matters, because a checklist that does not tell you its own limits will make you confident about documents you should not be confident about.

Why region-by-region beats a general smell test

The defining property of a tampered bank statement is that almost all of it is real. A forger starts from a genuine statement - often their own - and changes a balance, inserts a few deposits, or edits an employer's name in a transaction description. Ninety-five percent of the pixels are untouched and perfectly authentic.

This is why "does it look right?" fails so reliably. It does look right, because it mostly is right. A strong local signal gets averaged away into a weak global impression.

Checking by region inverts that. You are no longer asking whether the document feels genuine; you are asking whether this specific field is consistent with the fields around it. That is a question with an answer.

Zone 1: The header block

The top of the statement: bank name, logo, registered address, and any branding furniture.

What to check

• Logo resolution against the rest of the page. A logo lifted from a website and pasted into a template is frequently a different effective resolution from the text around it. Zoom to 400% - a genuine logo rendered by the bank's own system will be vector-crisp or scan-consistent with neighbouring text, not visibly softer or harder.
• Registered address and legal entity name. Check them against the bank's current published details. Templates circulating online are often years stale and carry a superseded address, an old brand name from before a merger, or a regulator reference number that has since changed.
• Branding consistency with the period claimed. A statement dated in the last quarter carrying a logo the bank retired two years ago is a template age problem, not a design quirk.

Where this check stops working. Logos are trivially easy to source at high quality, and a competent forger uses the current one. Clean branding is not evidence of authenticity - it is only the absence of a specific, careless mistake.

Zone 2: The account identity block

Account holder name and address, account number, and the routing identifier - sort code, IFSC, BSB, or routing number depending on jurisdiction.

What to check

• Routing identifier validity. Sort codes, IFSC codes, and BSB numbers follow published formats and, in most jurisdictions, are publicly searchable. An IFSC code should resolve to a real branch, and that branch should be plausible for the account holder's stated address. This is one of the few checks in this guide that produces a hard yes or no.
• Account number checksum, where the scheme has one. Several national schemes embed a check digit. Where one exists, it costs nothing to validate and catches numbers invented rather than copied.
• Name and address rendering versus the rest of the document. The account holder block is the single most commonly edited region on a statement, because it is how one person's genuine statement becomes another person's evidence. Look hard at character spacing and baseline alignment here relative to the header above it.
• Masking consistency. If the bank masks the account number (****4471), it should be masked identically everywhere it appears - summary box, page footer, every page. Partial masking in one place and full digits in another usually means two different sources were combined.

Zone 3: The summary box

The opening balance, closing balance, total credits, total debits, and the statement period.

This is the highest-value region in the document, because it is both the number the decision usually turns on and the number with the most constraints on it.

What to check

• The core identity. Opening balance + total credits − total debits = closing balance. Compute it. This single arithmetic check catches the most common form of tampering: inflating a deposit without correcting the totals.
• The summary against the ledger. Total credits in the summary box must equal the sum of every credit in the transaction table. Same for debits. Forgers who remember to fix the closing balance routinely forget that the totals are independently derivable from the rows.
• Statement period against the first and last transaction dates. A statement covering 1 March to 31 March whose transactions run to 2 April is either a fabricated period label or a spliced document.
• Closing balance against the final row's running balance. These are two separate places the same number appears. They must match exactly.

Where this check stops working. A competent forger recalculates. The whole point of the summary-versus-ledger cross-check is that it forces them to be consistent in four places at once rather than one - but a careful one will be. Arithmetic that passes is meaningful evidence; arithmetic that fails is close to conclusive, but the converse does not hold.

Zone 4: The transaction ledger

The table itself. This is where most of the document is, and where most of the checkable structure lives.

The running balance chain

Every row carries a running balance, and the delta between consecutive rows must equal that row's transaction amount, exactly:

row[n].balance − row[n−1].balance = row[n].credit − row[n].debit

Walk it. Every row, not a sample. This is the check that catches insertions - a transaction added between two existing rows breaks the chain at the insertion point even when the opening and closing figures have both been corrected.

Date sequence and weekday plausibility

• Dates must be monotonic. A row out of order is either a rendering artefact or an insertion.
• Check a handful of dates against the calendar. Bank-initiated entries - fees, interest, direct debits - do not usually post on weekends or public holidays. A salary credit dated a Sunday is worth a second look.
• Gaps matter in both directions. A month with no activity at all in an otherwise busy account is unusual; so is a sudden cluster of round-number deposits in the weeks immediately before the application date.

Transaction description formatting

Bank systems generate descriptions from templates. Within a single statement, descriptions of the same kind should share the same shape: the same capitalisation convention, the same reference-number format, the same separators, the same truncation length.

Fabricated rows are written by a human, and humans write naturally. A ledger where forty rows read POS PURCHASE 4471 TESCO STORES 3421 and one reads Salary payment from Acme Ltd has one row that did not come out of the same system as the others.

Row geometry

• Row heights should be uniform within a section. An inserted row is frequently a fraction of a point taller or shorter.
• Decimal points should align vertically down the amount column. Amounts in a genuine statement are right-aligned or decimal-aligned by the renderer; a pasted value often sits a hair off the column baseline.
• Grid lines and zebra striping, where present, should span every row completely and alternate without interruption. A break in the alternation pattern marks an inserted or deleted row.

The amount column specifically

This is the most-edited column in the document. Two things are worth checking directly:

• Digit rendering consistency. Compare the same digit in different rows at high zoom. A 7 in an edited amount is often subtly different in weight or spacing from a 7 elsewhere on the page.
• Round-number density. Genuine transaction ledgers are messy. A statement where the credits are disproportionately round figures - 5,000; 10,000; 25,000 - and the debits are all irregular is showing you which column was authored.

Zone 5: Page breaks and page furniture

Multi-page statements have a structural property that single-page thinking misses entirely: the closing balance of page 1 must equal the opening balance of page 2.

What to check

• Balance continuity across every page boundary. Carried-forward and brought-forward figures must match exactly. This is the most commonly missed check in manual review and one of the most productive, because forgers frequently edit a single page in isolation without reconciling the seam.
• "Page X of Y" against the actual page count. A statement labelled "Page 1 of 4" arriving as three pages is a page substitution or a removal.
• Page-level furniture consistency. Account number, statement period, and header repeat on every page in most bank templates. They must be identical - same masking, same formatting, same position - on all of them.
• Per-page rendering consistency. A single page that is a slightly different dimension, resolution, or brightness from the others has a different origin. This is the signature of a page substitution: three genuine pages and one rebuilt.

Zone 6: Stamps, signatures, and the footer

Many jurisdictions issue branch-stamped or signed statements, particularly where the document is produced for visa, tenancy, or loan purposes.

What to check

• Stamp ink behaviour. A physical stamp pressed onto paper has uneven ink density, fibre bleed at the edges, and partial transparency where it crosses printed text underneath. A digitally placed stamp has uniform opacity, hard edges, and sits opaquely over the text rather than interacting with it. This is a genuinely reliable visual check at high zoom - real ink is never that clean.
• Stamp and signature position relative to content. A stamp that avoids overlapping text entirely, or sits at a suspiciously exact angle, was placed by software.
• Footer disclaimers and reference codes. These are template furniture and should match the bank's current format for the claimed period.

Cross-region checks

Some checks do not belong to a single zone because they operate on the document as a whole.

Metadata and file provenance. Open the PDF's properties. The producer and creator fields, creation and modification timestamps, and embedded font list all carry provenance. A statement claiming to come from a bank's internet banking system but produced by a photo editor is a strong signal. The caveats are real, though, and cut both ways: metadata is trivially stripped, so clean metadata proves nothing, and many legitimate banking platforms emit empty or generic metadata. Absence of evidence is not evidence here. You can check this yourself in seconds with a PDF metadata extractor.

Text layer versus rendered image. A genuine digital statement has a text layer that matches what is displayed. Select the text and copy it out. If a displayed value differs from the copied text, someone pasted an image over the original - the underlying text layer retains what the document originally said.

Benford's law on the leading digits. In naturally-occurring financial figures, leading digits are not uniformly distributed: roughly 30% of amounts begin with 1, and the frequency falls away toward 9. Fabricated figures typically do not follow this curve. The important caveat is statistical power - this test needs upward of thirty monetary figures before it means anything, so it is useful on a twelve-month bundle and close to meaningless on a single-page statement. Treat it as corroboration, never as a standalone finding.

Field-level rendering forensics. This is the check that has no manual equivalent, and it is worth understanding because it is where edited fields actually surface. Every text field on the page is measured against its own neighbours on three axes: how efficiently it re-compresses, how dark its darkest ink pixels are, and how sharp its edges are. Text that was pasted or re-rendered through a different path is already smoothed, so it re-compresses far more efficiently than genuinely original content; it frequently reaches true black where the original renderer's anti-aliasing bottoms out a few levels above it; and it is often slightly softer. None of these is meaningful in absolute terms - an edited field is one that is an outlier relative to its siblings on the same page. That peer comparison is the part a human cannot perform by eye.

The checklist, in order

Work top to bottom. The early items are cheap and catch careless fraud; the later ones cost more and catch competent fraud.

Items 1 through 4 are arithmetic. They are deterministic, they need nothing but a spreadsheet, and they are where a manual reviewer gets the most value per minute spent. Items 5 through 14 are judgement calls of varying strength. Item 15 has no manual equivalent.

What this checklist cannot do

Three honest limits.

It does not catch a fully AI-generated statement. A statement generated whole-cloth from a prompt was never edited, so there is no edit to find. The arithmetic will be internally perfect because a model computed it. The fonts will be uniform because everything was rendered in one pass. Detection has to come from template mismatch against the issuer's real format and from generation artefacts - a different problem, covered in deepfake document fraud.

It does not scale. Walking a twelve-month bundle properly is twenty to forty minutes of careful work. At any real application volume that is a bottleneck, and the practical failure mode is not that reviewers get it wrong - it is that they stop doing items 10 through 14 by mid-morning.

A clean pass is not a guarantee. Every check above has a defeat, and a determined forger who knows the checklist can satisfy most of it. What the checklist buys you is that they have to satisfy all of it simultaneously, and the arithmetic constraints in particular are unforgiving. Most do not.

That is also the case for running the automated checks alongside it rather than instead of it: 200+ forensic checks run on every submission at $0.50 a document, with the per-field analysis in item 15 that manual review structurally cannot reach. If you are choosing between tools, the evaluation criteria are here.

Related reading

• How to Detect a Tampered Bank Statement - the same problem from the forensic-technique angle
• Document Tampering Detection Software: How to Choose One - evaluating a detector
• Payslip Fraud Detection - the other half of most income bundles
• Rental Application Document Fraud - where these statements usually arrive
• Document Tampering and Fraud: The Complete Guide - the wider landscape

FAQ

How do I check if a bank statement is fake?

Start with arithmetic, because it is deterministic rather than a judgement call. Verify that opening balance plus credits minus debits equals the closing balance; that the running balance delta between every consecutive pair of rows equals that row's amount; and that the closing balance on each page equals the opening balance of the next. Then check that the routing code resolves to a real branch, that dates are in order and weekday-plausible, and that the copyable text layer matches what is displayed on screen. Those checks need nothing but a PDF reader and a spreadsheet.

What is the single most reliable manual check?

The running balance chain. Every row's balance must differ from the previous row's by exactly that row's transaction amount. It catches inserted, deleted, and modified rows, it requires no forensic tooling, and unlike most checks on this list it produces a hard answer rather than a suspicion. A forger who corrects the opening and closing balances but not the intermediate chain fails it immediately.

Which part of a bank statement is edited most often?

Three regions dominate. The account holder name and address block, because that is how one person's genuine statement becomes another person's evidence. The closing balance in the summary box, because it is usually the number the lending or tenancy decision turns on. And individual credit amounts in the ledger, to inflate apparent income. All three are localised edits in an otherwise authentic document, which is exactly why whole-document impressions miss them.

Can I tell a statement is fake from its PDF metadata?

Sometimes, and the signal is asymmetric. Metadata showing a photo editor as the producer where the document claims to come from a banking system is a strong finding. But clean metadata proves nothing - it is trivially stripped, and any forger competent enough to be a real problem has stripped it. Many legitimate banking platforms also emit empty or generic metadata, so its absence is not itself suspicious. Use metadata as a way to catch careless fraud, never as a clearance.

Does a bank stamp mean a statement is genuine?

No, and stamps are a specific fraud target precisely because they are treated that way. A physical stamp has uneven ink density, fibre bleed at its edges, and partial transparency where it crosses printed text. A digitally placed one has uniform opacity, hard edges, and sits opaquely over the text underneath. At high zoom the difference is usually visible. Treat a stamp as one more region to verify, not as verification.

How long does it take to check a bank statement properly?

Working through this checklist carefully on a multi-page statement takes twenty to forty minutes, and a twelve-month bundle takes longer. That is the real constraint on manual review: not accuracy, but throughput. Automated analysis runs the same checks plus per-field rendering forensics in about a minute, which is what makes it viable to check every submission rather than a sample.

Will this checklist catch an AI-generated bank statement?

Largely not. A statement generated from a prompt has no edit history, so there is nothing for edit-detection to find - the arithmetic will be internally consistent because a model computed it, and the rendering will be uniform because it was produced in a single pass. Catching these depends on template mismatch against the issuer's genuine format and on generation artefacts, neither of which is a manual check. If AI-generated documents are a realistic part of your threat model, manual review alone is not sufficient.

Is checking the bank statement enough to verify income?

It verifies document integrity - that the file was not altered after issue. It does not verify that the account exists, that it belongs to the applicant, or that the deposits represent genuine recurring income. Those need issuer verification, open banking, or corroboration against a second document such as a payslip. Cross-document agreement is often the strongest available check: a statement and a payslip that disagree about net pay is a finding neither document produces on its own.