Merchant underwriting is the review a company performs before taking on risk from a business that sells goods or services. The term has two common meanings. Payment processors and acquirers underwrite merchants at onboarding to decide whether they can carry the merchant's card-processing risk. Lenders and funders underwrite merchants to decide whether the business's future revenue can support an advance or loan.

Both meanings show up in the same search results, and people often land on the wrong one. This guide treats both honestly. It explains how payments onboarding underwriting works (chargebacks, merchant category codes, reserves, the MATCH list, transaction monitoring), how merchant financing underwriting works (cash flow, existing obligations, verification, lender policy), where the two overlap, and where their risk questions part ways. It then walks through the signals, the data sources that surface them, what can be automated, and what to look for in merchant underwriting software.

What is merchant underwriting?

Merchant underwriting is a structured judgment about whether a business is legitimate and whether the risk it creates is acceptable at a given set of terms. Who performs it, and which risk they are measuring, depends on whether the merchant is asking to accept card payments or asking for capital.

Meaning one: underwriting a merchant to process payments

When a business applies for a merchant account, a payment facilitator account or a gateway with acquiring attached, the acquirer or processor takes on contingent liability for that merchant's card transactions. If customers dispute charges and the merchant cannot cover the refunds and chargebacks, the loss can flow back up the chain. Payments onboarding underwriting asks whether the business is real, whether its line of business is allowed under card network rules and the acquirer's own appetite, and how much exposure the processor will hold while sales can still be disputed.

Meaning two: underwriting a merchant for financing

When the same business applies for a merchant cash advance, revenue-based financing, a term loan or a line of credit, the funder is advancing capital and expecting to recover it from future receipts or scheduled payments. Merchant financing underwriting asks whether the business exists as claimed, whether its revenue is real and stable enough, what obligations already claim that revenue, and whether the deal fits the lender's policy. This is the sense in which alternative lenders, MCA funders and revenue-based finance companies use the term.

Why one term covers both

Both jobs look at the same business through overlapping data: identity records, card volume, refunds, chargebacks, deposits, web presence. Many commerce platforms also do both, onboarding merchants to process payments and later offering them capital. The vocabulary blurred as a result. The useful distinction is the exposure: a processor is exposed to the merchant's past and ongoing sales being reversed, while a lender is exposed to the merchant's future sales not arriving.

One merchant, two underwriting questions. The shared signals in the middle feed both paths, but each side weighs them against a different exposure.

How do payment processors underwrite merchants at onboarding?

A processor or acquirer underwrites a merchant by verifying the business and its owners, classifying what it sells and how it delivers, checking history including network termination lists, and then setting terms (reserves, settlement timing, volume limits) that cap the exposure it is willing to hold. The review continues after approval through transaction monitoring.

Classification: MCC, business model and delivery

The first question is what the merchant actually sells. The merchant category code (MCC) assigned at onboarding drives network rules, interchange and the acquirer's risk appetite, so misclassification is itself a risk. Underwriters look past the code to the business model: card-present or card-not-present, one-time or recurring billing, physical goods or services, and above all how long the gap is between payment and delivery. A merchant that takes payment today for something delivered months from now (travel, events, annual subscriptions, custom manufacturing) creates exposure that lasts as long as that gap, because if the merchant fails before delivery, customers will dispute the charges.

History: processing statements, chargebacks and the MATCH list

For a merchant switching processors, recent processing statements show volume, average ticket, refund levels and dispute history. Underwriters compare the requested monthly volume and average ticket to that history and to what the business plausibly sells. They also check whether the merchant or its principals were previously terminated. Mastercard describes its MATCH Pro system as mandatory for Mastercard acquirers, with an inquiry on the merchant and its principal owners submitted before the merchant agreement is executed. The database holds information reported by acquirers about certain merchants they have terminated. A MATCH hit is a reason to investigate and document, and acquirers set their own policies on how to treat it.

Card network rules and sponsor bank oversight

Card network rules sit over the whole relationship. Visa states that its Visa Core Rules and Visa Product and Service Rules govern its financial institution clients' participation in the Visa system, with some provisions applying to merchants and acquirers in particular regions, and it points merchants to their acquirer's acceptance agreement for further requirements. In practice, the acquirer carries network obligations for every merchant it signs, which is why onboarding policy tends to be strict about prohibited and high-risk categories.

Banks that hold accounts for payment processors are also expected to understand who those processors serve. The FDIC's guidance on payment processor relationships (FIL-3-2012, most recently amended in February 2026) expects banks to monitor processors and their merchants rather than rely only on the processor's own due diligence, to watch for rising complaints and elevated returns or chargebacks, and to confirm that reserve balances are adequate to cover chargebacks. More broadly, the federal banking agencies' interagency guidance on third-party relationships (June 2023) sets out a life cycle of planning, due diligence, contracting, ongoing monitoring and termination for bank relationships with third parties, including fintech companies.

Terms that cap exposure: reserves and settlement timing

Payments underwriting rarely ends in a plain yes or no. More often it ends in a yes with conditions designed to keep enough of the merchant's money on hand to cover future reversals:

  • Up-front reserve: a fixed amount held at the start of the relationship.
  • Rolling reserve: a percentage of each settlement withheld for a set period, then released on a rolling basis.
  • Delayed settlement: funds paid out on a longer schedule than standard, so disputes surface before money leaves the processor.
  • Volume and ticket limits: caps on monthly processing or single transaction size, reviewed as history accumulates.
  • Conditions and reviews: requirements such as delivery evidence, refund policy changes or a scheduled re-review.

Exact reserve levels and holding periods are commercial decisions that vary by processor, merchant and category, so any figure you see quoted generically should be treated as an anecdote rather than a rule.

After approval: transaction monitoring

Onboarding is only the first underwriting event. Processors monitor for volume spikes well beyond the approved profile, sudden changes in average ticket, rising refund or dispute ratios, card-testing patterns, and changes in what the merchant appears to sell. Any of these can trigger a re-review, a new reserve or termination. This ongoing monitoring is a major difference from most merchant financing, where the review is concentrated before funding and the follow-up is focused on remittance performance.

How is a merchant underwritten for financing?

A lender or funder underwrites a merchant by verifying the business, measuring the level and stability of the revenue that will repay the deal, identifying obligations that already claim that revenue, and checking the result against its own policy before a person decides on terms. The core question is forward-looking: will this business keep generating enough receipts to cover the remittance or payment?

The products differ in how they collect, and that changes what the underwriter weighs. A merchant cash advance purchases a share of future receivables and collects through a holdback or a fixed remittance. Revenue-based financing ties payments to a percentage of revenue. Term loans and lines of credit carry scheduled payments regardless of how sales move. We cover the structural differences in revenue-based financing vs term loan underwriting, and the general method of reading deposits, balances and obligations in cash flow underwriting for SMB loans.

Merchant cash flow underwriting, in the narrow sense people search for, focuses on the receipts a merchant actually collects: card settlements, marketplace payouts and other deposits, net of refunds and chargebacks, and the balance the business keeps after its existing obligations are paid. Underwriters look at monthly deposit totals and trend, the number of deposits, average daily balance, low-balance and negative days, NSF and overdraft events, and debits that look like other advances. Existing positions matter a great deal in MCA, since a merchant already remitting to two funders has less revenue free to support a third. Our guide to detecting stacking covers that specific problem.

Where the regulatory frame differs

Merchant financing is not governed by card network rules in the way acquiring is. The frame is the lender's own credit policy, the contract, and the federal and state law that applies to the specific product and lender. That varies. As one example, the CFPB's revised small business lending data rule under section 1071, published on May 1, 2026, excludes merchant cash advances from the definition of covered credit transaction and sets a compliance date of January 1, 2028, according to the final rule text. Several states also have their own commercial financing rules, such as disclosure requirements, and those differ by state and change over time. Lenders should confirm current obligations with counsel rather than relying on a blog summary, this one included.

Payments onboarding vs merchant financing: where do the risk questions differ?

The processor's risk is that money already collected from cardholders will be pulled back and the merchant will not be able to cover it. The lender's risk is that money not yet earned will never arrive. Everything else, the evidence each side favors, the tools it uses to control exposure and the rules it answers to, follows from that difference.

The same merchant, assessed against two different exposures. Specific practices vary by processor, lender and product.

Three practical consequences follow. First, a merchant that is attractive to one side can be unattractive to the other. A fast-growing subscription business with long prepaid terms may be a reserve-heavy onboarding case for a processor while showing exactly the revenue stability a funder wants. A seasonal restaurant with near-zero dispute exposure may sail through payments onboarding and still be a hard financing case in its slow quarter.

Second, the same signal can point in opposite directions. Rapid growth in card volume is a monitoring alert for a processor, because exposure is growing faster than history. For a lender it can be good news, provided the growth is real, persistent and not a one-off spike ahead of an application.

Third, a processor's decision is not a credit decision and should not be read as one. A merchant account approval tells a lender that a processor was willing to process for the business on certain terms. It says nothing about whether the business can carry an advance. Conversely, a reserve or a held settlement in the merchant's processor account is something a lender should notice, because it means some of the revenue on paper is not yet available to the business.

What merchant signals do both sides use?

Both sides rely on business identity, card volume and trend, refunds, chargebacks, web presence and uptime, and payout and deposit history. The data is shared; the interpretation is not. Each signal below includes how a processor and a lender typically read it.

Business identity and ownership (KYB)

Registration status, legal name and DBA consistency, formation date, address, EIN and beneficial owners. A processor needs this to know who it is contracting with and to run list checks on the owners. A lender needs it for the same reasons plus enforceability of the agreement and to catch identity-based fraud. Our KYB guide for lenders covers the checks and their data-coverage gaps in detail; it is the one signal both sides treat almost identically.

Card volume and trend

Monthly processed volume, transaction count and average ticket over time. Processors compare it to the approved profile; a sharp jump can indicate a business changing what it sells, or a bust-out. Lenders read it as the revenue base. For a merchant whose sales are mostly card-based, card volume should reconcile to settlement deposits in the bank account after fees, refunds and timing. When it does not, the gap is the finding.

Refunds

Refunds reduce net revenue for a lender and indicate product or fulfilment trouble for both. A rising refund rate in an e-commerce business can mean a bad product batch, a supplier problem or a shift toward a riskier channel. Lenders should calculate revenue net of refunds rather than reading gross sales, especially where a platform reports gross merchandise value.

Chargebacks and disputes

For a processor, the dispute ratio is close to the center of the risk model, because each dispute is a potential loss and excessive disputes can put the merchant into network monitoring programs. For a lender, chargebacks matter less as a ratio and more as a leading indicator: rising disputes often precede a processor reserve, a held settlement or a terminated merchant account, any of which would cut the revenue that repays the deal.

Web presence and uptime

Whether the business has a working site, a reachable checkout, consistent contact details, active listings and a domain whose age and ownership fit the story. For an online merchant, a storefront that has been down or a checkout that does not work is a direct revenue signal, not a cosmetic one. For processors, the site is also how they confirm what the merchant sells, its refund policy and its delivery terms. Both sides should remember that web presence corroborates; it does not prove. A real business can have a thin site, and a fabricated one can look polished.

Payout and deposit history

Processor settlements and marketplace payouts as they land in the bank. Platforms batch and remit on their own schedules, hold funds for new sellers and may hold reserves, so payout timing rarely matches sales timing. Lenders that read deposits without accounting for this can misjudge stability. Our post on underwriting Shopify and marketplace sellers goes deeper on reading processor payouts against bank deposits.

Illustrative only, no borrower data. A flagged signal goes to a person for review, never to an automatic decline.

What types of services surface merchant operational signals like website uptime and card volume?

Merchant operational signals come from a handful of service categories: processor and acquirer reporting, commerce platform and marketplace data shared with the merchant's permission, bank transaction data, business registry and KYB data providers, and web and domain monitoring. No single source covers everything, so underwriting models and review teams combine them and reconcile the overlaps.

  1. Processor and acquirer reporting. Processing statements, settlement reports and dispute reports give card volume, transaction counts, average ticket, refunds, chargebacks, fees and any reserves held. For a lender, these usually arrive as merchant-supplied statements or through a merchant-authorized connection, and should be reconciled to bank deposits.
  2. Commerce platforms and marketplaces. Storefront and marketplace data (orders, gross sales, refunds, payout schedules, account health and seller ratings) can be shared through merchant-permissioned connections where a platform offers them. Coverage, granularity and access terms vary by platform, so assume nothing is standard.
  3. Bank transaction data. Uploaded statements or permissioned bank-data connections show what actually landed: settlements, payouts, other deposits, balances and existing debits. This is where card volume becomes cash and where other funders' debits appear. See our bank statement analysis guide.
  4. Business registry and KYB data. State registries, federal tax identity confirmation and commercial data aggregators confirm the entity, its status and owners, and screening services check people and entities against watchlists. Data freshness differs by state and provider.
  5. Web, domain and listing monitoring. Site availability and checkout checks, domain registration age, SSL and DNS history, business listings and public reviews. These surface uptime and web-presence signals and help confirm what a merchant sells.
  6. Business credit and public records. Commercial credit files, liens, UCC filings and judgments add obligations and legal history that neither processing nor bank data shows directly. UCC filings in particular can reveal other funders.

Two cautions apply to every category. First, consent and purpose: data a merchant shares for processing is not automatically available for underwriting, and a lender should obtain its own authorization for any connection it uses. Second, freshness and coverage: a monitoring service checks only what it was configured to check, a registry may lag a recent filing, and a platform's report may describe gross merchandise value rather than cash received. An underwriting model that ingests these signals should carry the source and as-of date with each one so a reviewer can judge its weight.

What does a merchant underwriting workflow look like?

On the financing side, a merchant underwriting workflow typically runs from intake through documents, financial analysis, verification, fraud review and policy evaluation to a report that a human underwriter uses to decide. Payments onboarding has its own sequence (application, KYB and list checks, classification, risk scoring, terms, monitoring), but the rest of this section follows the lender's path.

Illustrative merchant-financing workflow. Fraud and policy results are flags and exceptions for a person; the decision stays with the underwriter.

A worked example: Cedar & Stone LLC (illustrative)

Take an illustrative applicant, Cedar & Stone LLC, a home-goods seller with its own storefront and a marketplace channel, applying for a merchant cash advance through a broker. The figures below are invented for illustration and describe no real business.

  1. Intake. The broker submits an application, four months of bank statements, the owner's ID and processing statements. The funder logs consent for the data it will use and checks the package is complete before anyone starts analysis.
  2. Documents. Statements are structured into transactions; the processing statements and marketplace payout reports are matched to the statement periods. Each extracted figure keeps a link to its source page.
  3. Financials. Deposits average a stable monthly level, but the underwriter separates card settlements and marketplace payouts from a one-time owner transfer in month two, which would otherwise inflate revenue. Two recurring daily debits look like existing advances.
  4. Verification. The LLC is active in its state registry; the owner on the application matches the registered member. The trade name on the storefront differs from the legal name, which the DBA filing explains.
  5. Fraud. No statement tampering indicators. The dispute reports show chargebacks rising over the last 60 days, which goes on the file as a flag, not a decline.
  6. Policy. The lender's rules allow at most one existing position for this tier. Two positions is a policy exception that needs a documented reason or a smaller offer.
  7. Report and decision. The underwriter reads the memo, calls the merchant about the disputes (a supplier delay on one product line, with refunds issued), confirms one of the two debits is a payoff in progress, and decides on a smaller amount with a shorter term. The software prepared the evidence; the person made the call.

Notice what the example does not do. It does not treat the processor's willingness to keep processing as proof of creditworthiness, and it does not let any single flag decide the outcome. It also shows why the chargeback trend matters to a lender at all: if those disputes had kept rising, the processor might have imposed a reserve, and the deposits the advance depends on would have shrunk.

Which parts of merchant underwriting can be automated?

Data gathering, extraction, reconciliation, calculation, list screening and rule checks automate well. Interpreting conflicting evidence, judging explanations, handling exceptions and making the final decision should stay with people. Automated merchant underwriting tools are most useful when they prepare a complete, sourced file quickly and route the hard questions to a reviewer.

Tasks that automate well on both the payments and financing sides:

  • Collecting documents and permissioned data, and checking a submission is complete.
  • Extracting transactions and statement fields, with links back to the source page.
  • Classifying deposits (card settlements, marketplace payouts, transfers, loans) and detecting recurring debits.
  • Calculating volumes, trends, average daily balance, negative days, refund and dispute ratios.
  • Running registry, watchlist and termination-list checks and recording the results.
  • Evaluating a file against written policy rules and listing every exception.

Tasks that need a person:

  • Deciding whether a mismatch is fraud, a data lag or an ordinary business change.
  • Weighing an explanation from the merchant or broker against the evidence.
  • Approving or declining a policy exception, and documenting why.
  • Setting final terms, or deciding not to proceed.

The failure mode to avoid is automation that hides its reasoning. A score with no sources forces a reviewer to either trust it blindly or redo the work. We discuss the design principle in human-in-the-loop AI underwriting, and the mechanics of rules and exceptions in what a loan policy engine does.

What should you look for in merchant underwriting software?

Start by deciding which merchant underwriting you are buying for. Software for payments onboarding is built around applications, KYB, list screening, MCC classification, reserves and ongoing transaction monitoring. Software for merchant financing is built around documents, bank and cash-flow analysis, existing obligations, lender policy and an underwriter's decision. Many evaluations go wrong because a team compares products built for different jobs.

People searching for the leading merchant underwriting platforms for fintech often expect a ranked list. A ranking is less useful than a fit test, because a payfac onboarding sub-merchants and an MCA funder reviewing broker submissions need different tools. Use the criteria below for the financing side, and our MCA underwriting software buyer's guide for a longer evaluation framework.

Merchant validation software is a narrower category, usually meaning tools that confirm a merchant is a real, registered, reachable business: registry checks, owner identity, address and phone verification, website and listing checks, and watchlist screening. It is a component of both kinds of merchant underwriting, not a substitute for either. A validated merchant can still be a poor credit risk or a high dispute risk.

Common mistakes in merchant underwriting

Most merchant underwriting errors come from reading a signal outside its context: treating gross sales as cash, treating a processor approval as a credit view, or treating one red flag as a verdict. The list below is drawn from patterns that recur on both sides.

  • Reading gross merchandise value as revenue. Platform dashboards often report gross sales before refunds, fees and reserves. Lenders should underwrite the cash that reaches the bank.
  • Ignoring payout timing. Weekly or held payouts make deposits look lumpy. Normalize for the schedule before calling revenue unstable.
  • Missing processor holds. A new reserve or delayed settlement in the merchant's processing account reduces available cash even when sales are steady.
  • Treating chargebacks as only a processor problem. Rising disputes are an early warning for lenders too.
  • Over-trusting web presence. A polished site is easy to fake, and a thin one can belong to a solid trade business.
  • Letting a flag become a decision. A MATCH hit, a registry mismatch or a fraud indicator should prompt investigation and documentation, with a person deciding.
  • Skipping reconciliation. Card volume, platform payouts and bank deposits should tie out. The unexplained difference is often the most important finding in the file.
  • Mixing up the two meanings in a vendor evaluation. A strong onboarding tool and a strong financing tool solve different problems.

From here, this article is about Cevrynt

How Cevrynt approaches merchant underwriting for lenders

Cevrynt works on the financing side only. It is AI-assisted underwriting software for MCA funders, alternative lenders and revenue-based finance companies; it does not onboard merchants for payment processing, set reserves or assess acquiring risk, and it is not a lender. The Cevrynt platform brings intake, documents, bank statement analysis, business verification, fraud signals and lender policy into one evidence-linked review, with each finding tied to its source.

For online sellers, the e-commerce merchant underwriting workflow treats commerce performance as one input alongside bank activity, verification and existing obligations, so platform signals inform the decision rather than replace it. Cevrynt × SHOPLINE is a documented development and referral partnership around e-commerce merchant-underwriting workflows; it is not a generally available live integration, and the partnership page sets out what it does and does not cover.

Fraud and policy results in Cevrynt are flags and exceptions for your team, and the lender keeps final approval authority on every file. If you want to see how a merchant file moves from documents to a decision-ready report, book a walkthrough.