Atomara
Process How it works For whom Guides Pricing API Blog FAQ
EN
English Polski Українська Čeština Deutsch
Sign in Check a PDF
Atomara
01Process 02How it works 03For whom 04Guides 05Pricing 06API 07Blog 08FAQ
Language
EN PL UA CS DE
Sign in Check a PDF
Home /Blog /How fake statements get made

How fake bank statements get made in 2026 — and why the old advice stopped working

Published 2026-08-27 Fraud trendsAI

Every guide to spotting a forged bank statement written before about 2023 shares an assumption: that forgery is difficult. Look for misaligned columns, mismatched fonts, a logo at the wrong resolution, arithmetic that does not close — the tells of someone doing something hard, badly.

That assumption is gone. Not because forgers got cleverer, but because they stopped needing to be. The work moved from the person committing the fraud to a supply chain that sells the output, and the price collapsed. This post is about what that supply chain looks like from the receiving end — what each layer of it leaves behind, and which of the old advice still earns its place.

Four ways a fake document reaches you

They are worth separating, because they fail in different places and the defence differs for each.

Template shops. Ready-made layouts for named institutions, sold as a product, filled in through a form. The output is visually correct because it was drawn by someone who had a real statement in front of them. This is the oldest layer and still the largest.

“Novelty” editors. Tools that take a real document and let someone change a figure in it. The framing is deliberately jokey — the marketing says novelty, the use case is not — and the result is the most dangerous kind of forgery, because everything except the edited number is genuine.

Generative models. A model asked to produce a plausible statement for a plausible person. The output is not copied from anywhere, so there is no original to compare against, and it does not carry the artefacts of an edit — because nothing was edited. It is not a modified document; it is a document that never existed.

Compromised real files. The applicant sends a genuine statement belonging to someone else, or a real file obtained from a breached mailbox with the name swapped. Structurally, most of it is authentic — which is exactly the problem.

Why the visual checklist stopped working

Every tell on the traditional list is a tell of *effort*: uneven kerning because someone typed over a figure, a logo at the wrong resolution because it was pulled off a website, columns that drift because the row was recreated by hand. Those artefacts appear when a human is doing careful manual work under time pressure.

Remove the human and the artefacts go with them. A generated document has consistent kerning throughout, because nothing was typed over anything. Its arithmetic closes, because a generator can do arithmetic. Its layout is uniform, because it was laid out once by software rather than patched. Judged on appearance, a fabricated statement now outperforms many genuine ones — real documents pick up scanner noise, phone re-encoding and portal re-renders on the way to you.

The uncomfortable conclusion: looking right has become weak evidence, and looking slightly wrong has become weak evidence too. A tidy document is what a generator produces. A slightly scruffy one is what a real bank portal and a real applicant's phone produce between them.

What each kind still leaves behind

This is the useful part, and it is worth being precise about how strong each trace actually is.

  • Edited real documents leave the most: the file was opened by an editor and saved a second time, and the software that did it usually writes its own name into the file. Where the edit covered rather than removed, the original content can sometimes still be recovered from inside the PDF.
  • Template output leaves a production fingerprint: a document assembled in a design tool or a word processor does not have the internal structure a bank's reporting engine produces, whatever the visible page shows.
  • Generated documents leave the least in the file itself — but they are the weakest against the checks that do not look at the file at all, because there is no real account behind them. Nothing in the numbers has to reconcile with anything outside the document, and that is where they break.
  • Stolen real files are almost clean structurally, and are caught by identity rather than forensics: the name, the address, and the account do not belong to the person in front of you.
That is the shape of the whole problem in four lines: the forgeries that are easiest to detect in the file are the ones that were cheapest to make, and the ones that are hardest to detect in the file are the ones that fall apart fastest outside it. Our post on what metadata can and cannot prove goes through the limits of the file-level layer in detail.

What to do differently

Three changes, in order of how much they buy you.

Stop treating the document as the evidence. It is a claim. The evidence is whether the claim survives contact with something the applicant does not control: a bank-verified income connection, a statement fetched from the bank's own portal in front of you, an employer confirmed on a number you looked up yourself. Every one of those is unaffected by how good the forgery is.

Ask for more than one document, and make them agree. A single statement can be internally consistent for nothing. Three consecutive months, where each closing balance has to equal the next opening balance, is a much harder thing to generate and a trivially cheap thing to ask for.

Use file forensics as a filter, not a verdict. It is fast, it eliminates the careless majority, and it costs you almost nothing per document. What it is not is proof of authenticity — a clean read means the easy tells are absent, which is not the same as the document being real.

The part vendors usually leave out

Detection is not a solved problem, and anyone telling you otherwise is selling something. Two things stay true regardless of which tool you use.

First, false positives are not free. Innocent documents get re-saved constantly — by bank portals, by email gateways, by the applicant's phone — and every one of those re-saves leaves the same trace an edit does. A screening process that treats every anomaly as guilt produces a steady stream of wrongly refused applicants, and they remember it far longer than the fraudster you stopped.

Second, a well-made generated document may leave nothing in the file worth finding. That is not a gap that better forensics will close, because there is nothing to find: the file is exactly what it claims to be structurally. It is only a lie about the world, and lies about the world are checked against the world.

So the honest position is narrow and useful: file forensics tells you what happened to a document, quickly and cheaply, and that is worth having on every file you receive. It does not tell you whether the money was ever there. The verification method is written out in full, and the free metadata checker lets you read the first layer of any PDF yourself, in your own browser, without uploading it anywhere.
— Not sure about a document?

Check it before you trust it.

Upload the PDF for a free preliminary check — metadata, a risk score and the anomaly count at no charge.

Upload a PDF
Atomara

Forensic verification of any PDF — bank statements, pay stubs, payment confirmations and more. Automated PDF forensics. Risk indicators, not a verdict.

Product

  • How it works
  • Pricing
  • API
  • Guides
  • Verify a bank statement
  • Verify a payment receipt
  • PDF metadata checker
  • FAQ
  • Blog

Who it's for

  • For businesses
  • For individuals
  • B2B plans
  • Free check

Contact

  • [email protected]
  • About
  • Contact
  • Privacy Policy
  • Terms of Service
  • Security
© 2026 Atomara
English Polski Українська Čeština Deutsch
Automated PDF forensics · Any document · Any bank
We value your privacy

We use cookies to run the site and, with your consent, to measure traffic and improve it. Privacy Policy