Maker proposes a change. Diff is visible only to the maker.
Lender-controlled credit policy. Versioned, audited, reviewable.
Configure component weights, decision thresholds, approval paths and the protected-attribute gate. Every change is two-eyes-approved and snapshotted; historical decisions reference the version that produced them.
Where your policy lives
Define rules for loan types, segments, sectors and risk appetite.
Choose which data sources and signals to include in scoring.
Set custom weights, score bands and thresholds per product.
Configure approvals, limit rules, overrides and referrals.
Two-eyes approval on every policy change; self-approval is blocked.
Protected-attribute rules require justification + compliance sign-off.
- 1Author the policySet weights, eligibility and limits; a maker-checker flow prevents self-approval.
- 2Version on every editEach change snapshots an append-only version so past decisions stay reproducible.
- 3Apply with auditEvery score records which policy version produced it, with a full audit row.
The knobs the credit team actually owns.
Every tenant has its own scoring policy. The country-level default is the fallback, but each lender overrides what matters for their portfolio. Nothing is hidden behind a sales call.
| Knob | Example | Why it exists |
|---|---|---|
| Component weights | { bank: 0.18, mobile_money: 0.22, behavioral: 0.10, ml_signal: 0.10 } | Match the signals your borrower segment actually has. |
| Score thresholds | Green ≥ 650 · Yellow 550–649 · Orange 450–549 · Red < 450 | Tune approve / review / reject bands to your risk appetite. |
| Fraud penalty cap | 0 to −50 points | How much fraud signal accumulation depresses the score. |
| Confidence floor | Require ≥ 0.7 for Approve | Keep thin-file profiles out of the auto-approve lane. |
| Approval routing | PD ≤ 0.05 → auto · 0.05–0.20 → committee · > 0.20 → reject | Send the right decisions to the right people. |
Two eyes on every change. Self-approval is structurally blocked.
Loan products and scoring policies move from draft → pending → active. The original maker cannot approve their own change; a distinct user with the approver role does. On approval, a version snapshot is written and historical decisions remain tied to the version that produced them.
Submitted for review. Any approver in the org can see the diff.
A distinct approver activates. Version snapshot written.
Fairness gate enforced at the rule layer.
Saving a rule that references gender, religion, ethnicity or disability returns a 422 unless the maker attaches a written justification and a compliance approver signs off. The gate lives in the API, not just the admin UI — partner integrations inherit the same protection.
Run your own credit policy.
See how lenders configure governed, explainable policy without writing code.