MCA funder bank statement fraud pattern detection — how altered statements, fake deposits, and synthetic businesses get caught.

The 60-second answer

Every set of bank statements submitted to an MCA funder in 2026 passes through an automated fraud-detection layer before any human looks at the file. The layer is distinct from anomaly detection. Anomalies are unusual patterns that might be legitimate. Fraud detection identifies patterns that are statistically improbable in real bank statements — patterns that almost always indicate the file has been edited, fabricated, or sourced from a different business than the application claims.

The detection is good. In 2026, the catch rate on altered statements is close to 100 percent for any non-trivial edit. Detection on synthetic businesses (fabricated identity plus fabricated statements) is somewhat lower but improving rapidly as industry-wide databases mature.

A fraud flag is a near-permanent record. It blocks the merchant from most reputable funders for 12–24 months and follows them across the industry through shared databases.

What the detection actually looks for

1. Running balance integrity

Every bank statement carries a running balance. Each transaction is the running balance plus or minus the transaction amount, matching the prior line's running balance. The OCR parses every line and re-computes the running balance. Any break — a number that does not add up correctly, even by one cent — is a hard flag.

This is the single most effective fraud catch. Almost every amateur edit breaks the running balance because the editor changes one number without re-computing every subsequent balance line.

2. Pixel-level font and rendering consistency

Real bank statements are generated by the bank's printing system with a single font, consistent spacing, consistent line height, and consistent rendering. An edit done in a PDF editor often introduces a pixel-level inconsistency: slightly different font weight, slightly different anti-aliasing, slightly different baseline. Modern OCR runs a pixel-comparison pass across the page and flags inconsistencies.

3. Statement total cross-checks

Most statements include summary blocks: total deposits for the period, total withdrawals for the period, beginning balance, ending balance, average balance. The OCR re-computes all of these from the line-item data and compares to the printed summary. Any inconsistency is a flag.

4. Statement-to-statement continuity

Month one's ending balance must equal month two's beginning balance, exactly. The OCR chains the statements together and flags any discontinuity. Common failures: skipping a month entirely, submitting two statements that do not actually cover consecutive periods, submitting an edited file where one month's edits cascade into the next month's beginning balance.

5. Deposit pattern statistics

Real deposits follow recognizable distributions: clustered around certain dollar amounts for the merchant's business, certain day-of-week patterns, certain rounding behaviors. Fabricated deposits often miss these subtle patterns. They are too round, too clean, too evenly spaced. The detection flags deposit distributions that look statistically inconsistent with real merchant data in the same vertical.

6. Cross-account inconsistency

If the merchant submits statements from two accounts (operating plus reserve, for example), transfers between the accounts must match across both statements. A transfer out on account A on a specific date must appear as a transfer in on account B on the same or next business day. Mismatches are a hard flag.

7. Synthetic business signals

Some fraud involves fabricated businesses — fake LLC, fake EIN, fake bank account opened briefly to generate "real" statements. Detection signals include: very short account history, deposit patterns that do not match the claimed business type, address inconsistencies across application and statement, EIN that does not match SOS records.

The industry databases

Fraud detection extends beyond a single funder. Several industry databases share fraud flags across MCA funders:

• DataMerch: The most widely-used merchant fraud and default database in MCA. Flags persist for typically 12–24 months. Most major funders query DataMerch on every application.
• Cynergy / similar shared-decline databases: Used by larger funders to share decline reasons and detected fraud patterns.
• NACHA Originator-level patterns: Some funders share recent originator- and merchant-level data to identify patterns of repeat fraud.

The implication: a merchant flagged for fraud at one major funder is generally flagged for fraud at most major funders, all at once. There is no "submit to the next funder" path after a fraud flag has propagated.

Worked example — three fraud catches

Example A — running balance break. A broker edits month two of a merchant's statements to add a fake $25,000 deposit on day 12, hoping to boost qualified revenue. The deposit is added, but the running balance from day 12 through day 30 is not re-computed. The OCR flags the break in under 5 seconds. File declined. Merchant flagged.

Example B — pixel font inconsistency. A merchant downloads their real statement, opens it in a PDF editor, changes three deposit amounts to be slightly larger. The edited numbers render in a font that is slightly off from the bank's native font. OCR pixel comparison catches it. File declined.

Example C — continuity break. A merchant submits months 1, 2, and 4 — skipping month 3 because month 3 had several NSFs and a low balance. The OCR notices that month 2's ending balance does not match month 4's beginning balance and that the dates skip a month. File flagged. Underwriter requests month 3. Once provided, the NSFs show. The merchant could have submitted all four months honestly and been priced as B-paper; instead, the omission attempt resulted in C-paper pricing or decline.

The broker-fraud problem

A meaningful share of detected fraud in MCA does not come from the merchant. It comes from brokers who edit the merchant's statements to "improve" the file before submission, often without the merchant's full knowledge. The broker's incentive is volume — submitting more fundable files means more commissions. The merchant carries the cost.

Two protective moves for merchants:

• Submit statements yourself, directly to the broker's intake portal or to the funder. Watch the upload happen. Save copies of exactly what was uploaded.
• Avoid brokers who promise "guaranteed funding" or "we'll work on your statements." That is a euphemism for editing. Use platforms that show you the actual funders bidding on your file and the actual statements being submitted.

What to do if you have been flagged in error

The flag can occasionally be incorrect — for example, when a bank reissues a statement with corrected information that does not match an earlier version, or when a merger between two business entities creates a continuity break. Recovery steps:

• Request the specific decline reason in writing from the funder. Most will provide it.
• Get the database record from DataMerch directly. They will share the record with you and provide a dispute path.
• Provide bank-direct evidence. A letter from the bank's business banking team confirming the legitimate version of the statement usually resolves the flag.
• Allow 30–60 days for the correction to propagate. Industry databases update on a regular cycle.

The bottom line

Fraud detection on bank statements is one of the most mature pieces of MCA underwriting infrastructure. The catch rate on altered files is essentially complete in 2026. Industry-wide databases share flags across funders, making a fraud detection a near-permanent block from most reputable funders. The right move — always — is to submit clean, real statements, address weaknesses through documentation and timing rather than editing, and avoid any broker or platform that suggests otherwise.