Building a Credit Policy With Reason Codes and Human Review

Why written, versioned policy matters

Lending criteria tend to start as informal rules of thumb — 'we don't fund businesses with more than three NSFs in the last three months,' or 'minimum six months in business.' As a lending operation grows, informal rules applied inconsistently across underwriters create risk: similar files can get different outcomes, and there's no clear record of what the policy was at the time a decision was made. A written, versioned policy turns these rules into explicit, testable conditions, and keeps a record of which version applied to which file.

Structuring policy as conditions and reason codes

A workable policy structure expresses each criterion as a condition with a clear evaluation and a reason code, rather than a vague guideline. For example, instead of 'cash flow should be healthy,' a condition might be: 'average daily balance over the trailing three months must be at least $2,500 (reason code: LOW_ADB).' Instead of 'no recent NSF issues,' a condition might be: 'no more than 3 NSF items in the trailing 3 months (reason code: NSF_FREQUENCY).'

Each condition should map to a specific reason code so that when a file fails a condition, the output states exactly which condition and why — not just a general decline or flag. Reason codes also make it possible to track, across many files over time, which conditions are triggering the most often, which supports policy tuning.

Severity tiers and human review points

Not every failed condition should produce the same outcome. A practical policy distinguishes at least three tiers: conditions that produce a hard stop (the file cannot proceed without an exception approval from a defined authority level), conditions that produce a flag for review (the file proceeds to a human reviewer with the specific concern highlighted), and conditions that are informational (noted in the file but don't require action). Defining which conditions sit in which tier — and who has authority to approve an exception — keeps the policy usable without becoming either too rigid or too loose.

Human review points should be explicit: for example, any file with a detected active MCA position and a requested funding amount above a threshold routes to a senior underwriter regardless of other scores. Making these routing rules part of the written policy, rather than leaving them to individual discretion, keeps outcomes consistent.

A worked example

Consider a fictional lender's policy fragment: minimum adjusted monthly revenue of $15,000 (reason code REV_MIN, hard stop), no more than 2 negative-balance days in the trailing month (reason code NEG_DAYS, flag for review), and no detected financing position with daily remittance exceeding 15% of adjusted daily revenue (reason code STACK_RISK, flag for review, escalate to senior underwriter if two or more positions are detected).

A fictional applicant, Dune Valley Landscaping, shows adjusted monthly revenue of $22,000 (passes REV_MIN), 3 negative-balance days in the trailing month (triggers NEG_DAYS, routed to a reviewer with the specific days and transactions shown), and one detected MCA position with daily remittance equal to about 9% of adjusted daily revenue (passes the STACK_RISK threshold on its own). The file proceeds to a human reviewer with a single flagged reason (NEG_DAYS) and the underlying evidence, rather than a vague decline or an opaque pass.

Reviewer and policy-owner guidance

When building or reviewing a policy, confirm that every condition has a clear, testable threshold and a reason code; that severity tiers and escalation routing are documented, not implicit; and that every decline or flag a file receives can be traced back to the specific condition and evidence that produced it. Policy should be versioned so that a file decided under an older version can still be explained using the policy that was actually in effect at the time.

More in Underwriting Guides