GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here!
Watch the launch videoWatchApplicant Risk Assessment
Scoring system that evaluates credit history, income stability, and debt ratios to categorize insurance applicants into risk tiers.
Solution
This automated risk assessment system evaluates insurance applicants across multiple financial dimensions to determine risk categories and appropriate next steps. The system analyzes credit profiles by examining credit scores, payment history, and established credit duration. It then evaluates financial stability through employment tenure, income verification status, and banking history.
The debt analysis component calculates risk based on debt-to-income ratios and existing loan obligations. After processing all factors, the system assigns a comprehensive risk score and classifies applicants as low, medium, or high risk. Each classification triggers specific actions, including automatic approval, manual review requirements, or additional verification processes. The system also determines appropriate interest rate modifications based on risk level, allowing insurers to price policies accurately while streamlining the underwriting process.
How it works
The decision graph contains multiple evaluation nodes that systematically assess risk:
- Credit History Scoring: Evaluates credit score, late payment history, and credit history length, assigning points based on predefined thresholds.
- Income Stability Assessment: Analyzes employment duration, income verification completeness, and bank account standing to determine financial reliability.
- Debt Burden Calculation: Measures debt-to-income ratio and number of outstanding loans to evaluate financial obligations.
- Risk Score Aggregation: Combines all component scores and identifies any concerning factors where applicants scored zero points.
- Risk Classification: Categorizes applicants into low, medium, or high risk tiers based on total score and number of negative factors.
- Action Determination: Assigns appropriate approval status and interest rate adjustments based on risk category.
Where teams use it
- Insurance policy underwriting
- Premium calculation and risk-based pricing
- Policy renewal assessments
- Fraud prevention screening
- Automated application processing
- Agent-assisted policy issuance
Inside the decision model
Applicant Risk Assessment ships as a JDM decision graph with 9 nodes, 3 decision tables and 13 rules. Download it, load it into GoRules, and run it as-is on Zen Engine.
Request
inputEverything hangs off a single applicant object: creditScore, latePayments, creditHistoryMonths, employmentMonths, incomeVerification, bankAccountStanding, debtToIncomeRatio, and outstandingLoans feed the three scoring tables.
Sample requestJSON
{
"applicant": {
"creditScore": 710,
"latePayments": 1,
"creditHistoryMonths": 48,
"employmentMonths": 36,
"incomeVerification": "complete",
"bankAccountStanding": "good",
"debtToIncomeRatio": 0.35,
"outstandingLoans": 2
}
}Score Credit History
tableCredit strength earns up to 30 points when all three columns line up: a creditScore above 750 with fewer than 2 latePayments and more than 60 months of history takes the top row, the [650..750] band with under 4 late payments and over 36 months scores 20, [600..650) scores 10, and the blank fallback row scores 0. First hit ordering means an applicant has to clear every column in a row to collect its points.
The bands roughly track familiar consumer credit tiers, with 750 marking prime territory and 650 the near-prime boundary, so the breakpoints read naturally to underwriters even though the point values are template choices. Requiring history length alongside the score matters because a thin file can show a high number with little evidence behind it, and credit-based insurance scoring genuinely relies on these same ingredients where it is permitted.
| creditScoreapplicant.creditScore | latePaymentsapplicant.latePayments | creditHistoryLengthapplicant.creditHistoryMonths | creditHistoryScorescores.creditHistory |
|---|---|---|---|
| > 750 | < 2 | > 60 | 30 |
| [650..750] | < 4 | > 36 | 20 |
| [600..650) | < 6 | > 24 | 10 |
| - | - | - | 0 |
Score Income Stability
tableStability points demand agreement across three columns: more than 60 employmentMonths with 'complete' incomeVerification and 'good' bankAccountStanding scores 25, the same qualitative pair over 24 months scores 20, 'partial' verification with 'fair' standing past 12 months scores 15, any tenure over 6 months salvages 5 points regardless of the other columns, and the fallback gives 0.
Employment tenure is the classic proxy for income continuity, and letting documented income outrank stated income mirrors the verification tiers lenders and underwriters actually use. The 6, 12, 24, and 60 month breakpoints are sensible template values rather than fixed industry standards, chosen so each step upgrades both duration and documentation together.
| employmentLengthapplicant.employmentMonths | incomeVerificationapplicant.incomeVerification | bankAccountStandingapplicant.bankAccountStanding | incomeStabilityScorescores.incomeStability |
|---|---|---|---|
| > 60 | 'complete' | 'good' | 25 |
| > 24 | 'complete' | 'good' | 20 |
| > 12 | 'partial' | 'fair' | 15 |
| > 6 | - | - | 5 |
| - | - | - | 0 |
Score Debt To Income
tableDebt burden is scored from applicant.debtToIncomeRatio paired with outstandingLoans: under 0.2 with fewer than 2 loans earns 25 points, under 0.4 with fewer than 3 earns 15, under 0.6 with fewer than 5 earns 5, and the empty row gives 0. Because matching is first hit, a low ratio with many loans slides down to whichever row it fully satisfies.
These breakpoints echo lending practice, where ratios around a third of income are treated as comfortable and anything approaching half as stretched, so rewarding sub-0.2 borrowers most is realistic. Counting loans separately catches applicants who keep the ratio low across many small obligations, a pattern that still signals payment complexity.
| debtToIncomeRatioapplicant.debtToIncomeRatio | outstandingLoansapplicant.outstandingLoans | debtToIncomeScorescores.debtToIncome |
|---|---|---|
| < 0.2 | < 2 | 25 |
| < 0.4 | < 3 | 15 |
| < 0.6 | < 5 | 5 |
| - | - | 0 |
Calculate Risk Score
expressionComponent sums come together as totalRiskScore, the sum of scores.creditHistory, scores.incomeStability, and scores.debtToIncome, for a maximum of 80. The negativeFactors filter collects every component that scored 0 and negativeFactorsCount measures how many, so the classifier can tell a mediocre-everywhere applicant apart from one with a single failed dimension.
scores.creditHistory + scores.incomeStability + scores.debtToIncomefilter([scores.creditHistory == 0, scores.incomeStability == 0, scores.debtToIncome == 0], # == true)len($.negativeFactors)Classify Risk
switchRouting runs on two signals at once: totalRiskScore >= 60 and negativeFactorsCount == 0 takes the low-risk branch, totalRiskScore >= 30 or (totalRiskScore >= 20 and negativeFactorsCount < 2) goes to medium, and the default statement sweeps the rest into high risk. Making the top tier require zero failed components keeps a file with one blank dimension out of auto-approval no matter how strong the rest of it is.
Low Risk Action Medium Risk Action High Risk ActionLow Risk Action
expressionFiles that reach this branch get riskCategory 'low', approvalStatus 'auto-approved', and an interestRateModifier of -0.5, a small pricing credit. Auto-approving only the cleanest tier is the straight-through processing pattern that keeps underwriters off routine applications.
'low''auto-approved'-0.5Medium Risk Action
expressionThe middle branch sets approvalStatus to 'manual-review' with a neutral interestRateModifier of 0, so pricing stays standard while a person decides. Holding the modifier flat until an underwriter has looked is a conservative default for borderline scores.
'medium''manual-review'0High Risk Action
expressionAnything falling through the default statement lands here: riskCategory 'high', approvalStatus 'additional-verification', and a 1.5 point interestRateModifier. Requesting more documentation instead of declining outright preserves the sale, while the surcharge prices the extra uncertainty in the meantime.
'high''additional-verification'1.5Other Insurance templates
View all templatesPolicy Eligibility Analyzer
Automated rule-based system that evaluates customer eligibility for insurance policies based on age, location, and specific risk factors.
InsuranceAuto Insurance Premium Calculator
Dynamic pricing system that determines accurate premiums based on driver profile, vehicle specifications, and coverage options for personalized insurance rates.
InsuranceInsurance Claim Validation System
Automated verification that validates insurance claims against policy status, timeframe requirements, and claim details before investigation.
Make this template
your own.
Load Applicant Risk Assessment into GoRules, adjust the rules to your policy, and ship it behind your own API.