Skip to content
by Rakesh Waghela

6.6 Sample rules library

A representative library of underwriting rules in the format the prompt requested. The 45 rules below cover the eligibility, bureau, GST, bank-statement, cash-flow, Tally, fraud, exposure, pricing, tenure, deviation, and repeat-borrower dimensions. The platform’s actual production rule library will be 150 – 500 rules across products, segments, channels, and partners; this is a representative working sample.

The platform stores these as versioned, configurable rules in the decision engine — see 3.E Underwriting engine and 5.5 Workflow and rules engines for runtime detail.

Eligibility — entity

Section titled “Eligibility — entity”

Rule 01 — GSTIN_ACTIVE_REQUIRED

Section titled “Rule 01 — GSTIN_ACTIVE_REQUIRED”
  • Purpose: Borrower’s GSTIN must be active at application; suspended / cancelled GSTINs are decline-worthy.
  • Data source: GSTIN verification API (Karza / Signzy / GSP).
  • Logic: gstin_status == 'Active'.
  • Threshold: hard.
  • Action: fail → DECLINE (reason code GST_CANCELLED).
  • Manual review: none.
  • Audit evidence: GST verification response with timestamp.

Rule 02 — BUSINESS_VINTAGE_MIN_24_MONTHS

Section titled “Rule 02 — BUSINESS_VINTAGE_MIN_24_MONTHS”
  • Purpose: Filter borrowers with insufficient operating history.
  • Data source: GST registration date + MCA incorporation date + Udyam date; earliest reliable.
  • Logic: months_between(business_start, today) >= 24.
  • Threshold: hard for A/B grades; 12 – 24 REFER for C-grade products.
  • Action: per grade.
  • Manual review: short-vintage with A-grade signals; REFER toward acceptance.
  • Audit evidence: registration dates with sources.

Rule 03 — INDUSTRY_NOT_RESTRICTED

Section titled “Rule 03 — INDUSTRY_NOT_RESTRICTED”
  • Purpose: Avoid sectors on the board-approved negative list (gambling, certain real-estate, specific NIC codes).
  • Data source: Borrower’s primary NIC code from GST / Udyam.
  • Logic: nic_code not in NEGATIVE_LIST.
  • Threshold: hard.
  • Action: fail → DECLINE.
  • Manual review: none.
  • Audit evidence: NIC code + negative-list version.

Rule 04 — GEOGRAPHY_SERVICEABLE

Section titled “Rule 04 — GEOGRAPHY_SERVICEABLE”
  • Purpose: Lend only in board-approved geographies.
  • Data source: Borrower’s principal-place-of-business state and city.
  • Logic: borrower_state in SERVICEABLE_STATES.
  • Threshold: hard.
  • Action: fail → DECLINE.
  • Manual review: edge geographies; REFER.
  • Audit evidence: borrower address.

Rule 05 — MCA_COMPANY_STATUS_ACTIVE

Section titled “Rule 05 — MCA_COMPANY_STATUS_ACTIVE”
  • Purpose: Borrower entity must not be Struck-Off, Under-Process, or in Liquidation.
  • Data source: MCA via Karza / Probe42.
  • Logic: mca_status == 'Active'.
  • Threshold: hard.
  • Action: fail → DECLINE.
  • Manual review: none.
  • Audit evidence: MCA snapshot.

Rule 06 — UDYAM_REGISTRATION_PRESENT

Section titled “Rule 06 — UDYAM_REGISTRATION_PRESENT”
  • Purpose: For PSL co-lending pools, Udyam is mandatory.
  • Data source: Udyam portal.
  • Logic: Udyam registration active.
  • Threshold: soft for own-book; hard for PSL co-lending pools.
  • Action: per product/pool.
  • Manual review: registration in process; REFER with timeline.
  • Audit evidence: Udyam URN.

Eligibility — promoter

Section titled “Eligibility — promoter”

Rule 07 — PAN_ACTIVE_PROMOTER

Section titled “Rule 07 — PAN_ACTIVE_PROMOTER”
  • Purpose: PAN must be valid.
  • Data source: NSDL PAN verification.
  • Logic: PAN valid and active.
  • Threshold: hard.
  • Action: fail → DECLINE.
  • Manual review: none.
  • Audit evidence: NSDL response.

Rule 08 — AGE_PROMOTER_BETWEEN_21_70

Section titled “Rule 08 — AGE_PROMOTER_BETWEEN_21_70”
  • Purpose: Standard lending-age window.
  • Data source: Aadhaar / PAN DoB.
  • Logic: age between 21 and 70.
  • Threshold: hard.
  • Action: fail → DECLINE.
  • Manual review: edge cases for older promoter with active business; REFER.
  • Audit evidence: DoB.

Rule 09 — AADHAAR_VERIFIED

Section titled “Rule 09 — AADHAAR_VERIFIED”
  • Purpose: KYC complete.
  • Data source: Offline XML or V-CIP.
  • Logic: Aadhaar verification status = success.
  • Threshold: hard.
  • Action: fail → block sanction (allow earlier stages).
  • Manual review: V-CIP rescheduled; in-progress.
  • Audit evidence: KYC record.

Rule 10 — SANCTIONS_PEP_CLEAN

Section titled “Rule 10 — SANCTIONS_PEP_CLEAN”
  • Purpose: AML compliance.
  • Data source: Sanctions / PEP / adverse media vendor.
  • Logic: No high-confidence hit.
  • Threshold: hard on confirmed hit.
  • Action: confirmed hit → DECLINE; partial hit → REFER for disposition.
  • Manual review: false positive disposition.
  • Audit evidence: screening response.

Rule 11 — BO_VERIFICATION_COMPLETE

Section titled “Rule 11 — BO_VERIFICATION_COMPLETE”
  • Purpose: PMLA — beneficial owner mapped and KYC’d.
  • Data source: BO graph completion status.
  • Logic: Every BO at >= 25% mapped and KYC’d.
  • Threshold: hard at sanction (allow application progress).
  • Action: block sanction.
  • Manual review: BO traced but document pending; REFER.
  • Audit evidence: BO graph.

Bureau

Section titled “Bureau”

Rule 12 — BUREAU_SCORE_MIN_650_PROMOTER

Section titled “Rule 12 — BUREAU_SCORE_MIN_650_PROMOTER”
  • Purpose: Floor on bureau score.
  • Data source: Consumer bureau (CIBIL primary).
  • Logic: bureau_score >= 650 (worst-of promoters).
  • Threshold: hard.
  • Action: fail → DECLINE; cure: re-apply after 6 months.
  • Manual review: none below floor.
  • Audit evidence: bureau pull.

Rule 13 — BUREAU_NO_WRITEOFF_LAST_36_MONTHS

Section titled “Rule 13 — BUREAU_NO_WRITEOFF_LAST_36_MONTHS”
  • Purpose: Writeoff is a strong default predictor.
  • Data source: Consumer + commercial bureau.
  • Logic: No WRITTEN_OFF or SETTLED_LESS_THAN_FULL within 36 months.
  • Threshold: hard.
  • Action: fail < 24 months → DECLINE; 24 – 36 → REFER.
  • Manual review: settled > 36 with strong recent performance; REFER toward accept.
  • Audit evidence: bureau detail.

Rule 14 — BUREAU_NO_90PLUS_DPD_LAST_24_MONTHS

Section titled “Rule 14 — BUREAU_NO_90PLUS_DPD_LAST_24_MONTHS”
  • Purpose: Recent severe delinquency.
  • Data source: Bureau.
  • Logic: No 90+ DPD on any lending product in last 24 months.
  • Threshold: hard.
  • Action: fail → DECLINE.
  • Manual review: cured 30 – 60 DPD only; REFER.
  • Audit evidence: bureau detail.

Rule 15 — BUREAU_NO_WILFUL_DEFAULTER_FLAG

Section titled “Rule 15 — BUREAU_NO_WILFUL_DEFAULTER_FLAG”
  • Purpose: Regulatory exclusion.
  • Data source: Bureau wilful-defaulter list.
  • Logic: No flag.
  • Threshold: hard.
  • Action: fail → DECLINE.
  • Manual review: none.
  • Audit evidence: bureau detail.

Rule 16 — BUREAU_RECENT_ENQUIRIES_LE_5_LAST_6_MONTHS

Section titled “Rule 16 — BUREAU_RECENT_ENQUIRIES_LE_5_LAST_6_MONTHS”
  • Purpose: Rate-shopping / multi-application stress signal.
  • Data source: Bureau.
  • Logic: count of enquiries in last 6 months <= 5.
  • Threshold: per grade — <= 3 A; <= 5 B; > 5 REFER.
  • Action: per.
  • Manual review: enquiries all from one channel (genuine shopping); REFER toward accept.
  • Audit evidence: bureau detail.

Rule 17 — EXISTING_FOIR_LE_50_PCT

Section titled “Rule 17 — EXISTING_FOIR_LE_50_PCT”
  • Purpose: Limit total obligations against income.
  • Data source: Bureau-detected EMIs + BSA-detected NACH; estimated income from GST + bank.
  • Logic: sum(existing_EMI) / monthly_estimated_income <= 0.50.
  • Threshold: <= 0.45 A; <= 0.50 B/C; > 0.50 fail.
  • Action: per grade or REFER; > 0.60 DECLINE.
  • Manual review: borrower has cleared an EMI being repaid; REFER.
  • Audit evidence: EMI list + income computation.

Rule 18 — COMMERCIAL_BUREAU_NO_CURRENT_NPA

Section titled “Rule 18 — COMMERCIAL_BUREAU_NO_CURRENT_NPA”
  • Purpose: Entity must not have any current NPA on commercial bureau.
  • Data source: Commercial bureau (CRIF Highmark MSME / CIBIL Commercial).
  • Logic: No current Sub-standard / Doubtful / Loss classification.
  • Threshold: hard.
  • Action: fail → DECLINE.
  • Manual review: none.
  • Audit evidence: commercial bureau.

Rule 19 — COMMERCIAL_BUREAU_EXPOSURE_RATIO

Section titled “Rule 19 — COMMERCIAL_BUREAU_EXPOSURE_RATIO”
  • Purpose: Existing commercial debt vs annual turnover.
  • Data source: Commercial bureau + GST.
  • Logic: existing_commercial_exposure / annual_turnover <= 0.60 for unsecured WC.
  • Threshold: per grade.
  • Action: per.
  • Manual review: high-quality existing facilities (term loans with collateral); REFER.
  • Audit evidence: bureau + GST.

GST

Section titled “GST”

Rule 20 — GST_TURNOVER_MIN_20L_ANNUAL

Section titled “Rule 20 — GST_TURNOVER_MIN_20L_ANNUAL”
  • Purpose: Minimum business size for the product.
  • Data source: GSTR-3B last 12 months.
  • Logic: sum(taxable_value_last_12_months) >= 2_000_000.
  • Threshold: hard for the product.
  • Action: fail → DECLINE.
  • Manual review: below but strong anchor signal; REFER.
  • Audit evidence: GSTR-3B parsed.

Rule 21 — GST_TURNOVER_GROWTH_NOT_DECLINING

Section titled “Rule 21 — GST_TURNOVER_GROWTH_NOT_DECLINING”
  • Purpose: Declining revenue signals distress.
  • Data source: GSTR-3B last 24 months.
  • Logic: turnover_last_12 / turnover_prior_12 >= 0.80.
  • Threshold: >= 1.0 A; >= 0.90 B; >= 0.80 C; < 0.80 REFER; < 0.65 DECLINE.
  • Action: per.
  • Manual review: known seasonality / Covid-recovery; REFER.
  • Audit evidence: GST trend.

Rule 22 — GST_3B_FILED_LAST_18_OF_24

Section titled “Rule 22 — GST_3B_FILED_LAST_18_OF_24”
  • Purpose: Filing consistency.
  • Data source: GST.
  • Logic: count of filed-on-time >= 18 in last 24.
  • Threshold: >= 22 A; >= 20 B; >= 18 C; < 18 fail.
  • Action: per or DECLINE.
  • Manual review: filing improving; REFER.
  • Audit evidence: GST filing log.

Rule 23 — GST_NO_SUSPENSION_LAST_12_MONTHS

Section titled “Rule 23 — GST_NO_SUSPENSION_LAST_12_MONTHS”
  • Purpose: GSTIN suspension is a red flag.
  • Data source: GST status history.
  • Logic: No suspension/cancellation in last 12 months.
  • Threshold: hard.
  • Action: fail → DECLINE.
  • Manual review: none.
  • Audit evidence: GST status history.

Rule 24 — GST_TOP_BUYER_LE_60_PCT

Section titled “Rule 24 — GST_TOP_BUYER_LE_60_PCT”
  • Purpose: Customer concentration.
  • Data source: GSTR-1.
  • Logic: top_buyer_sales / annual_sales <= 0.60.
  • Threshold: per grade and per segment overlay.
  • Action: per or REFER.
  • Manual review: top buyer is large stable corporate; REFER toward accept.
  • Audit evidence: GSTR-1 buyer aggregation.

Bank statement

Section titled “Bank statement”

Rule 25 — BANK_ABB_MIN_20K

Section titled “Rule 25 — BANK_ABB_MIN_20K”
  • Purpose: Minimum balance discipline.
  • Data source: BSA — last 6 months ABB on primary account.
  • Logic: abb >= 20_000.
  • Threshold: per grade table.
  • Action: per grade.
  • Manual review: high turnover, low balance (fast-turn); REFER.
  • Audit evidence: BSA output.

Rule 26 — BANK_NO_NEGATIVE_BALANCE_GT_5_DAYS_LAST_6M

Section titled “Rule 26 — BANK_NO_NEGATIVE_BALANCE_GT_5_DAYS_LAST_6M”
  • Purpose: Avoid chronic OD-rolling borrowers.
  • Data source: BSA daily EOD balance.
  • Logic: count of negative-balance days <= 5.
  • Threshold: <= 3 A; <= 5 B; <= 10 C; > 10 fail.
  • Action: per or DECLINE.
  • Manual review: legitimate OD limit with bank; REFER.
  • Audit evidence: BSA detail.

Rule 27 — BSA_NACH_BOUNCES_LE_2_LAST_12_MONTHS

Section titled “Rule 27 — BSA_NACH_BOUNCES_LE_2_LAST_12_MONTHS”
  • Purpose: Bounce history predicts future.
  • Data source: BSA-detected NACH bounce events.
  • Logic: count(nach_bounces_last_12_months) <= 2.
  • Threshold: per grade; > 6 DECLINE.
  • Action: per.
  • Manual review: recent bounce explained; REFER.
  • Audit evidence: BSA bounce log.

Rule 28 — BSA_CASH_DEPOSIT_RATIO_LE_20_PCT

Section titled “Rule 28 — BSA_CASH_DEPOSIT_RATIO_LE_20_PCT”
  • Purpose: Cash-heavy borrowers harder to verify; potentially under-reported.
  • Data source: BSA cash-deposit categorisation.
  • Logic: cash_deposits / total_credits <= 0.20.
  • Threshold: per grade.
  • Action: per or REFER.
  • Manual review: known cash-heavy industry (retail, jewellery); REFER.
  • Audit evidence: BSA.

Rule 29 — BSA_NO_CIRCULAR_TRANSACTIONS

Section titled “Rule 29 — BSA_NO_CIRCULAR_TRANSACTIONS”
  • Purpose: Circular flows suggest related-party arrangements masking real cash-flow.
  • Data source: BSA pattern detection.
  • Logic: No material (> 10% of monthly volume) circular pattern.
  • Threshold: REFER on detection.
  • Action: per.
  • Manual review: explain pattern.
  • Audit evidence: BSA pattern detection log.

Cash-flow

Section titled “Cash-flow”

Rule 30 — CASH_FLOW_DSC_MIN_1_5X

Section titled “Rule 30 — CASH_FLOW_DSC_MIN_1_5X”
  • Purpose: Loan EMI / interest must be servicable from operating cash flow.
  • Data source: BSA + GST cash-flow analysis; proposed EMI / interest.
  • Logic: avg(monthly_available_cf_last_12_months) / proposed_monthly_service >= 1.5.
  • Threshold: >= 2.5 A; >= 2.0 B; >= 1.5 C; < 1.5 REFER; < 1.0 DECLINE.
  • Action: per.
  • Manual review: stable but tight DSC; REFER.
  • Audit evidence: cash-flow workings.

Rule 31 — GST_BANK_RECON_DIVERGENCE_LE_15_PCT

Section titled “Rule 31 — GST_BANK_RECON_DIVERGENCE_LE_15_PCT”
  • Purpose: Reconciliation health.
  • Data source: GSTR-1 + BSA monthly credit (operating only).
  • Logic: abs(gst_sales - bank_credit) / gst_sales <= 0.15 over rolling 12 months.
  • Threshold: per grade and per segment overlay.
  • Action: per or REFER.
  • Manual review: high-cash legitimate business; REFER.
  • Audit evidence: GST + BSA.

Rule 32 — WORKING_CAPITAL_CYCLE_LE_120_DAYS

Section titled “Rule 32 — WORKING_CAPITAL_CYCLE_LE_120_DAYS”
  • Purpose: Excessive cycle stresses cash flow.
  • Data source: GST + BSA + Tally where available.
  • Logic: cash_conversion_cycle <= 120 days for general WC.
  • Threshold: per segment overlay.
  • Action: per or REFER.
  • Manual review: high-cycle industry; REFER with appropriate ticket size.
  • Audit evidence: cycle computation.

Tally / accounting

Section titled “Tally / accounting”

Rule 33 — TALLY_REVENUE_MATCHES_GST_WITHIN_15_PCT

Section titled “Rule 33 — TALLY_REVENUE_MATCHES_GST_WITHIN_15_PCT”
  • Purpose: Borrower’s accounting must reconcile with their GST.
  • Data source: Tally P&L + GST.
  • Logic: abs(tally_revenue - gst_revenue) / gst_revenue <= 0.15.
  • Threshold: hard at 15%; > 25% REFER toward decline.
  • Action: per.
  • Manual review: legitimate divergence (timing differences); REFER.
  • Audit evidence: Tally + GST.

Rule 34 — TALLY_RECEIVABLE_AGEING_OVER_90_LE_20_PCT

Section titled “Rule 34 — TALLY_RECEIVABLE_AGEING_OVER_90_LE_20_PCT”
  • Purpose: Heavy aged receivables = collection issues = liquidity stress.
  • Data source: Tally receivable ageing.
  • Logic: receivables_over_90_days / total_receivables <= 0.20.
  • Threshold: per segment overlay.
  • Action: per.
  • Manual review: known specific disputed receivable; REFER with disclosure.
  • Audit evidence: Tally ageing.

Rule 35 — TALLY_NET_PROFIT_POSITIVE_LAST_FY

Section titled “Rule 35 — TALLY_NET_PROFIT_POSITIVE_LAST_FY”
  • Purpose: Loss-making businesses have heightened risk.
  • Data source: Tally P&L.
  • Logic: Net profit >= 0 in last full financial year.
  • Threshold: A-grade if positive; loss REFER; major loss (> 10% of revenue) DECLINE unless explained.
  • Action: per.
  • Manual review: one-off loss event explained; REFER.
  • Audit evidence: Tally P&L.

Fraud

Section titled “Fraud”

Rule 36 — FRAUD_INTERNAL_BLACKLIST

Section titled “Rule 36 — FRAUD_INTERNAL_BLACKLIST”
  • Purpose: Block known bad actors.
  • Data source: Internal blacklist (PAN, mobile, device, bank account, BO, address).
  • Logic: any match.
  • Threshold: hard.
  • Action: fail → DECLINE; alert risk.
  • Manual review: none.
  • Audit evidence: blacklist entry.

Rule 37 — FRAUD_DEVICE_MULTI_PAN_30_DAYS

Section titled “Rule 37 — FRAUD_DEVICE_MULTI_PAN_30_DAYS”
  • Purpose: Device fingerprint signals fraud.
  • Data source: Device intel vendor.
  • Logic: Same device used for > 3 distinct PANs in 30 days.
  • Threshold: > 3 DECLINE; 2 – 3 REFER.
  • Action: per.
  • Manual review: legitimate family / shared business device; REFER.
  • Audit evidence: device fingerprint log.

Rule 38 — FRAUD_BSA_TAMPERING_FLAG

Section titled “Rule 38 — FRAUD_BSA_TAMPERING_FLAG”
  • Purpose: Manipulated bank statements indicate fraud.
  • Data source: BSA vendor tampering signal.
  • Logic: Vendor flag = confirmed.
  • Threshold: confirmed → DECLINE; suspicion → REFER with re-pull via AA.
  • Action: per.
  • Manual review: re-pull clean; REFER.
  • Audit evidence: vendor tampering response.

Rule 39 — FRAUD_PAN_AADHAAR_NAME_MISMATCH

Section titled “Rule 39 — FRAUD_PAN_AADHAAR_NAME_MISMATCH”
  • Purpose: Identity-fraud signal.
  • Data source: PAN + Aadhaar verification responses.
  • Logic: Name fuzzy-match score below threshold.
  • Threshold: similarity < 0.70 → REFER; < 0.50 DECLINE.
  • Action: per.
  • Manual review: name change (marriage); REFER with evidence.
  • Audit evidence: name match score.

Exposure

Section titled “Exposure”

Rule 40 — SINGLE_BORROWER_EXPOSURE_LE_25_PCT_TIER1

Section titled “Rule 40 — SINGLE_BORROWER_EXPOSURE_LE_25_PCT_TIER1”
  • Purpose: Enforce RBI single-borrower cap for NBFC-BL.
  • Data source: Internal exposure ledger.
  • Logic: (current_outstanding + proposed_sanction) / tier1_capital <= 0.25.
  • Threshold: hard.
  • Action: fail → DECLINE; cannot be deviated.
  • Manual review: none.
  • Audit evidence: exposure calculation.

Rule 41 — GROUP_BORROWER_EXPOSURE_LE_40_PCT_TIER1

Section titled “Rule 41 — GROUP_BORROWER_EXPOSURE_LE_40_PCT_TIER1”
  • Purpose: Group exposure cap.
  • Data source: Internal exposure ledger; BO-graph linkage.
  • Logic: sum(group_exposure) / tier1_capital <= 0.40.
  • Threshold: hard.
  • Action: fail → DECLINE.
  • Manual review: none.
  • Audit evidence: group mapping + exposure.

Rule 42 — SECTOR_EXPOSURE_LE_BOARD_APPROVED_CAP

Section titled “Rule 42 — SECTOR_EXPOSURE_LE_BOARD_APPROVED_CAP”
  • Purpose: Sectoral concentration risk.
  • Data source: Internal portfolio composition.
  • Logic: sector_outstanding / total_book <= board_cap for borrower’s sector.
  • Threshold: per board policy.
  • Action: fail → DECLINE for this loan (board cap reached for the sector).
  • Manual review: borderline; REFER.
  • Audit evidence: sectoral composition.

Pricing and tenure

Section titled “Pricing and tenure”

Rule 43 — PRICING_GRID_BY_GRADE_AND_PRODUCT

Section titled “Rule 43 — PRICING_GRID_BY_GRADE_AND_PRODUCT”
  • Purpose: Standardised pricing per risk grade + product + tenure + channel.
  • Data source: Pricing grid + risk grade.
  • Logic: rate = pricing_grid[grade][product][tenure_band] + channel_adjustment + repeat_adjustment.
  • Threshold: derived.
  • Action: set rate.
  • Manual review: off-grid pricing requires deviation approval.
  • Audit evidence: pricing grid version + derivation.

Rule 44 — TENURE_GRID_BY_GRADE

Section titled “Rule 44 — TENURE_GRID_BY_GRADE”
  • Purpose: Cap tenure by grade.
  • Data source: Tenure grid + risk grade.
  • Logic: requested_tenure <= tenure_grid[grade].
  • Threshold: hard within product norms.
  • Action: cap or fail.
  • Manual review: business-case-based extension; REFER.
  • Audit evidence: tenure grid + grade.

Repeat borrower

Section titled “Repeat borrower”

Rule 45 — REPEAT_BORROWER_PRIOR_PERFORMANCE_CLEAN

Section titled “Rule 45 — REPEAT_BORROWER_PRIOR_PERFORMANCE_CLEAN”
  • Purpose: Repeat borrowers with clean prior performance get accelerated treatment.
  • Data source: Internal LMS history.
  • Logic: Prior loan paid on time (<= 30 DPD ever) and closed satisfactorily.
  • Threshold: pass.
  • Action: enables fast-track flow + better pricing.
  • Manual review: minor DPD events; case-by-case.
  • Audit evidence: LMS history.

Rule design notes

Section titled “Rule design notes”
  • Every rule’s action outcome must be explicit (APPROVE, DECLINE, REFER, CAP_TO_X, PRICE_ADJUST_BY_Y, etc.).
  • Every rule’s threshold must be configurable in admin, not hard-coded.
  • Every rule’s evaluation must produce a trace artefact captured in the decision_run record for audit.
  • Rule versions are immutable; changes spawn new versions; in-flight applications use the policy version recorded at application start.
  • Champion-challenger can be applied to compare rule-version performance against historical / parallel cohorts.

Segment-specific overlays

Section titled “Segment-specific overlays”

In addition to these base rules, segment-specific overlays add or adjust thresholds — see the segment-overlay pages:

The 45 rules above are the base scaffold; production engines layer segment overlays + co-lending-partner overlays + per-product variants on top, reaching the 150 – 500 rule range typical of mature lending platforms.