How to detect a fake bank statement

Fake bank statements are everywhere. Templates cost a few dollars online, editable PDFs are a right-click away, and generative tools can now produce convincing forgeries in seconds. If you review statements as part of your job, whether you are underwriting a loan, screening a tenant, closing an audit, or checking an expense claim, you cannot rely on the document looking clean. You need to know the markers that separate a genuine statement from a plausible-looking fake.

This is a practical guide. It covers what a real statement is made of, the technical markers that betray forgeries, and how to verify a document you are unsure about. Karchu is a bank statement analyzer, not a forgery-detection service, but every real statement uploaded to Karchu carries the same fingerprints described here, and every fake one usually breaks at least one of them.

Why fake bank statements matter

A bank statement is one of the most trusted personal documents in the world. It underwrites mortgages, rental applications, business loans, immigration files, insurance claims, benefits applications, and dozens of other decisions. The people relying on it usually do not have direct access to the account it describes. That gap is the entire problem.

Fraud losses tied to fabricated income and bank statement documents run into the billions of dollars a year across US mortgage, auto lending, small business credit, and property management. The cost is not evenly distributed. Landlords, small lenders, and independent underwriters bear more of it because they lack the automated verification pipelines banks have built for themselves. If you are one of them, a fifteen minute review of a document can save six months of collection headaches.

What a real bank statement is actually made of

Before you can spot a fake, you need to know exactly what a real one looks like. Every legitimate bank statement, whether from Chase, Wells Fargo, Barclays, HSBC, Monzo, Revolut, or your local credit union, contains the same building blocks.

A machine-generated PDF produced by the bank's core banking system, not scanned or hand-edited. The PDF is text-based (you can select and copy text from it), typically single-page or multi-page, and uses the bank's official templates for the given period.
A header block with the bank's legal entity name, address, customer service phone, an account holder name and address, the statement period, and the account number in masked format (usually last 4 digits visible).
Balances: opening balance, closing balance, and a running balance column that mathematically reconciles. Every debit and credit adds up. If you total them, they equal the closing minus opening balance exactly.
Transaction lines with a date, a description that includes the method code (POS, ACH, WIRE, CHK), a merchant or counter-party string, a reference number, and an amount.
MICR and routing metadata: the routing number, account number (often masked), and sometimes IBAN or SWIFT/BIC codes for international statements.
A digital signature or trust marker: many banks now sign statement PDFs cryptographically, or attach a QR code or verification URL that the recipient can use to confirm authenticity.
Consistent typography: the entire statement is set in a single font family (usually Helvetica, Arial, or the bank's brand font), rendered at consistent sizes, with clean line alignment and no rasterized text patches.

Any missing or mismatched block is a hint. Multiple missing blocks is a signal. A statement that fails the balance math is not a hint, it is a confirmation.

The ten technical markers of an authentic statement

These are the checks that separate real from fake, ordered roughly by how hard they are to fake.

1. Balance reconciliation

The simplest and hardest to fake. Add every debit, subtract from the opening balance, add every credit. You should land exactly on the closing balance. Forgeries almost always fail this by a few dollars because the forger changed a transaction amount and did not recompute every downstream running-balance figure. When Karchu parses a PDF, this reconciliation runs automatically and any mismatch surfaces as a red flag.

2. Running balance column continuity

A real statement's running balance column is the cumulative result of the transactions before it. If the running balance on line 12 differs from (running balance on line 11 plus or minus line 12's amount), the statement has been edited. Fakes often show correct amounts in each row but a running balance that jumps or drifts.

3. Font consistency across the document

Real bank PDFs use one to two fonts, embedded in the file. A forgery frequently patches numbers over an existing template, and those patched numbers are set in a slightly different font, weight, or size. Zoom in to 400% in a PDF viewer. Compare the number 5 in the transactions section to the number 5 in the header. Real: identical. Fake: subtly different curves, spacing, or thickness.

You can also inspect PDF fonts programmatically. A real statement embeds two to four fonts. A statement patched together in a PDF editor often embeds seven, eight, or more, because each edit added another font subset.

4. Text is selectable and correctly encoded

Every real statement is text-based, meaning you can drag-select any number or word and copy it as text. If the "text" is actually an image (nothing gets selected, or you get garbage), someone has scanned or rasterized the document to hide their edits. This is the single most common tell. Legitimate banks do not distribute scanned statements.

Related trick: partial rasterization. Most of the document is text, but the amount column is an image. Zoom in. If the numbers pixelate while the surrounding text stays sharp, you are looking at an overlay.

5. Consistent decimal and thousand separators

A real statement uses the same currency formatting for every amount. If most numbers are formatted as 1,234.56 but a handful are 1234.56 or 1,234,56, someone edited a subset and forgot to match the format. Same rule applies to negative-amount formatting: parentheses versus minus signs stay consistent throughout.

6. Transaction codes match the bank's format

Every bank has a house style for transaction descriptions. Chase uses one pattern, Wells Fargo another, Barclays another. Payroll deposits, POS purchases, and ACH pulls always follow the same descriptor grammar within a given bank. A forgery cobbled together from generic examples usually mixes styles, or uses codes that do not exist for that bank. If a "Wells Fargo" statement contains a UK-style FPS or a BACS reference, that is the end of the analysis.

Our guide to bank statement abbreviations lists the codes each region uses. Any statement that mixes regions is almost certainly fabricated.

7. Date sequencing and cutoff logic

Statements are for a specific period, usually a calendar month or a billing cycle. Every transaction date must fall inside that period. Every transaction line should also appear in chronological order (or in the bank's documented order, which is nearly always chronological with same-day sub-ordering by post time). A single out-of-period date, or a set of dates that jump backwards, means someone inserted lines.

8. Reference and trace numbers follow known patterns

ARN numbers are 23 digits. Fedwire trace numbers follow OMAD/IMAD structure. ACH trace numbers are 15 digits. UK Faster Payments references follow a standard format. A statement full of blank reference numbers, or numbers that look invented, is a forgery.

9. PDF metadata and producer strings

Open the PDF's document properties. A real bank statement typically shows a producer string that identifies the bank's own document rendering pipeline: Adobe LiveCycle, Oracle BI Publisher, Crystal Reports, or an internal proprietary name. It shows a creation date matching the statement period. A statement with a Producer of "Microsoft Word", "LibreOffice", "iLovePDF", "Sejda", "PDFescape", or "Adobe Acrobat Pro" (as the producer, not the viewer) has almost certainly been edited.

Same for the creation and modification dates. Real statements are created once and never modified. If ModDate differs from CreationDate by even a few minutes, someone opened and saved the file after the bank issued it.

10. Digital signature or verification URL

This is the strongest possible marker. Many banks (particularly in the UK, EU, India, Singapore, and increasingly the US) now embed a digital signature in every statement PDF, or print a verification URL or QR code on the last page. Open the signature panel in a PDF viewer. A valid signature by the bank's certificate authority is definitive: the document has not been altered since it was issued. A missing, invalid, or expired signature does not prove forgery on its own (many US banks still do not sign) but a valid signature is proof of authenticity.

The behavioral markers

These are the ones you cannot see in a single document, but that stand out when you have real statements from the same bank to compare against.

Suspiciously round numbers. Real spending is messy. Someone with a monthly rent of $2,000 exactly, a grocery bill of $600 exactly, and a paycheck of $5,500 exactly, all in the same statement, is showing you fantasy math.
Too clean a cash flow. Real accounts have overdraft touches, small ATM fees, refunds, subscription pings, and occasional micro-charges. A statement with only large, clean, positive-cash-flow transactions is a red flag.
No recurring pattern. Real people have recurring subscriptions, salary deposits on the same day of the month, and a familiar grocery or gas station appearing repeatedly. A statement with 40 unique merchants and zero repetition is suspicious.
Missing fees and taxes. Banks charge monthly service fees, foreign transaction fees, ATM fees, and interest. A statement with none of these across a full month is unusual.
Balance never gets close to zero. Most people ride closer to their balance limits than they admit. A statement where the balance stays comfortably positive with perfectly-timed deposits often reflects reverse-engineered numbers.

The verification workflow

When you receive a statement you need to trust, this is a fifteen minute checklist. In order.

Open the PDF and select a block of text. If nothing selects, ask for a non-scanned copy or reject.
Open Document Properties. Confirm Producer is the bank's rendering software, not a consumer editor.
Check for a digital signature. If present and valid, you are done. Move on.
Zoom to 400% and compare number rendering across the header and transaction lines. Same font, weight, and spacing throughout.
Sum all debits and credits and reconcile against opening and closing balance. This is where most forgeries die.
Spot-check running balance continuity on five random lines.
Verify at least three transaction descriptions look like that bank's house style.
Look at the transaction density: is there a normal mix of small and large, recurring and one-off, deposits and withdrawals?
If you have any doubt at all, ask for a second month's statement or a direct-verification method (see below).

Direct verification methods

A visual check is defensive. A direct verification is definitive. Options, in order of reliability.

Bank-issued verification portal: some banks (Chase, HSBC, Barclays and others) provide a URL printed on the statement where anyone with the reference number can confirm the document was issued by the bank.
Digital signature: as above, a valid signature is proof.
Read-only account access: services like Plaid, Yodlee, TrueLayer, and MX let the account holder grant a one-time read-only permission to their bank data. This bypasses the statement entirely.
Statement pull via Open Banking: in the UK, EU, Australia, and increasingly the US, the account holder can consent to a real-time API pull of their transactions.
Bank phone call: the account holder authorizes the bank to confirm the statement's authenticity by phone. Old-fashioned but effective for high-value decisions.
Third-party verification services: services like Truework, The Work Number, Argyle, and Pinwheel offer income and asset verification pulled directly from source systems.

Common forgery techniques and how to catch each

Template swap: forger downloads a bank template and fills in fabricated numbers. Catch: balance math almost never reconciles; description style is generic.
Number patching: forger takes a real statement and overwrites specific amounts. Catch: font mismatch under zoom; running balance drift; PDF has multiple embedded fonts.
Line insertion: forger adds fake transactions to inflate income. Catch: dates jump; total does not reconcile; sequence numbers or reference numbers repeat.
Rasterization: forger converts the edited statement to an image to hide edits. Catch: text is not selectable; image compression artifacts around numbers.
Metadata scrub: forger runs the file through a "metadata remover" to hide Producer/CreationDate. Catch: metadata absence is itself a marker on a bank PDF; combine with visual checks.
AI-generated wholesale: newer forgeries are entirely synthesized. Catch: behavioral markers (see above) usually break; described merchant names sometimes do not exist; MCCs and codes are frequently mismatched.

What Karchu does when a statement fails these checks

Karchu is an analyzer, not a forensic tool. What we do is transparent parsing, and that transparency helps you spot forgeries even when you did not go looking for one:

Every uploaded statement is reconciled against opening and closing balance. Mismatches are flagged, not silently rounded away.
The parser records which font each transaction line was rendered in. Mixed fonts on the amount column produce a warning.
Transaction descriptions are matched against the bank's house style (Chase's descriptors look different from Wells Fargo's, and both look different from Barclays). Cross-region mixes trigger a review flag.
The PDF's Producer and creation dates are surfaced in the document view, so you can see what tool created the file.
The raw transaction stream is preserved next to the cleaned version, so an auditor can always inspect exactly what came out of the PDF.

If you are checking statements as part of a workflow (property management, small-business lending, expense verification), those signals are usually enough to short-circuit an obvious fake before it turns into a decision.

Can fake bank statements be verified as fake?

Yes, almost always. A truly professional forgery is rare and expensive. Most fakes people submit in the wild are patched templates, and every checklist item above defeats them in under fifteen minutes. The combination of balance reconciliation, font consistency, PDF metadata, and behavioral markers catches somewhere north of 95 percent of casually-produced fakes without a single external tool.

For the remaining edge cases, direct verification (Plaid, Open Banking, digital signature, or bank confirmation) is the answer. Do not rely on visual inspection alone for decisions worth more than the cost of a verification pull.

What Karchu is, and is not

Karchu is a bank statement analyzer built for legitimate use: analyzing your own statements, or your clients' statements with their permission. It is used by freelancers, small businesses, accountants, landlords, and mortgage applicants who need to understand or summarize real financial data. The same properties that make Karchu accurate for genuine statements (deterministic parsing, transparent reconciliation, preserved raw text) make it useful as a first-line sanity check when you have to review someone else's statement.

Karchu is not a forgery service and does not produce editable statements. Statements uploaded to the platform are processed as-received and never modified. If you have a legitimate verification workflow and want a categorized breakdown of a statement you are reviewing, Karchu will give you one. If a statement fails a reconciliation check inside Karchu, you should treat that as a signal to ask more questions.

Where to go next

To go deeper on the mechanics: how to analyze a bank statement covers what to actually look at once you trust the document. Bank statement abbreviations is the decoder for the codes and house styles referenced above. And AI vs rule-based analysis explains why deterministic parsing (the kind that catches reconciliation errors) beats guessing.