Detecting AI-Generated Bank Statements

TL;DR — highest-yield checks in 2026

CheckWhat you're looking forWhy it catches AI fakesDaily ending balance flowEach day's ending balance = previous balance + day's net activityAI generators frequently break running-balance arithmeticDirect deposit patternPayroll deposits at consistent intervals, consistent amounts, ACH-coded correctlyReal payroll lands on a predictable cadence; AI patterns deviate subtlyNACHA SEC code on direct depositsPPD code for personal payroll, plus a real ACH originator IDMost AI generators don't include or correctly format theseRound-number detectionReal spending has cents; round numbers are suspicious in bulkStatistical signal across the full statementCounterparty name patternsMerchants appear with their actual ACH/POS naming conventionsAI sometimes uses retail brand names rather than acquirer formatsRouting/MICR validationRouting number is real, format is correct, account number length matches the bankRouting numbers are publicly cross-referenceableDirect bank data via Plaid/Yodlee/MXReal-time data from the bank, bypassing the document entirelyThe only structurally fraud-resistant approachCross-reference with pay stubNet pay on stub matches deposit on statement on the right dateSingle highest-yield cross-document check

If you have time for one check, run the daily ending balance arithmetic. If you have time for two, add direct bank data via an aggregator on high-stakes decisions.

What makes bank statements different from pay stubs and W-2s

Three properties of bank statements change the detection problem in important ways relative to the documents covered in articles #8 and #9.

Transaction-level granularity. A pay stub has maybe 20 line items. A W-2 has 20 boxes. A monthly bank statement typically has dozens to hundreds of individual transactions, each with a date, counterparty, amount, type, and effect on running balance. The volume of data is both an advantage and a problem for fraudsters: more data to fabricate convincingly, more checks the verifier can run, more places for inconsistency to surface. AI generators that produce convincing summary documents often fail when asked to produce convincing transaction-level detail at scale.

Running balance arithmetic. Every transaction on a bank statement changes the account balance. The starting balance, plus the net of all transactions in chronological order, has to equal the ending balance — and every intermediate daily balance has to be correct too. This is a deterministic constraint that holds across the entire statement, not just within a single box or row. Real bank statements get this right by definition because they're produced by the bank's accounting system. AI-generated ones frequently don't.

Real-time direct data exists. Unlike pay stubs (no authoritative external source) or W-2s (the IRS as a source, with multi-hour-to-multi-day turnaround), bank statement data can be retrieved from the bank itself in seconds via consumer-permissioned aggregation services. This is the most important structural fact in this entire article. For decisions where you can ask the applicant to connect their bank account, document inspection becomes optional — the bank's own data is right there. More on this in the dedicated section below.

The combined effect: bank statements are the highest-leverage document to fake (because they support so many decisions) and the highest-leverage to verify (because real-time bank data is available). The asymmetry favours the verifier — but only if you use the available tools.

Tier 1: Statement-level structural checks

The fastest and highest-yield checks operate on the statement as a whole rather than transaction by transaction.

Daily ending balance flow

This is the single most diagnostic check available without leaving the document. A real bank statement shows, either explicitly or implicitly via the transaction list, a daily ending balance for each business day. The arithmetic has to chain:

Previous day's ending balance + today's deposits − today's withdrawals = today's ending balance.

This holds for every day. If it doesn't, the statement is either fabricated or contains an error the bank should have already corrected.

The reason AI generators struggle here: they compose transactions individually and don't always tie them back to running totals. A model that generates a plausible-looking transaction list may not be tracking the cumulative balance correctly. Even small errors — a $10 discrepancy on day 7 that propagates through to a $10 error in the ending balance on day 31 — are diagnostic.

How to check it quickly: pick three random days spread across the statement, do the arithmetic, and compare to the listed daily ending balance. If they match, the math is probably right. If even one is off, dig deeper.

Statement period coverage

A real bank statement covers a complete period — typically a calendar month or a fixed monthly cycle (e.g., the 15th of one month through the 14th of the next). The statement period should be clearly stated on the header, the first and last transaction dates should fall within that period, and there should be no gaps in business days. A statement showing "March 1–March 31" with no transactions between March 7 and March 18 is suspicious unless the applicant can explain the dormancy (vacation, account inactivity, etc.).

Transaction sequence consistency

Major banks assign each transaction a sequence number, reference number, or check number within the statement. The numbers should be monotonically increasing in chronological order. AI generators sometimes produce transaction lists where the reference numbers don't flow correctly — out of sequence, missing numbers, or repeated numbers. Not every statement includes these fields visibly, but when they're present, they're useful.

Format consistency with the bank's actual statement format

Each major bank has a characteristic statement format: the header layout, the logo position, the section ordering, the font choices, the page footer. An applicant's statement that doesn't match the current statement format of the bank they claim to use is a red flag. The fastest sanity check: pull up a sample of the bank's current statement format (most banks publish examples or you can compare against a known-real statement in your portfolio) and compare.

This is particularly diagnostic for the major national banks (Chase, Bank of America, Wells Fargo, Citi, Capital One, US Bank), all of which redesign their statements periodically. A statement using a 2022 layout in 2026 is either old (which the date should reveal) or fake.

Page numbering and total pages

Real bank statements show "Page X of Y" and the total page count matches the actual number of pages. AI-generated statements occasionally show internally inconsistent page numbers, or page totals that don't match the file's actual page count.

Tier 2: Transaction-level forensics

If the statement passes the structural checks, the next layer is the transaction list itself. Real spending has characteristic patterns; AI-generated spending often doesn't.

Round-number distribution

Real consumer spending has cents almost universally. A coffee at $4.85, a grocery bill at $87.43, a utility payment at $123.67. The exceptions — ATM withdrawals (typically in $20 multiples), some manual transfers, certain fixed-fee transactions — represent a small share of total transactions.

AI-generated statements often have too many round-number transactions. A statement showing 60% of debit transactions ending in .00 is statistically implausible. The check: scan the transaction list and count round-number amounts. If more than 15–20% of transactions are round dollar amounts (excluding obvious cash transactions), something is off.

Pay frequency consistency

If the applicant claims to be employed with a regular salary, the direct deposit pattern should reflect it. Bi-weekly employees should have deposits every 14 days, semi-monthly employees on the 15th and last day of each month (or similar consistent dates), monthly employees on a consistent date. Deposits that arrive on Tuesday this week and Friday next week, or that vary in amount by 30% from period to period without explanation, are suspicious.

The same logic applies in reverse: a "self-employed" applicant whose statement shows deposits that look exactly like regular payroll (same amount, every 14 days, same originator) is internally inconsistent with their claimed income source.

Counterparty naming conventions

How merchants appear on bank statements follows specific conventions. A purchase at a Starbucks location doesn't appear as "Starbucks" but as something like STARBUCKS #07429 SAN FRANCISCO CA or SQ *STARBUCKS COFFEE if it ran through Square. Amazon purchases appear as AMZN MKTPLACE PMTS or Amazon.com*1234ABCDE. Gas stations include the station chain, location, and often a city/state. Subscriptions include the service name plus an identifier.

AI-generated transaction lists often use clean brand names — "Starbucks", "Amazon", "Netflix" — without the actual ACH/POS descriptor format that real statements use. This is one of the more reliable signals because the real formats are deterministic (they come from card networks and ACH processors), and AI generators frequently smooth over them.

Time-of-day patterns (if shown)

Some banks include transaction timestamps. If they're present, the times should reflect plausible spending behaviour — coffee in the morning, dinner in the evening, payroll deposits typically posted overnight or early morning. Transactions clustered at unrealistic hours (3 AM debit card purchases at retail stores that aren't open) are suspicious.

Pending vs cleared status

Statements covering recent periods may include pending transactions that haven't fully settled. The mix of pending vs cleared should be consistent with the statement period — old transactions should all be cleared, very recent transactions may still be pending. AI generators sometimes label transactions inconsistently or use "pending" status for transactions that should have cleared days ago.

Tier 3: ACH and direct deposit specifics

This is where AI generators reliably fail, because reproducing the actual NACHA ACH formats requires understanding the underlying payment rails — and most generators were trained on the cosmetic appearance of statements, not the wire-protocol detail.

NACHA Standard Entry Class (SEC) codes

Every ACH transaction in the United States carries a 3-character SEC code indicating what type of transaction it is. The most common on consumer statements:

PPD (Prearranged Payment and Deposit) — the most common SEC code for personal payroll, direct deposits, and recurring bill payments. Real payroll deposits almost always carry this code.

CCD (Cash Concentration or Disbursement) — corporate-to-corporate ACH; appears on business statements but rarely on personal ones.

WEB (Internet-Initiated Entry) — consumer-authorised debits initiated online, common for bill pay and one-time online purchases.

TEL (Telephone-Initiated Entry) — consumer authorisations by phone; less common.

ARC (Accounts Receivable Conversion) — paper check converted to ACH; appears for some bill payments.

POP (Point-of-Purchase) — paper check converted at point of sale.

BOC (Back Office Conversion) — paper check converted later in processing.

Real bank statements either show these codes explicitly or imply them through the transaction type description. AI-generated statements often omit them entirely or use them inconsistently. A "payroll deposit" with no PPD code, or labelled CCD when the recipient is a personal account, is a tell.

ACH originator identification

Every ACH transaction includes an originator name and a 10-character "Company Identification Number" (the ACH originator ID), which is registered with NACHA and tied to a specific company. Real payroll deposits show:

The employer's actual ACH-registered name (which may differ slightly from their consumer brand — e.g., "ACME LLC" rather than "Acme").

A 10-character originator ID that's unique to that company.

A consistent format across pay periods (the same originator ID and name appear every time).

AI-generated statements often invent originator names that look reasonable but aren't tied to any real company, or omit the originator ID entirely, or use originator IDs that don't follow the NACHA format.

For high-stakes decisions, originator IDs can be cross-referenced against ACH databases. A "Microsoft Payroll" deposit with an originator ID that doesn't trace to Microsoft Corporation's actual ACH registration is fabricated.

Settlement timing

ACH transactions have predictable settlement timing. Same-day ACH is increasingly common but most consumer payroll still settles next-business-day (T+1). A statement showing payroll deposits posted on a Saturday or Sunday (without a Friday pre-deposit) is suspicious — banks don't process most ACH on weekends.

Direct deposit splits

If an employee splits their direct deposit between two accounts (a common arrangement — e.g., 80% to checking, 20% to savings), this typically appears as two PPD deposits from the same originator on the same day, with amounts that sum to the gross direct deposit visible on their pay stub. A statement showing only one deposit when the pay stub indicates a split (or vice versa) is internally inconsistent.

Tier 4: MICR line and routing number verification

The MICR line at the bottom of a check — and the routing/account information on a bank statement — is publicly verifiable.

Routing number structure

A US bank routing number (also called an ABA routing transit number) is exactly 9 digits and follows a specific structure:

Digits 1–2: Federal Reserve routing symbol (corresponds to a Federal Reserve District — 01–12 are primary US districts).

Digits 3–4: ABA institution identifier.

Digits 5–8: Bank-specific identifier.

Digit 9: Check digit, calculated from the first 8 using a specific algorithm.

The check digit calculation is: (3 × (d1 + d4 + d7) + 7 × (d2 + d5 + d8) + 1 × (d3 + d6)) mod 10 should equal 0 when including digit 9 (or equivalently, the formula yields the check digit directly from the first 8).

A routing number whose check digit doesn't validate is invented. This is a fast, deterministic check.

The first two digits also encode the Federal Reserve District. Routing numbers starting with 50–59 are reserved for thrift institutions; 60–72 indicate specific Federal Reserve Districts; numbers above 72 (other than the specific reserved ranges) are typically invalid. A routing number starting with 88 or 99 doesn't match any current ABA assignment.

Cross-reference paths: the Federal Reserve publishes a routing number directory; the ABA's routing number lookup is publicly available; most banks list their own routing numbers on their websites.

Account number conventions

Each bank has characteristic account number formats. Chase consumer checking accounts are typically 9 or 10 digits. Bank of America accounts vary. Wells Fargo accounts have their own patterns. If the account number length on a purported statement doesn't match the bank's actual format, it's a tell.

Bank name and routing match

The routing number on the statement should belong to the bank named on the statement. A statement claiming to be from "Wells Fargo Bank N.A." with a routing number that traces to a different institution is fabricated. The lookup is fast.

Tier 5: Direct bank data — the structural answer

This is the section that makes everything above optional for high-stakes decisions.

Several US fintech services — Plaid, Yodlee (now part of Envestnet), MX, Finicity (Mastercard Open Banking), and Argyle (for income-specific data) — operate consumer-permissioned bank data aggregators. With the applicant's consent (typically via OAuth-style flows where the applicant logs into their bank through the aggregator's UI), the lender can retrieve real-time transaction history, account balances, and account ownership directly from the bank.

The structural advantage is total: there's no document to verify because there's no document. The data comes directly from the bank's systems. Forgery is essentially impossible in this flow because the fraudster would have to compromise the bank itself to produce false data.

Operational trade-offs:

Applicant friction. The applicant has to complete a connection flow, which adds steps. Most consumers are familiar with these flows by now, but conversion drops slightly.

Coverage gaps. Some smaller banks don't yet have full integration with all aggregators. Coverage is well above 90% of US deposit accounts but not 100%.

Cost. Each connection has a per-call or per-month fee depending on the aggregator and the data products consumed. Material but typically much less than the cost of fraud loss prevented.

Data access scope. Aggregator data is typically transaction-level, real-time, and verifiable, but the depth varies. Some aggregators also offer income-verification products (Argyle, Pinwheel) that focus specifically on payroll deposits.

For mortgages, business loans, large personal loans, and any decision where the cost of being wrong materially exceeds the cost of friction, direct bank data is the right verification path. Document inspection becomes a fallback for the small share of applicants whose banks aren't supported.

For lower-stakes decisions (small rentals, low-limit credit), document inspection plus the cross-checks above remains the dominant approach. The math, ACH, and routing checks above are the right battery.

Cross-reference: matching the bank statement to other documents

The highest-yield cross-document check available is also one of the simplest.

Net pay on the pay stub should match the deposit on the bank statement. Same date (or the next business day if the pay date falls on a weekend), same amount, same originator. A pay stub showing $2,847.36 net pay on March 15 should show a $2,847.36 deposit on the bank statement on March 15 (or March 16 if March 15 was a Saturday), with the originator matching the employer.

A pay stub and bank statement that don't reconcile is the strongest single fraud signal available short of direct bank data. AI generators that produce both documents may get each individually convincing but fail to make them match.

For the pay stub-side of this check, see our companion guide on AI-generated pay stubs.

The arms race, and the durable answer

The same conclusion that applies to pay stubs and W-2s applies to bank statements, with one important addition: real-time bank data via aggregators is already a structural answer for many use cases, available today. The detection techniques in this guide remain useful — for low-stakes decisions, for banks not supported by aggregators, for the share of applicants who can't or won't complete a connection flow — but they're fighting a moving target.

The longer-horizon answer for issuer-side verification of bank statements is verifiable issuance: banks themselves issuing statements with cryptographic signatures and QR-based verification, so recipients can confirm a statement is authentic in one scan rather than running through the forensic battery. Some banks have begun doing this for high-trust use cases like wealth management documentation; broader retail adoption is following.

The pattern is covered in detail in our scan-to-verify documents pillar guide. For the cryptographic mechanics underneath, see QR code signature validation. For the credential-style lifecycle, see QR code certificate verification.

The practical 2026 stance for organisations relying on bank statement data: for high-stakes decisions, default to direct bank data via Plaid, Yodlee, Finicity, or equivalent; for lower-stakes decisions, run the forensic battery in this guide and demand that high-risk applicants verify via direct data. Document-only review will remain part of the workflow for some applications, but it should not be the only check on any decision that matters.

Is creating a fake bank statement illegal?

Submitting a fabricated bank statement to a lender, landlord, or other party to obtain financial benefit constitutes fraud under federal law (18 USC § 1001, 18 USC § 1014 for false statements to financial institutions, and various other provisions). The penalties are substantial — up to 30 years' imprisonment and $1 million in fines under § 1014 for bank fraud. Creating a fake statement with knowledge of fraudulent intent is itself a crime even before submission.

How does direct bank data via Plaid actually work?

The applicant clicks a "Connect Bank" button in your application flow, which opens a Plaid-hosted UI. They select their bank, log in with their actual bank credentials (which Plaid handles via OAuth where available, or via direct credential brokering elsewhere), and authorise data sharing. Plaid retrieves transaction history, balances, and account metadata from the bank and exposes it to your application via API. The applicant's credentials are not stored by your application.

What if the applicant's bank isn't supported by Plaid or other aggregators?

Coverage is above 90% of US deposit accounts, but gaps exist. For unsupported banks, fall back to document review with the forensic battery in this guide, plus an explicit cross-reference between the bank statement and the pay stub. For very small or unusual banks, additional verification through the bank itself (phone confirmation of an issued statement) may be warranted.

Can AI detect AI-generated bank statements?

Several vendors offer document fraud detection focused on bank statements. They catch a meaningful share of AI-generated fakes, particularly those produced from common templates. They miss the more sophisticated. As with pay stubs and W-2s, layered defence — visual + structural math + ACH details + cross-reference — outperforms any single tool. Direct bank data, where available, outperforms all of them.

Are joint account statements harder to verify?

Joint accounts add a few complications — both account holders may show as authorised, deposits from both employers may appear, transactions may reflect either party's spending — but the underlying forensic checks (math, ACH codes, MICR, counterparty patterns) work the same. Direct bank data also works on joint accounts with appropriate consent.

What about international bank statements?

Non-US bank statements follow different conventions. The math-checks transfer (running balance still has to chain), but the ACH-specific details (NACHA SEC codes, US routing number structure) don't apply. The international equivalents — SEPA in Europe, BACS in the UK, EFT in Canada — each have their own conventions worth learning if your portfolio includes non-US applicants. Open Banking initiatives (particularly the UK's Open Banking framework and the EU's PSD2/PSD3) provide a real-time direct-data path equivalent to US aggregators for many non-US accounts.

Should I always require direct bank data for material decisions?

For most US lenders, yes. The friction cost is low enough — most consumers are familiar with Plaid flows from other contexts — and the fraud-prevention value is high enough that direct data should be the default for any decision where the cost of being wrong exceeds the cost of a few extra application steps. The cases for document-only review are: very small loans, jurisdictions or applicant populations where aggregator coverage is thin, and edge cases where consent flows fail.

How does this fit with the broader Cluster B detection trilogy?

This article completes our three-part series on AI document fraud detection. The cluster covers the three highest-volume targets together: pay stubs, W-2s and tax documents, and bank statements. Each document type has its own forensic techniques, but the philosophy is consistent: detection is a useful capability but fights an uphill battle; issuer-side verification and direct-data paths are the durable answers.

VerifyDoc.ai supports verifiable issuance of financial documents — bank statements, pay stubs, employment letters — so recipients can confirm authenticity in one scan rather than running forensic checks. For the issuer-side workflow on verifiable bank statements specifically, see our verifiable bank statements playbook.