Policy & Decisioning guide: MCA Underwriting Rules: How to Set Hard Stops for NSFs, Negative Days and Restricted Industries

MCA underwriting rules with hard stops usually cover time in business, minimum monthly deposits, NSF days over a fixed window, negative-balance days, open positions, restricted industries, excluded states, prior defaults and identity mismatches. A hard stop only works if it names the metric, the window, the counting method, the data source, the threshold and what happens next, including who confirms it.

This guide is for credit, risk and operations teams at MCA funders and alternative lenders writing or cleaning up knockout criteria. It covers the rule families funders commonly use, how to define each so two analysts get the same answer, hard stop vs soft flag vs exception, versioning and testing rules on past files, and fair-lending and adverse-action points. Every threshold is an illustrative example, never a recommendation.

01What hard-stop auto-declines can you set for NSF count, negative days or restricted industry?

You can set a hard stop on any condition your written credit policy says you will not fund, as long as the condition can be measured the same way on every file: NSF days in a window, negative-balance days in a window, and an industry code on a prohibited list are all measurable. Whether a hard stop fires an automatic decline or routes to a person is your policy choice, made in your own system.

The three examples behave differently. An industry restriction is close to binary, and the hard part is classifying the business correctly. NSF and negative-day rules are counts derived from bank statements, so the hard part is the arithmetic: which accounts, which days, which transactions, and what happens when a page is missing. 'No more than 5 NSFs' looks precise but hides four or five decisions analysts will otherwise make differently.

Many funders call these rules 'auto-declines' because their origination system closes the file when one fires. That is a legitimate design with a cost: every data error becomes a lost deal or an unexplained decline. A common middle ground treats the hard stop as a strong presumption: the file is parked and a person confirms the inputs were right before the decline is issued. The human-in-the-loop guide covers where that check pays for itself.

02What is the difference between a hard stop, a soft flag and an exception?

A hard stop is a condition your policy says ends the file. A soft flag is a condition that needs a person to look at it before the file moves on. An exception is a documented, approved decision to proceed even though a rule was not met. They are three different tools, and most rule sets go wrong by using one where another belongs.

Hard stops should be reserved for conditions where no amount of context changes the answer. Good candidates are things your funding agreements, syndication partners or legal advisers have ruled out: a prohibited industry, a state you do not fund in, a business that is not legally in existence, an applicant on a sanctions list. Conditions that are bad but explainable, such as a cluster of NSFs during a documented one-off event, are usually better as flags with a higher threshold that escalates to a stop.

Soft flags are where most of a rule set lives. A flag says: this is outside the comfortable range, look at it. It should carry its evidence with it, so the underwriter sees the eight NSF days and the transactions behind them instead of re-deriving them. It should also say what would clear it. 'NSF days above 6; clear if the activity is concentrated in one documented period and the last 30 days are clean' is a flag an underwriter can act on. 'High NSF' is not.

Exceptions are the release valve. A well-run policy states which rules can be excepted, by whom, and what evidence the exception record must contain. Some hard stops should be non-exceptable by design: if a funding partner prohibits an industry, nobody at the funder can grant an exception to that. Others, like a time-in-business minimum, are often exceptable at a senior level when there is a predecessor business or a strong owner history. The guide to exceptions and overrides covers how to record them; the point here is that the rule definition itself should say whether an exception is possible.

03Which knockout criteria do MCA funders commonly write?

Most merchant cash advance underwriting rule sets cover the same ten families: time in business, revenue or deposits, NSF activity, negative days, average daily balance, existing positions, industry, state, prior defaults and identity or ownership consistency. The families are shared across the industry; the thresholds, windows and actions vary widely from funder to funder and from product to product.

Time in business

Define the start date source before the threshold. The formation date on the state registry, the first deposit on the earliest statement and the date the applicant writes on the form often disagree. Pick one primary source, usually the registry record found during business verification, and say how to treat a business that re-registered after a change of entity type. An illustrative rule: 'Months since formation per state registry, under 6 = stop; 6 to 11 = flag.'

Minimum monthly revenue or deposits

Gross deposits are not revenue. The rule must say which deposits count: exclude transfers between the business's own accounts, loan or advance proceeds, refunds and reversals, and owner capital injections, or at least report them separately. Then say how months are aggregated: an average over the window, a minimum in any single month, or both. A business averaging well above the line with one near-empty month tells a different story from one that is steady. Example: 'True deposits, average of last 3 full months, under $15,000 = stop.'

NSF count and frequency

This is the rule that most needs a written counting method, covered in its own section below. At minimum it names the window, whether you count events or days, and how fees, returned items and overdraft items are treated. Frequency matters as much as the count: six NSF days spread across three months reads differently from six in the final two weeks. Many funders use two rules, one for the whole window and one for the most recent 30 days.

Negative days

A negative day is a day the account closed below zero, but statements do not always print a daily closing balance. The rule must say how the balance is reconstructed and whether intraday dips count. A common example: 'Days with an ending ledger balance below zero, last 90 days, summed across operating accounts, over 10 = stop.'

Average daily balance

Average daily balance is usually a pricing and sizing input rather than a knockout, but some funders set a floor. If you do, define the denominator (calendar days or banking days) and the window, and decide whether balances are combined across accounts. The ADB and DSCR guide explains what the metric does and does not measure.

Existing positions and stacking

Position rules count active advances or loans, usually seen as recurring daily or weekly debits to funders, plus anything disclosed on the application. Define what makes a position active (a debit in the last 14 days, for example), how a renewal is told apart from a new position, and whether disclosed but not yet visible positions count. A typical structure is a flag at one count and a stop at a higher one. Detection itself is covered in the stacking guide.

Restricted and prohibited industries

Keep two lists. A prohibited list is a hard stop and is usually driven by funding partners, banks and legal advice. A restricted list is a flag that triggers extra review or a different program. Both lists should be written as industry codes with plain-language descriptions, not just as words, because a keyword list will both miss businesses and catch innocent ones.

State restrictions

State rules decide where you will fund and which disclosures or licences a deal needs. Define which state the rule reads: the state of formation, the principal place of business, or the location of the owner. They can differ, and a Delaware entity operating in another state is ordinary. Requirements vary by state and change over time, so keep the list owned by compliance, not hard-coded by engineering.

Prior defaults

Prior-default rules typically look at your own history with the merchant or its owners, plus any default evidence in the file such as collection debits or legal judgments. Define the lookback, whether a settled default counts, and whether the rule follows the owner across different businesses. That last choice is a significant policy decision and deserves a written rationale.

Ownership and identity mismatches

These rules compare names, addresses, tax identifiers and owners across the application, statements, registry records and identity checks. A mismatch is rarely a hard stop on its own, because businesses use trade names and move offices. A good pattern is to define tolerances (name variants, suite numbers) and then flag what is left, with a hard stop reserved for confirmed identity failures. These signals overlap with fraud signals, so decide which team owns each one.

04How do you define an MCA underwriting rule precisely?

A precise rule names eight things: the metric, the window, the counting method, the data source, the threshold, the action, the reason text and the version. If any of these is left to the analyst, the rule will be applied differently on different desks, and you will not be able to tell whether a change in outcomes came from the deals or from the people.

Window. Say whether the window is calendar days, statement months or banking days, and what it is anchored to: the submission date, the last statement's closing date or the date of review. A 90-day window anchored to the last statement's end date is stable; one anchored to 'today' changes while the file sits in the queue.

Counting method. Events or days, gross or net of reversals, per account or combined. Write examples into the rule: 'Two NSF fees on the same day count as one NSF day.' Examples settle more arguments than definitions.

Data source. Name the document and the field. If the source is the bank statement, say which accounts are in scope and what happens when the applicant submits only some of them. If the source is a third-party check, say what to do when it returns nothing. A 'not found' is a different fact from a 'failed'.

Missing data. Every rule needs a branch for when it cannot be evaluated: a statement month is missing, a page is unreadable, the industry cannot be classified. The safe default is 'cannot evaluate, route to a person', never 'pass'. A rule that silently passes on missing data is the most common way a rule set leaks.

Reason text. Write the explanation the rule produces in words a merchant or broker could understand. This matters for adverse-action notices where they apply, discussed below, and it matters for the broker relationship: a decline reason a broker can act on leads to cleaner resubmissions.

Writing rules as structured data rather than prose makes all of this checkable. The example below is illustrative. It is not a schema from any particular product, and the thresholds are placeholders.

rule_id: nsf_days_90
version: 3
effective_from: 2026-11-01
owner: credit-policy
metric: nsf_days
definition: >
  Distinct calendar days with at least one NSF fee,
  returned debit or overdraft-item fee, across all
  operating accounts in scope.
window:
  length_days: 90
  anchor: last_statement_end_date
counting:
  unit: day
  exclude: [fee_refunded_same_cycle, bank_error_reversal]
data_source: bank_statements
missing_data: route_to_review   # never pass
thresholds:
  - when: "value > 12"
    action: hard_stop           # lender's choice: auto-decline or confirm
    exceptable_by: [credit_director]
  - when: "value > 6"
    action: flag
reason_text: Frequent insufficient-funds activity in the last 90 days
change_note: Moved stop from 10 to 12 after replay on Q3 files

05How should NSFs, returned items and overdrafts be counted?

Decide whether your rule counts NSF days or NSF events, list exactly which bank fee and transaction types qualify, and say how refunds, reversals and multiple accounts are handled. Banks label these items inconsistently, so the counting method has to be defined by what happened, not by the word on the statement.

On a statement, the same underlying event can appear several ways. A debit may be paid into overdraft with an overdraft fee, returned unpaid with an NSF or returned-item fee, or represented by the payee and returned again a few days later. A single failed ACH payment represented twice can generate three fee lines. Counting fee lines would score that as three events; counting distinct days might score it as three days or as one, depending on timing. None of these is wrong, but the rule must pick one.

• NSF or returned-item fee: the bank declined to pay an item for lack of funds. Most funders count these.
• Overdraft fee or item: the bank paid the item and the balance went negative. Some funders count these here; others leave them to the negative-day rule to avoid double counting.
• Returned deposit: a payment the business received bounced. That is a deposit-quality signal and usually belongs in a separate rule or a fraud review.
• Represented items: the same payment returned more than once. Decide whether each return counts or whether the series counts once.
• Refunded or waived fees: a fee the bank later refunded. Decide whether the underlying event still counts. Often it does, because the funds were still short.
• Extended or continuous overdraft fees: fees charged for staying negative. These usually belong to the negative-day rule, not the NSF count.

Counting days rather than events is a popular choice because it dampens the representment problem and matches how many underwriters already think about stress. Counting events is more sensitive and may suit a product with tight daily remittances. Whichever you pick, apply it identically to every account in scope. The NSF patterns guide explains how to read the pattern once it is counted; this rule only needs to count it consistently.

Multiple accounts are the other trap. NSFs on a payroll account that is topped up the day before payroll may be cash management, not stress. Summing across accounts is simple and conservative; evaluating only the primary account is easier to game. A middle path sums across accounts for the stop and shows the per-account split in the evidence.

06How do you write rules for negative days and average daily balance?

Define a negative day by the account's end-of-day ledger balance, say how that balance is reconstructed when the statement does not print it, and set the window and account scope the same way you did for NSFs. For average daily balance, fix the denominator and decide whether the floor is a stop, a flag or only a sizing input.

Many statements show a running balance after each transaction rather than a daily closing balance. A day's closing balance is then the balance after its last posting, and quiet days carry the previous balance forward. That carry-forward step is where errors creep in, around weekends and statement boundaries. If a daily series cannot be reconstructed with confidence, the rule should say 'cannot evaluate', not assume a positive balance.

Intraday negatives are a policy choice. A balance that dips below zero at noon and recovers by end of day did not close negative, but it may have triggered an overdraft item. If your NSF rule already counts overdraft items, ignoring intraday dips in the negative-day rule avoids double counting. Write that reasoning into the rule's change note so the next person understands it.

For average daily balance, the usual definition is the sum of daily closing balances divided by the number of calendar days in the window. Using banking days instead inflates or deflates the result depending on weekend balances. If you combine accounts, combine daily balances first and then average, rather than averaging each account and adding the averages; the results differ when accounts were opened or closed inside the window.

07How do restricted-industry and state rules work in an underwriting decision engine?

Industry and state rules are list lookups: classify the business, look up the class on a prohibited or restricted list, and return stop, flag or pass. In an underwriting decision engine the lookup is trivial; the classification step and the list's ownership are where errors and disputes come from.

Classification starts from what the applicant says, then gets checked against registry filings, the website and the transaction pattern. When sources disagree, the rule should flag the disagreement rather than pick the convenient answer. Writing lists in an industry coding system (such as NAICS) with plain-English descriptions lets you audit why a business landed where it did.

Lists should carry their own source and date. 'Prohibited per syndication agreement with Partner A, effective March 2026' is a list entry anyone can audit; 'no cannabis' is not, because it does not say whether ancillary businesses, landlords or equipment sellers are included. Review each list on a fixed schedule and when funding agreements change.

State rules work the same way, with one more dimension: state law. Several states have adopted commercial financing disclosure laws that can reach sales-based financing. New York's Department of Financial Services, for example, adopted a regulation implementing the state's Commercial Finance Disclosure Law for certain commercial financings of up to $2,500,000, with separate formatting requirements for sales-based financing (NY DFS announcement). Requirements differ by state, apply at different thresholds and change, so a state rule in your engine should point to a compliance-owned table rather than encode the law itself. The engine's job is to make sure the right state is identified and the right workflow is triggered.

08Underwriting model vs decision engine: where do knockout rules belong?

Knockout rules belong in the decision or policy layer, not inside a scoring model. A model estimates risk from patterns; a decision engine applies your stated policy to the facts. Keeping hard stops as explicit rules means you can explain every stop, change a threshold without retraining anything, and show an auditor exactly which version applied.

The vocabulary is messy. 'Loan engine', 'banking policy engine', 'underwriting decision engine' and 'decision engine' are often used for the same thing: software that takes structured facts about an application and applies a lender's rules to produce outcomes. An underwriting model is something else, usually a statistical or machine-learning score. The decision engine vs underwriting engine article draws the scope lines, and what is a loan policy engine covers what the policy layer does. For rule writing, the practical consequence is this:

• Inputs come from analysis. Bank statement extraction, business verification and fraud review produce the facts: NSF days, negative days, industry class, open positions. The rules should consume those facts, not recompute them.
• Rules apply policy. Each rule compares a fact to a threshold and returns a result with its reason. A model score can be one of the facts a rule reads, but the knockout decision stays an explicit rule.
• People decide. The combination of results routes the file. The final call, and any exception, belongs to a named person.

Putting a hard stop inside a model, for example by training on past declines so the model learns to score prohibited industries low, is a common mistake. It makes the stop probabilistic, hides it from reviewers, and means a policy change requires retraining. The explainable AI guide covers why explicit reasons matter when automated analysis is involved.

09How should underwriting rules be versioned and tested against past files?

Give every rule a version, an effective date, an owner and a change note, record which version evaluated each file, and replay any proposed change against a set of past files before it goes live. The replay shows which deals the change would newly stop and which it would newly release, and those are the files a person must read.

Versioning answers the question an auditor, capital partner or credit committee will eventually ask: why was this file declined in March but a similar one approved in June? With versions, the answer is 'the NSF stop moved from 10 to 12 days on June 1, for this reason'. Store the version on the file at evaluation time and keep old versions readable.

A replay is not a strict statistical backtest, and it has a blind spot: declined files have no performance data, so you cannot know how newly released ones would have repaid. Its purpose is to make a change's consequences visible before it ships, so a credit lead can read the files in the changed cells and judge whether the rule does what it was meant to.

1. Pick the replay set. A recent, representative set of funded, declined and withdrawn files from several brokers and industries.
2. Freeze the inputs. Use the facts as extracted at the time, so you test the rule, not changes in extraction.
3. Run both versions and record each file's result under each.
4. Read the changed cells. Every newly stopped and newly released file gets a short human review; for funded files now stopped, check how they performed.
5. Check for concentration. If changed files cluster in one state, industry or broker, ask whether that is intended. This is also where fair-lending concerns surface.
6. Record and schedule. Write the change note, set an effective date and plan when to review exception rates.

After launch, watch the exception rate per rule. A rule that is overridden on a large share of the files it flags is telling you its threshold or its definition is wrong. A rule that never fires may be redundant or may be broken. Both deserve a look at the next policy review. The audit trail guide covers what to keep so this review is possible.

10What fair-lending and adverse-action rules apply to hard stops in business credit?

Where a financing is business credit under the Equal Credit Opportunity Act and Regulation B, you may not use a rule to discriminate on a prohibited basis, and a decline generally triggers adverse-action notice duties, with specific reasons rather than 'did not meet internal policy'. Whether a given MCA agreement is credit is a legal question, so confirm coverage with counsel and treat these practices as good discipline either way.

Regulation B defines business credit as extensions of credit primarily for business or commercial purposes, and adverse action as including a refusal to grant credit in substantially the amount or on substantially the terms requested (12 CFR 1002.2). Many MCA agreements are written as purchases of future receivables rather than loans, and how a particular product is characterised depends on its terms and on the law that applies. Funders that also offer term loans or lines of credit will have products that are plainly in scope.

For business credit, Regulation B's notice rules depend on the applicant's size (12 CFR 1002.9). For businesses with gross revenues of $1 million or less in the preceding fiscal year, the creditor may give the statement of action orally or in writing and may disclose the right to a statement of reasons at the time of application. For businesses above $1 million, notice must be given within a reasonable time, and written reasons are required if the applicant asks in writing within 60 days. The same section says a statement of reasons must be specific, and that saying the applicant failed to meet internal standards or policies is not enough. That is the practical reason every rule in your set should carry its own plain-language reason text.

On discrimination, Regulation B lets a creditor consider any information it obtains, as long as it is not used to discriminate on a prohibited basis (12 CFR 1002.6). The current text on the CFPB's site states that the Act does not provide that the 'effects test' applies, while its official interpretation still treats facially neutral criteria as a problem where they function as proxies for protected characteristics and are designed or applied with that intent. State fair-lending laws and other regulators can take broader views, and positions on disparate impact have changed over time. For rule writers, the safe practice does not depend on which view prevails:

• Do not write rules on prohibited bases, and do not write rules that stand in for them, such as excluding areas or customer types for reasons unrelated to credit risk.
• Write down the credit rationale for every hard stop when you create it. A restricted-industry or state exclusion with a documented business reason is far easier to defend than one nobody can explain.
• Use the replay step to look for unexplained concentration of new stops in particular geographies or business types.
• Have counsel review the prohibited and restricted lists, the state table and the reason texts.

A note on Section 1071 data collection, which comes up in these conversations: the CFPB published a final rule on May 1, 2026 reconsidering parts of the small business lending data rule and extending its compliance date to January 1, 2028 (CFPB compliance page). The CFPB's unofficial redline of that rule lists merchant cash advances among the excluded transactions (CFPB unofficial redline, PDF); the Federal Register text controls. That exclusion is about data reporting under subpart B, not about the rest of Regulation B, and requirements can change again, so check the current rule before relying on it.

11What are the most common mistakes when writing knockout rules?

The most common mistakes are undefined counting methods, rules that pass when data is missing, hard stops that should have been flags, thresholds copied from another funder, and rule changes with no version or rationale. Each one makes outcomes inconsistent in a way that only shows up months later.

• Threshold without definition. 'Max 5 NSFs' with no window, unit or account scope, so two analysts count differently.
• Too many hard stops. Explainable conditions turned into auto-declines lose good deals and teach brokers to send files elsewhere.
• Double counting. One overdraft feeding the NSF rule, the negative-day rule and the ADB floor, so one bad week trips three rules.
• Copied thresholds. Numbers taken from someone else's guidelines without checking them against your own book and product.
• Rules nobody owns. Lists and thresholds edited by whoever has access, with no change note.
• Rules that fight the analysis. A rule recomputing a metric differently from the analysis the underwriter sees.

From here, this article is about Cevrynt

12How Cevrynt approaches lender-defined rules and hard stops

Cevrynt is AI-assisted underwriting software for MCA funders and alternative lenders. Its Policy Engine evaluates each file against the lender's own rules and shows the result of every rule, pass, flag or exception, next to the evidence that produced it, such as the statement lines behind an NSF count from bank statement analysis. Cevrynt does not auto-decline files and does not make funding decisions. If a lender's own policy treats a rule as an automatic decline, that action is the lender's choice and lives in the lender's own systems; in Cevrynt, results surface as flags and exceptions for a person to review.

Reviewer notes, overrides and exceptions are recorded with the file, so the reason and the approver stay attached to the decision. The final decision always belongs to the lender's underwriter. For MCA-specific workflows, see merchant cash advance underwriting, or book a walkthrough to discuss how your current rules would be represented. Teams who want to try it on their own files can also ask about a pilot.