Credit policy guide
Automated credit decisioning with humans in the loop: rules, waterfalls, and when to auto-decide
Last updated · Kaaj editorial team
To automate credit decisions without losing control, write your policy as two layers: hard-stop knockouts (restricted industry, entity status, time in business, fraud flags) and scored factors (credit, cash flow, DSCR, collateral). Run the cheapest checks first so obvious declines never pay for a full credit pull or bank-statement analysis. Auto-decide only inside a clearly defined box, usually small tickets where every rule passes, and route everything else, including new businesses and exceptions, to an underwriter with the reasons attached. Backtest rule changes on past applications, keep the rules in your team's hands, and log every decision. Kaaj applies lender-defined rules as pass or fail checks with reasons, runs inexpensive checks first, and can feed its results to the decision engine you already use.
How to set up automated decisioning in 10 steps
Start conservative: automate declines and data gathering before you automate approvals.
Write the policy down as rules
Turn each guideline into a testable rule with a threshold and a source, for example minimum time in business from the state record, not from the application.
Separate knockouts from scored factors
Knockouts decline or route a file on their own. Scored factors combine into a scorecard or weighted matrix for everything that survives.
Order checks by cost
Run instant checks (industry, entity status, fraud) first, then a soft credit pull, then bank-statement and financial analysis. Obvious declines should never reach the expensive steps.
Set hard-stop declines carefully
Common hard stops include restricted industries, inactive entities, confirmed document tampering, and extreme NSF counts or negative days. Keep the list short and review it often.
Define the auto-decision box
Limit automatic approvals to a narrow set, such as small tickets from established businesses where every rule passes. Everything else goes to a person.
Route exceptions with reasons
New businesses, deals using personal financials, and borderline scores should reach an underwriter with the rule results and evidence attached.
Decide what the output is
Approve and decline, or also a risk tier that drives pricing and structure. Keep humans responsible for exceptions either way.
Backtest before you switch on
Run a new or changed rule on past applications and compare with what actually happened before it touches live deals.
Keep the rules in your hands
Your credit team should be able to see and change thresholds quickly after a market shock, with every change dated and logged.
Get compliance sign-off and log everything
Have compliance review automated decisions before launch, and keep a record of every rule result, decision, and override for audit and adverse-action notices.
A credit-first waterfall
Each stage costs more than the last, so each one only runs on files that survive the previous stage.
Credit-first waterfall · cheapest checks first
Every stop and route should show its reason, so an underwriter can review or override it.
Knockouts vs. scorecards
| Pass/fail knockouts | Weighted scorecard or matrix | |
|---|---|---|
| What it does | Declines or routes a file on one rule | Combines many factors into a score or tier |
| Best for | Non-negotiables: restricted industries, fraud, inactive entities | Credit, cash flow, DSCR, collateral, and time in business together |
| Risk | Too many knockouts decline good deals | Opaque if weights are not documented |
| Explaining decisions | Easy: the rule that failed | Needs the top contributing factors |
What to automate and what to keep with underwriters
| Decision | Automate? |
|---|---|
| Declines on hard-stop rules | Yes, with the reason logged |
| Data gathering, verification, and analysis | Yes |
| Approvals inside a narrow small-ticket box | Yes, after backtesting and compliance review |
| New businesses and startups | Route to an underwriter |
| Deals using personal financials or guarantor strength | Route to an underwriter |
| Large tickets and committee deals | Underwriter and committee decide |
| Exceptions and overrides | Underwriter decides and documents |
Frequently asked questions
How do you encode a credit policy into a rules engine?
Write each guideline as a rule with a data source and threshold, split non-negotiable knockouts from scored factors, and test the rules on past applications before using them live.
Can small-ticket equipment deals be auto-decided while humans handle larger ones?
Yes. Many lenders auto-decide a narrow small-ticket box where every rule passes and send everything else, including larger deals and exceptions, to underwriters and committee.
What is a credit-first waterfall?
An order of checks from cheapest to most expensive, so obvious declines are caught by instant checks or a soft pull before anyone pays for full bank-statement or financial analysis.
Who should maintain the rules, the lender or the vendor?
The lender should own the rules and be able to change thresholds quickly, with every change logged. In Kaaj, rules are configured to your policy and your team decides when they change.
Can AI underwriting feed an existing decision engine?
Yes. Verified KYB, bank-statement, and fraud results can be sent by API or webhook, or written to Salesforce, so an existing scorecard or decision engine makes the call.
Do we need compliance approval before turning on auto-decisioning?
You should have compliance review it first, including how decisions are explained and how adverse-action notices are produced. Automated declines still need clear, specific reasons.
How should we test a new knockout rule?
Backtest it on historical applications and compare its decisions with actual outcomes before it touches live deals, rather than learning from a live split.
Apply your policy the same way on every file
Kaaj runs your rules as pass or fail checks with reasons, runs inexpensive checks first, and sends results to your CRM, LOS, or decision engine.