By Othman Kabbaj, Co-founder

Policy Exceptions in MCA Underwriting: Route Them, Record Them, Learn From Them

Every MCA funder approves files outside its credit box; the risk is not the exception but the missing record. Each exception should sit in a queue with an owner, be decided by someone with authority, and be stored with a snapshot of the evidence the decision-maker saw.

Last updated: 30 October 2026

Exceptions are normal. Undocumented exceptions are not.

A credit box is a set of defaults: minimum true revenue, maximum positions, NSF tolerance, time in business, industry restrictions. Real files do not always fit.

A merchant with strong revenue and one extra position might be worth funding at a smaller amount. A seasonal business might miss a revenue minimum in its slow month. A good renewal client might have had a rough quarter. Good funders make these calls every week.

The trouble starts when those calls are made in a hallway, a text or a chat thread. Months later, when the merchant defaults or a syndication partner asks questions, nobody can say who approved the exception, on what basis, or what the file looked like at the time.

The three failure modes

1. Nobody owns it. An underwriter spots a policy breach and asks "can we do this?" in a group chat. Three people see it; nobody answers for four hours. The ISO sends the file to another funder.

2. The wrong person decides it. A junior underwriter clears an exception that should have gone to a credit manager, because nothing stopped them.

3. The record does not match reality. The approval note says "approved, strong revenue," but the revenue figure on the file was later updated after a new statement arrived. Nobody can tell whether the approver saw the old number or the new one.

Each failure has the same fix: treat an exception as a first-class object in the workflow, not a comment.

A framework: route, decide, record, review

Route

Every exception needs a place to wait and a person to own it.

• Raise the exception automatically when a policy check fails, not when someone remembers to ask.
• Put it in a queue that shows the deal, the rule that failed and how long it has been waiting.
• Let an underwriter claim it, so two people do not work the same file.

Decide

Decisions should be explicit and limited to people with authority.

• Use a small set of outcomes: approve, adjust (for example a smaller amount or shorter term) or decline.
• Restrict certain exceptions to senior staff or admins. A max-positions breach might need a credit manager; a missing voided check might not.
• Require a short written reason. "Approved" is not a reason.

Record

The record is what protects the funder later.

• Store who decided, when, and the outcome.
• Freeze a snapshot of the evidence at decision time: the true revenue figure, the positions, the NSF count, the documents on file. If the data changes later, the snapshot should not.
• Keep the record on the deal, where servicing, syndication partners and auditors can find it.

Review

Exceptions are a policy signal.

• Once a quarter, list the exceptions approved, grouped by rule.
• If the same rule is excepted again and again, the policy may be too tight, or the team may be too loose. Either way it deserves a conversation.
• Where you can, look at how excepted deals paid compared with in-policy deals. Even a manual review of a small sample is informative.

A worked example

The following is illustrative, with hypothetical details for example only.

A funder's policy caps positions at two. A file arrives with three active positions and true revenue well above the funder's minimum.

Three months later the merchant bounces two payments. The servicing team opens the deal and sees exactly why it was approved and what the positions looked like at the time. The conversation is about the decision, not about who made it.

What a good exception record contains

Use this as a checklist for your own records.

1. The rule that failed and the value that failed it
2. The deal and merchant
3. Who claimed the exception, and when
4. Who decided, their role, and when
5. The outcome: approve, adjust or decline, with any changed terms
6. The written reason
7. A snapshot of the key evidence at decision time
8. Links to the source documents

If your current records are missing items 4, 6 or 7, you have approvals, not an audit trail.

How DueDeal handles it

DueDeal treats exceptions as gates on the deal.

• Gate queue. Exceptions sit in a gate queue where underwriters claim and decide them.
• Authority. Decisions can be restricted to admins where the funder configures it.
• Frozen evidence. Every decision writes an audit entry with a frozen snapshot of the evidence and who resolved it.
• Evidence behind the rule. Positions are linked to their supporting transactions, and true revenue is shown with its netted amounts, so the snapshot reflects real evidence rather than a single score. See stacking and existing positions and true revenue in MCA underwriting.
• Verification feeding decisions. Where a funder's policy calls for it, a soft credit pull fires and its result feeds the approve, adjust or decline gate.
• Activity trail. Actions are recorded in an org-wide activity trail, with role-based permissions and deal visibility scopes.

Two practices in the framework above are not automated in DueDeal today. Exceptions are not auto-assigned to a named approver; they wait in the queue to be claimed. And DueDeal does not yet analyze how excepted deals performed. Because underwriting and servicing sit in the same record, that review can be done from one system, but it is a manual review.

Put your exceptions on the record

Keep your CRM and your analysis provider. Give DueDeal 20 deals in a parallel pilot and we will measure exception-resolution time alongside the rest of the manual work. Or book a demo.

Frequently asked questions

What is a policy exception in MCA underwriting? A policy exception is a funding decision on a file that falls outside the funder's credit box, such as too many positions or revenue below the minimum. The file is approved, adjusted or declined by someone with authority.

How should MCA funders track underwriting exceptions? Funders should raise exceptions automatically when a policy check fails, queue them with an owner, limit decisions to authorized staff, and store each decision with a reason and a snapshot of the evidence.

What should an underwriting audit trail include? An underwriting audit trail should include the failed rule, who claimed and decided the exception, the outcome and reason, the time of each step, and a snapshot of the evidence as it was at decision time.

Why freeze the evidence at decision time? File data changes as new statements and stips arrive. A frozen snapshot shows exactly what the decision-maker saw, which matters for internal review, syndication partners and disputes.

Who should approve MCA policy exceptions? Approval authority should match the risk of the rule. Serious breaches such as position limits usually need a credit manager or admin, while minor documentation gaps can be cleared by underwriters.

Does DueDeal record who approved an exception? Yes. Every gate decision in DueDeal writes an audit entry with a frozen snapshot of the evidence and the person who resolved it. Decisions can be restricted to admins.