Draft
Maker proposes changeA loan-product or scoring-policy edit enters the draft state. The originating user is recorded as the maker.
Trust & governance
Designed to reduce regulatory anxiety.
DurujScore keeps lender judgment, consent records, policy versioning, reason codes and audit evidence visible — without positioning the platform as the final decision-maker.
Governed controls
How decisions stay reviewable
CR
Consent recordsEvery access request is purpose-bound, time-bound and auditable.
PV
Policy versioningEach score records which institutional policy version produced it.
RC
Reason codesBorrowers and lenders see understandable drivers, not a black-box number.
FL
Fair lendingProtected-attribute rules require documented justification and compliance approval.
AT
Audit trailWho accessed what, and why, is retained for every decision.
RP
ReproducibilityA logged decision can be replayed with the exact inputs and logic used at the time.
Audit trail
What gets logged on every decision.
The audit log is append-only. Months later, a compliance officer can answer "what happened on this date for this borrower" without depending on memory or screenshots.
| Event | What's recorded |
|---|---|
| Score requested | Caller, role, timestamp, lender JWT, IP / API-key hash. |
| Inputs read | Identity rows, linked-account ids, transaction windows, consent ids in effect. |
| Score computed | Component sub-scores, weights source (tenant / country / default), policy version. |
| Decision Layer | PD%, risk level, recommended limit and tenor, decision, reasons[], fraud warning, review flag. |
| Explanation rendered | Narrative + model version (when AI-explained), frozen for replay. |
| Outcome ingested | Status, max days late, defaulted date, recovered amount, observed_at, ingestion source. |
| Policy change | Maker, checker, before/after diff, effective_from, products affected. |
Policy versioning + maker-checker
Every policy change is two-eyes-approved and snapshotted.
A credit officer drafts a change (the "maker"). A second, distinct user approves it (the "checker"). Self-approval is structurally blocked. On approval, a version snapshot is written; historical decisions reference the version that produced them, so the same inputs always replay to the same outputs.
Submit
Pending approvalMove to pending. The diff is visible to any approver in the organization. The original maker cannot self-approve.
Approve
Checker activatesA distinct approver moves it to active. A version snapshot is written. Old snapshots stay queryable so historical decisions remain reproducible.
Decision replay
Re-run a past decision with the exact inputs and logic used at the time.
Each generated score row pins itself to its inputs (identity snapshot, transaction window, consent ids in effect, fraud signals) and to the policy version that produced it. The score, decision, reasons and explanation narrative are frozen on write. Re-running the same inputs through the same policy returns the same output — investigators and regulators get a deterministic answer.
The AI-narrated explanation a loan officer saw at time T is the explanation logged at time T. There is no "force regenerate" — re-running requires explicit deletion, which is itself audited.
The Validation report compares predicted PD vs observed default rate by score band on the same labelled cohort. Miscalibration shows up as a measurable gap, not a vibe.
Fair-lending controls
Protected attributes cannot quietly drive a decision.
Rules referencing gender, religion, ethnicity or disability cannot be saved without a documented justification and compliance approval. The platform enforces this at the product-rule layer; reviewers see a fairness gate before a policy goes live.
Saving a rule that references gender / religion / ethnicity / disability returns a 422 unless a written justification is attached and a compliance approver signs off.
Primary risk scoring uses tree models (XGBoost / LightGBM / CatBoost) with SHAP reason codes. Black-box outputs are not deployable on a regulated product.
The platform produces a recommendation. The lender’s credit committee remains the authoritative decider; the audit log records who said yes and why.
The Claude-narrated explanation is post-hoc only. The score itself is computed deterministically by the rule + tree-model layer; the LLM has no input into the number.
Regulatory alignment
Built to satisfy Ethiopian and adjacent regulators.
See the legal page for the article-by-article reference; the headlines:
NBEAligned with National Bank of Ethiopia credit-reporting expectations.ETCompatible with Ethiopian Data Protection Proclamation 1321/2024.GDPRGDPR-aligned consent + data-subject rights for diaspora and EU residents.AMLFraud and watchlist signals; identity-confidence thresholds for high-risk segments.
Make every decision reviewable.
See the consent, versioning, reason-code and audit controls in a live walkthrough — on your portfolio.