The 60-second answer
Modern MCA underwriting platforms run automated anomaly detection on every bank statement before a human underwriter looks at the file. The system computes a baseline deposit and withdrawal pattern for the merchant — typical deposit size, typical frequency, typical counterparty mix, typical balance trend — and flags anything that deviates beyond a set threshold.
Anomalies do not automatically kill an application. They trigger scrutiny. The system pushes the file from straight-through automated underwriting into a manual queue, and the underwriter either resolves the anomaly with the data in the file or sends a stip request to the merchant.
The difference between a funded merchant and a declined merchant is rarely whether the anomaly exists — it is whether the merchant can explain it cleanly.
The seven anomaly classes funders watch
1. Outsized single deposits
A deposit that is more than 2x the merchant's average deposit, or more than 2 standard deviations above the deposit distribution, gets flagged. For a merchant whose deposits typically run $200–$1,500, a single $25,000 deposit will always trigger review.
Legitimate explanations: a single large customer paid an invoice, an insurance settlement landed, a vendor refund cleared, a contracted milestone payment hit. Documentation: the invoice, the settlement letter, the contract milestone language.
2. Repeated round-number deposits
$5,000.00, $5,000.00, $5,000.00 on consecutive Fridays from the same counterparty reads as either a recurring service contract (good) or a transfer pattern from another account (bad). The system flags it for manual classification.
Legitimate explanations: a recurring retainer customer, a monthly subscription, a franchise royalty receipt. Bad pattern: scheduled transfers from a personal or secondary business account designed to smooth revenue.
3. Sudden mix shifts
A merchant whose first three months show 60 percent card, 20 percent cash, 20 percent wire, then suddenly month four shows 30 percent card, 50 percent wire, 20 percent P2P, triggers a mix-shift flag. The system is asking: did the business change, or was this month staged for the application?
Legitimate explanations: switched processors, lost a card-heavy customer, added a new large B2B customer who pays by wire. Documentation: processor switch confirmation, customer contract.
4. Balance pattern breaks
Operating accounts develop a characteristic balance shape — peak after large deposits, gradual drawdown through the week, fresh deposits restart the cycle. A sudden long period of low or flat balance, or an unexplained jump in average balance, triggers a balance-pattern flag.
Legitimate explanations: paid down a credit line, made a large equipment purchase, changed payroll cadence, opened a sweep account. Documentation: corresponding withdrawal paired with explanatory note.
5. Repeated NSF and overdraft clusters
One or two NSF events in a four-month window is normal. Five or more in a single month, or a cluster of NSFs in consecutive days, triggers a cash-flow stress flag. This is one of the harder anomalies to explain away.
Legitimate explanations: a single check that bounced and recleared, a debit timing error, a one-time vendor double-debit. Documentation: the specific NSF item and the corrective action.
6. Counterparty concentration shifts
If 80 percent of the merchant's recent revenue comes from a single counterparty — especially a new one — the system flags concentration risk. A new customer ramping fast is a soft red flag because the file does not yet show whether the customer is durable.
Legitimate explanations: a large new contract, a marketplace ramp (Amazon, Doordash), a seasonal partner. Documentation: contract, marketplace settlement summary.
7. Reversals and chargebacks
A single reversed deposit is normal. A cluster of reversals — especially card-processor chargebacks — triggers a fraud-or-quality-issue flag. It is one of the few anomaly types that often does kill an application, because chargeback patterns signal underlying customer-satisfaction or fraud problems that future months are likely to repeat.
How the detection actually works
Modern bank-statement OCR platforms (Plaid, Ocrolus, Heron Data, Boss Insights, and the home-grown systems at larger funders) all run similar logic:
- Build a baseline. Compute the merchant's normal deposit size, frequency, counterparty mix, weekly seasonality, and balance pattern from the first 60–90 days of statements.
- Score deviations. For every subsequent transaction, compute a deviation score against the baseline. Z-scores above 2.0 typically trigger flags.
- Cluster the flags. Isolated anomalies are scored lower than clusters of related anomalies. A single large deposit is mild; a large deposit plus a balance jump plus a new counterparty is a clustered flag worth manual review.
- Generate the underwriter note. The system produces a short summary of the top flags for the underwriter, with the relevant transactions pre-highlighted.
The underwriter then chooses one of three paths: resolve the flag from the file itself, send a stip request, or decline. The path chosen depends heavily on how the rest of the file looks — a strong file with one isolated flag almost always proceeds, while a borderline file with multiple flags often gets declined.
Worked example — same anomaly, two outcomes
Two merchants both have a $40,000 deposit on month three that is 6 standard deviations above their normal deposit pattern. Both files get flagged.
Merchant A attaches a 1-page note at intake: "This was an insurance settlement for a kitchen-fire claim. Documentation attached." Plus the settlement letter. The underwriter resolves the flag in under 5 minutes, strips the deposit from revenue (insurance is non-revenue), and moves forward with the file on the remaining qualified revenue. Offer in 24 hours.
Merchant B attaches nothing. The underwriter sends a stip request asking for an explanation. The merchant takes 48 hours to respond, sends a one-line email without documentation, then the underwriter sends a second request for the supporting document. Total elapsed time: 4–5 days. The file eventually funds but at a tighter price because the back-and-forth dropped the priority on the underwriter's queue and made the file feel uncertain.
Same underlying business. Same anomaly. Very different experience and meaningfully different pricing.
What to do before submission
- Walk through your own statements and identify the top 3 outliers. Look for deposits or withdrawals that look unusual relative to your normal pattern.
- Write a 1-page note explaining each. One paragraph per anomaly: what it was, what document supports it, whether it is recurring.
- Attach the supporting documents at intake. Not after the stip request — at intake. The underwriter's first pass should resolve the flag without needing to ask.
- If the anomaly is a cluster of NSFs, address it directly. A short note explaining the underlying timing issue and the corrective action is far more credible than silence.
- Do not try to hide anomalies by omitting or editing pages. Modern OCR cross-checks page numbers, running balances, and statement totals. Edited statements are caught in seconds and result in immediate decline plus a flag on your merchant history.
The bottom line
Anomaly detection is the part of MCA underwriting most merchants never see. The flags run automatically, generate underwriter notes, and shape the entire downstream process. Merchants who treat anomalies as known and explainable — proactively documenting them at intake — fund faster, at better terms, and avoid the slow-rolling stip cycles that frustrate everyone involved.
Frequently asked questions
- What is the most common anomaly that triggers underwriter review?
- Unexplained large deposits. A single deposit that is more than two standard deviations above the merchant's normal deposit pattern almost always triggers a stip request, regardless of whether the deposit is legitimate revenue.
- Will an anomaly automatically disqualify my application?
- Almost never. Anomalies trigger scrutiny, not denial. The denial comes from anomalies the merchant cannot or will not explain. A legitimate anomaly with documentation attached is fully fundable.
- How does the funder distinguish between legitimate anomalies and red flags?
- Through documentation, pattern matching against industry norms, and corroborating signals on the rest of the statement. An anomaly that fits the merchant's business narrative — and is supported by an invoice, contract, or POS report — is treated very differently from an anomaly with no explanation.
- Do I need to explain every unusual transaction proactively?
- No, but you should be ready to. The most efficient approach is to identify the two or three largest anomalies in your file before submission and attach a 1-page note explaining them. It speeds underwriting and prevents a back-and-forth that can take 24–48 hours each round.
- Will the anomaly stay on my file for future applications?
- Most funders keep notes on file for renewals. If you explained an anomaly cleanly the first time, the renewal underwriting will reference that note and not re-flag it. A poorly explained or unexplained anomaly often resurfaces.