Fraud Prevention guide: MCA Application Fraud: Catching Identity Fraud and Business Misrepresentation Before Funding

MCA application fraud is caught before funding by matching each fraud type to the check that exposes it: verify the owner as a person, verify the business against records the applicant did not supply, reconcile stated revenue against bank data, confirm the deposit account belongs to the business, and call the merchant back on a number you sourced yourself. Layered controls and a human reviewer do the rest.

This guide is organized by fraud type, the way a funder's risk team actually meets these files: owner identity theft, impersonation of a real business, misstated revenue, time in business or industry, undisclosed positions, broker-facilitated fraud, takeover of the merchant's bank login, and contact or deposit-account swaps between approval and funding. For each type it covers how the fraud shows up, the signals across documents, verification and bank data, the check that catches it, and the step a person has to take. It ends with a pre-funding control checklist and a documented fraud-review workflow. For the broader catalogue of warning signs, see fraud signals in small business lending; for forensic PDF analysis, see how to detect fake bank statements and edited PDFs.

01What fraud detection works for MCA lenders that need to catch identity fraud and business misrepresentation before funding?

The setups that work combine four evidence sources (submitted documents, independent verification, bank data and pre-funding contact) and route every conflict to a named reviewer before funds are released. A product that only scores documents, or only checks a registry, leaves whole fraud types uncovered.

Each point tool has a blind spot. A tampering checker will pass a genuine bank statement that belongs to a different business than the one applying. A registry lookup confirms a real, active LLC exists and says nothing about whether the person on the phone owns it. Bank data shows deposits, not that the deposit account was swapped yesterday. Each fraud type below exploits a gap between two sources, so the useful question is which check covers which type.

The matrix below maps the seven application-stage fraud types to the four evidence sources. A filled dot marks where the fraud usually shows up first; an open ring marks supporting evidence that strengthens or weakens the case. The same mapping holds whether the reviewer works at an MCA funder, a fintech lender or a credit union business-lending team; what changes is the policy, not the evidence.

02What are the main types of MCA application fraud?

Application fraud in merchant cash advance falls into two families: lies about who is applying (identity fraud) and lies about what the business is (misrepresentation). A third, smaller group happens after approval, when someone redirects where the money goes.

The families need different evidence. Identity fraud is answered by records the applicant cannot easily control. Misrepresentation is answered by reconciling the application against documents and bank data. Redirection is answered by process: freezing changes and verifying them out of band.

• Owner identity theft: a stranger applies with a real person's identity.
• Impersonation of a real business: the applicant poses as an established company they have no authority over.
• Misstated revenue, time in business or industry: the real owner inflates or disguises the business.
• Undisclosed positions: existing advances the application denies.
• Broker-facilitated fraud: someone in the submission chain alters or fabricates the file.
• Takeover of the merchant's bank login: bank data comes from credentials the fraudster controls.
• Contact-detail or deposit-account swaps: funding instructions change between approval and funding.

Two adjacent patterns sit outside this guide on purpose. Bust-out schemes, where a real merchant builds a clean history and then extracts as much as possible before defaulting, are covered in bust-out fraud in MCA lending. Entities built from scratch to look like real businesses are covered in shell companies and synthetic business identities. Both overlap with the types here, and the controls below help with them too.

03How does identity fraud show up in an MCA application?

Identity fraud shows up as a file where every document looks plausible on its own but the people, the entity and the bank account do not connect to each other. The catch is almost always a cross-source mismatch rather than a single bad document.

Owner identity theft

Someone applies as a real person. The name, SSN and date of birth are genuine, so a basic identity lookup returns a match. The FTC lists opening new accounts in a victim's name among the ways identity thieves use stolen information, and notes that unfamiliar accounts on a credit report are a warning sign for the victim (FTC: what to know about identity theft). In business finance, the stolen identity is usually attached to an entity the thief formed recently, or to a sole proprietorship with no registry record at all.

• Signals in documents: the ID image and the application disagree on address or date of birth; the voided check or statements show a different account holder name; the signature on the application does not resemble the one on the ID.
• Signals in verification: the owner's identity matches but the phone number or email has no history with that person; the entity was formed weeks ago with a registered agent address; the owner is not listed as an officer or organizer in the state record.
• Signals in bank data: the account was opened recently relative to the claimed time in business; deposits start abruptly; the account holder name is the person rather than the business.
• The check that catches it: identity verification of the owner with a live or document-plus-selfie step, matched against the registry officer list and the bank account holder name. FinCEN's alert on deepfake media lists inconsistencies among multiple identity documents, and geographic or device data that does not match the identity documents, among its red flags (FinCEN Alert FIN-2024-Alert004).
• The human step: a call to the owner on a number from an independent source, asking questions only the real owner would answer easily (their bank, their landlord, their main supplier), and recording who called, when and what was confirmed.

Impersonation of a real business

Here the target is not a person but an established company. The applicant pulls its public registry record, its address and its website, and presents themselves as an owner or officer. Because the business genuinely exists and has years of history, verification that stops at does this entity exist will pass it cleanly. The fraud lives in the gap between the entity and the applicant.

• Signals in documents: statements that are clean and internally consistent but whose account holder name differs slightly from the registered name (a missing suffix, a different DBA); an email domain that is not the company's website domain; a phone number that is a mobile line rather than the listed business line.
• Signals in verification: the applicant is not among the officers or members in the state filing; the company's website lists a different contact person; the registry shows recent amendments changing the registered agent or principal address.
• Signals in bank data: the deposit account on the application does not appear as the operating account in the statements, or the statements belong to the real business while the deposit account belongs to someone else.
• The check that catches it: bank account ownership verification that ties the deposit account to the business's legal name, plus confirmation that the applicant is a listed officer or holds documented authority. KYB verification software covers how registry matching and entity resolution work.
• The human step: call the business at the number on its own website or registry record, not the number on the application, and ask for the named owner. A real owner picks up or calls back; an impersonator usually cannot.

Synthetic and AI-assisted identity documents

Generated identity images now accompany both of the patterns above. FinCEN reports that criminals have used generative AI to alter or create images for identity documents such as driver's licenses and passports, and have combined those images with stolen or fake personal information to build synthetic identities. Its listed practices to reduce exposure include multifactor authentication and live verification checks, and it notes that a person using a deepfake identity may claim repeated technical glitches or ask to switch communication methods during a live check (FinCEN Alert FIN-2024-Alert004). An applicant who cannot complete a live check, or keeps steering to email, has given you a signal.

04How does business misrepresentation show up in MCA underwriting?

Business misrepresentation shows up as a gap between what the application states and what independent records and bank data support: revenue that the deposits do not carry, a formation date later than the claimed start, an industry code that does not match the counterparties, or positions the application denies but the debits reveal.

Misstated revenue, time in business or industry

This is the most common type, and the least dramatic. The business is real and the person applying owns it. The application just rounds monthly revenue up, claims three years when it has been operating for fourteen months, or describes a restricted industry as something your policy accepts. Sometimes the numbers are inflated on the application form only; sometimes the statements themselves have been edited to match, which turns misrepresentation into document fraud.

• Signals in documents: stated monthly revenue materially higher than the average true deposits on the statements; a tax return or P&L that does not reconcile with the bank activity; statements whose running balance does not recompute line by line.
• Signals in verification: a formation date later than the claimed start date with no predecessor entity; a registry or tax classification that differs from the stated industry; a web presence that describes a different line of business.
• Signals in bank data: large deposits from transfers between the owner's own accounts counted as revenue; counterparties that point to a different industry (a stated restaurant paying gaming suppliers); revenue concentrated in one or two payers.
• The check that catches it: a revenue reconciliation that separates true business deposits from transfers, loan proceeds and refunds, set against the stated figure. Bank statement analysis and the document intelligence layer do the structuring; the arithmetic check described in the fake bank statement guide catches edited balances.
• The human step: ask the merchant to explain the gap before treating it as fraud. A seasonal business, a recent acquisition or a predecessor sole proprietorship can explain a lot. Record the explanation and the evidence that supports or contradicts it.

Undisclosed positions

An application that says no current advances, attached to statements with fixed daily or weekly debits to funding companies, is misrepresentation even if every document is genuine. It is also the type that most directly damages the funder, because a new advance on top of undisclosed positions changes the merchant's capacity to perform. The detection mechanics are covered in depth in detecting stacking in merchant cash advance underwriting; the point here is the application check.

• Signals in documents: the position disclosure on the application is blank or says none; a statement month is missing or ends a few days early, right where a new debit would start.
• Signals in verification: UCC filings by funders or their filing agents against the business, which you can see in a lien search; the merchant's name appearing on several submissions in a short window.
• Signals in bank data: recurring fixed-amount ACH debits on business days, descriptions that resolve to funders, and large incoming wires followed by new recurring debits.
• The check that catches it: an automated debit-pattern scan across every statement month, compared with the disclosure on the application, plus a statement completeness check (no gaps in dates, no missing pages).
• The human step: ask the merchant, in writing, to list every current position with balances, and record the answer next to what the bank data shows. A disclosed position is a pricing and capacity question; a denied one that the data shows is a fraud question.

Broker-facilitated fraud

Most brokers and ISOs submit honest files. A few alter statements to clear minimums, fill in applications the merchant never saw, or reuse documents across merchants. Sometimes the merchant is in on it; sometimes they have no idea what was submitted in their name. Either way, the funder's only view of the merchant came through one party, and that is the vulnerability. The brokers and ISOs page covers how clean submissions help both sides.

• Signals in documents: files from the same broker that share fonts, producers or layout quirks across different banks; statements that were clearly recreated rather than downloaded; an application where the merchant's contact email is on the broker's domain or a generic mailbox.
• Signals in verification: the merchant's phone and email are absent or point to the broker; the same contact details recur on unrelated merchants.
• Signals in bank data: statement figures that do not match the bank data pulled directly from the merchant's account, when you have both.
• The check that catches it: pulling at least one source directly from the merchant (a bank data connection or statements downloaded during a verified session) and comparing it with what the broker sent, plus tracking findings by submitting broker so patterns become visible across files.
• The human step: a direct merchant call, made by the funder rather than the broker, that walks through the key figures on the application. Merchants who did not see their own application usually say so.

05How do account takeover and contact swaps hit the funding step?

These frauds attack the last mile: the bank data you trusted came from an account the fraudster controls, or the deposit account and contact details change between approval and funding. The control is procedural, because by this point the file itself looks approved.

Takeover of the merchant's bank login

A bank data connection is stronger evidence than an uploaded PDF, but only if the person authorizing the connection is the account holder. With stolen online banking credentials, a fraudster can connect a real business's account to show genuine history while directing funds elsewhere, or connect an account of their own and present it as the merchant's.

• Signals in bank data: the account holder name returned by the connection differs from the business on the application; the connection was authorized from a location or device inconsistent with the business; recent changes to the account's contact details or new external transfer recipients appear right before the application.
• Signals in pre-funding contact: the owner, reached on an independently sourced number, does not recognize the application or the connection.
• The check that catches it: compare the account holder name and account number from the connection with the deposit account on the funding instructions and with the statements, and treat any mismatch as a hold.
• The human step: if the real owner says they never applied, stop, record it and point them to the FTC's identity theft reporting at IdentityTheft.gov, which the FTC's identity theft page describes as the place to report and get a recovery plan. Their bank needs to know too.

Contact-detail and deposit-account swaps before funding

This is the business email compromise pattern applied to funding. The FBI's IC3 describes BEC as a scheme that often starts with a criminal taking over a legitimate business email account and then arranging an unauthorized transfer, and its first protective step is to verify requests to change account information through secondary channels or two-factor authentication (FBI IC3: business email compromise). In an MCA workflow the request looks routine: the merchant, or someone writing from the merchant's real mailbox, asks to fund to a different account because the old one is being closed. The email may come from the right address, which is exactly why the address proves nothing.

• Signals: a deposit account change requested after approval; urgency (fund today or the deal is off); a new account that never appears in the statements; a new account at a different bank or held in a personal name; a phone number change submitted in the same message, so a call-back would reach the fraudster.
• The check that catches it: a hard rule that no change to deposit account, email or phone takes effect without a call-back to a number on file from before the change, and ownership verification of any new account against the business's legal name.
• The human step: a second person approves any funding instruction change, and the call-back is logged with the number dialled, its source and the result.

06Which business identity data should risk teams require before funding?

Require the data that lets you connect the person, the entity and the deposit account through sources the applicant did not create: legal name and formation details from the registry, EIN evidence, beneficial owners and officers, a verifiable business phone and address, and a deposit account whose holder name matches the business.

More fields do not help on their own; fields you can check against something independent do. The list below is a practical minimum, with the source each field is checked against.

• Legal name, entity type, state and formation date: the Secretary of State record, including good standing.
• DBA or trade names: assumed-name filings where kept, and the name on the bank account.
• EIN: IRS-issued evidence such as a confirmation letter or filed return, never a typed number alone.
• Officers, members and beneficial owners: registry filings; the signer needs documented authority.
• Owner identity: identity verification, ideally with a live step, compared with the ID and application.
• Business phone and email domain: the business's own website, registry record or prior verified file.
• Operating address: address type (commercial, residential, virtual office, registered agent) and, for higher-risk files, imagery or a visit.
• Deposit account: ownership verification against the legal name, and the operating account in the statements.
• Current positions and liens: a UCC search and the debit pattern in the bank data.

For how automated sources cover these fields, and where they have gaps, see KYB for lenders. The Business Verification module is where these checks sit in the Cevrynt workflow.

07Where does KYC fit in MCA underwriting?

In MCA underwriting, KYC verifies the people (owners, guarantors and signers) while KYB verifies the entity, and both feed the same decision: is the person in front of us authorized to bind this business, and does the money go to this business. KYC that runs in isolation from KYB and bank data misses most of the fraud types in this guide.

Run as a pass-fail gate at intake, KYC catches fabricated people but not stolen identities or real owners lying about their business. KYC underwriting works when its outputs feed later checks: the verified owner should appear among registry officers, on the guarantee, on the contract signature and, for sole proprietors, on the bank account. A stolen identity tends to break at one of those points.

Three practical rules follow. First, the person who passes KYC must be the person who signs; a signer swap after verification is a reason to re-verify, not a formality. Second, a KYC result should record what was checked and how (document, database, live check), so a reviewer can tell a strong match from a weak one. Third, a declined or abandoned live check is a finding to record, consistent with FinCEN's red flag about customers who decline multifactor authentication or avoid live verification (FinCEN Alert FIN-2024-Alert004). For the conceptual split between the two, see KYB vs KYC for alternative lenders.

08What pre-funding controls stop application fraud at the last step?

A pre-funding control set is a short list of gates every file passes in order between approval and release of funds: owner identity confirmed, business identity confirmed, deposit account ownership verified, a call-back to an independently sourced number, and a freeze on unverified changes. Funds go only to the account that cleared every gate.

The gates are deliberately boring and run on every file. Most fraud types above fail at least one gate even when the documents are perfect, because faking a document is far easier than answering the real business's listed number or opening an account in its name.

09How should call-back verification to an independently sourced number work?

Call-back verification works only when the number comes from somewhere the applicant could not have edited: the state registry record, the business's own website, a directory listing that predates the application, or a number verified on a previous file. A call to the number on the application confirms only that whoever submitted it answers that phone.

Write the call-back down as a procedure, not a courtesy. The reviewer looks up the number before reading the contact details on the application, so they are not anchored by them. They call, ask for the owner by name and confirm a short list of facts: that the business applied, roughly how much it asked for, which bank it uses, the last four digits of the deposit account, and whether a broker submitted the file. They do not read those facts out and ask for a yes; they ask the owner to state them. If the owner is unavailable, the reviewer leaves a message asking for a call back to the funder's published main line, not a direct extension the applicant already has.

Plan for three failure modes. Mobile-only businesses may list the owner's cell everywhere, so lean harder on account ownership and the live identity check. A public listing changed in the last few weeks is weaker evidence than one stable for years. And call-backs fail quietly when they become a checkbox, so the log records the number's source, which makes a shortcut visible in review.

10What does a fraud-review workflow look like, and how should it be documented?

A fraud review starts when any check raises a flag: funding is held, a named reviewer gathers evidence from independent sources, the merchant is contacted through a verified channel, and the reviewer records a finding (cleared, cleared with conditions, or confirmed fraud) with the evidence behind it. The underwriter or credit authority then decides, and the record stays with the file.

1. Flag and hold. Any failed gate or material mismatch puts the file on hold and assigns a reviewer. The hold blocks funding, contract release and any change to funding instructions.
2. Scope the question. The reviewer writes the specific question being answered, for example: is the person who applied an authorized owner of Cedar & Stone LLC? Vague reviews drift.
3. Gather independent evidence. Registry record, identity verification results, account ownership result, bank data, lien search, and the original files with their hashes. Evidence the applicant supplied is labelled as such.
4. Contact through a verified channel. Call-back to the independently sourced number; questions and answers recorded.
5. Record a finding. Cleared, cleared with conditions (for example, fund only to the verified original account), or confirmed fraud. The finding cites the evidence, not just a conclusion.
6. Decide and route. The underwriter or credit authority decides on the deal. Confirmed fraud is routed to whoever handles your reporting and broker-relationship decisions.
7. Feed back. Patterns (a broker, a document template, a phone number reused across merchants) are added to the checks that run on the next file.

Documentation is what turns a reviewer's instinct into something the next reviewer, an auditor or a court can follow. The record below shows the shape that works: what was flagged, what was checked, the source of each piece of evidence, what the merchant said and who decided. The underwriting audit trails guide covers how to keep these records consistent across a portfolio.

{
  "file": "Cedar & Stone LLC (illustrative)",
  "flag": {
    "type": "deposit_account_change",
    "raisedBy": "pre-funding gate 5: change freeze",
    "raisedAt": "2026-10-14T15:42:00-04:00",
    "detail": "Email requested funding to account ending 9082; approved account ends 4417"
  },
  "hold": { "funding": true, "contract": true, "instructionChanges": true },
  "question": "Did the authorized owner request the account change?",
  "evidence": [
    { "item": "Registry officer list", "source": "state registry", "suppliedBy": "independent", "result": "owner listed as managing member" },
    { "item": "Account 4417 ownership", "source": "account verification", "suppliedBy": "independent", "result": "held in legal business name" },
    { "item": "Account 9082 ownership", "source": "account verification", "suppliedBy": "independent", "result": "held in an individual's name, not the owner" },
    { "item": "Change request email", "source": "merchant mailbox", "suppliedBy": "applicant channel", "result": "sent from owner's real address" }
  ],
  "callBack": {
    "numberSource": "business website, unchanged since 2023",
    "calledBy": "reviewer-07",
    "at": "2026-10-14T16:05:00-04:00",
    "result": "Owner did not send the request; will contact their email provider"
  },
  "finding": "confirmed_fraud_attempt",
  "conditions": "Fund only to account 4417 after owner re-verification",
  "decidedBy": "credit-lead-02",
  "notes": "Mailbox compromise suspected; merchant advised to secure email"
}

Whether a confirmed attempt triggers a regulatory report depends on who you are. FinCEN's alert notes that Bank Secrecy Act compliance obligations vary by financial institution type, and its suspicious activity reporting request is addressed to institutions with those obligations (FinCEN Alert FIN-2024-Alert004). Many MCA funders are not banks, and their obligations depend on structure, partners and state law, so the reporting route belongs in your written fraud policy, set with counsel, not decided file by file. A merchant who has been impersonated or whose email was compromised can report to the FBI through IC3, which the IC3 BEC page describes alongside asking the bank to attempt a recall.

11How do you avoid false positives and still treat applicants fairly?

Treat every signal as a question for a person, not a verdict: most mismatches have legitimate explanations, and the cost of wrongly calling a real merchant a fraudster is a lost customer and a broker relationship. The protection is a clear threshold for what triggers a hold, a fixed review procedure, and a recorded reason for every outcome.

Legitimate businesses trip fraud checks constantly: owners move, restructure from a sole proprietorship into an LLC, open a new operating account, or let a registry filing lapse and reinstate it. A new account requested before funding is ordinary when the owner can explain it and it passes ownership verification. FinCEN itself frames its red flags as indicators that warrant scrutiny rather than proof, and says no single red flag is necessarily indicative of illicit activity (FinCEN Alert FIN-2024-Alert004).

• Separate severity from count. One deposit-account holder mismatch outweighs five formatting quirks.
• Ask before concluding. A written request for an explanation resolves many flags and creates the record either way.
• Apply the same gates to every file. Consistency is both the fraud control and the fairness control.
• Keep findings neutral. Record what was observed and what it conflicts with.
• Review outcomes. Retire or retune checks that only ever produce noise.

Software can run every check on every file and lay out every conflict with its evidence. Deciding whether a conflict is fraud, an error or an honest change belongs to a reviewer, as described in human-in-the-loop AI underwriting.

From here, this article is about Cevrynt

12How Cevrynt approaches application fraud review

Cevrynt brings the evidence sources this guide relies on into one review. Document intelligence structures the submitted files with source links, bank statement analysis reconciles stated revenue and surfaces recurring debit patterns, business verification lays registry, ownership and account details side by side, and fraud signals shows where those sources disagree, with each flag linked to the evidence behind it.

Fraud and policy results are flags for a person. Cevrynt does not decline applications, make funding decisions or release funds; the reviewer records notes and overrides, and the underwriting report keeps the finding, its evidence and the decision-maker together in the file's audit history. Pre-funding controls such as call-backs remain your team's procedure, with Cevrynt holding the record of what was checked.

If your team funds merchant cash advances and wants to see how fraud flags and verification conflicts appear on an illustrative file, a walkthrough is the quickest way to judge the fit.