← Back to DurujScore
How it works

From application to decision in one auditable trace.

Borrower consents. Signals get pulled. Score gets computed. Decision Layer derives a recommendation. Audit row gets written. Outcome feeds back. Every step is reproducible.

The layers

Four layers, one explainable result

DT
Data layer

Consented identity, bank, mobile-money, MFI/SACCO and behavioural signals.

FT
Feature layer

Signals normalised into cashflow regularity, repayment discipline, capacity and risk features.

MD
Model layer

Deterministic, explainable tree models produce a 300–850 score with SHAP-style reason codes.

DC
Decision layer

Score, band, factors and a recommendation are returned — the credit committee decides.

CA
Consent & audit

Every access is purpose-bound and logged; each score records the policy and model version used.

RP
Reproducible

A decision made today can be replayed tomorrow with the exact inputs and logic.

The path of a decision
  1. 1Consent & collectThe borrower grants time-bound, purpose-bound consent; verified signals flow in through your channels.
  2. 2Score & explainThe engine computes the composite score, sub-scores, factors and reason codes — deterministically.
  3. 3Decide & recordYour team reviews the recommendation and decides; the score, reasons and audit row are stored.
The trace

From consent to score to outcome — one auditable trace.

Every step writes an audit row. Months later, a compliance officer can answer "what happened on this date for this borrower" without depending on memory or screenshots.

  1. 1Borrower consentsThe borrower grants the lender access to their Duruj Passport — purpose-bound, time-bound, revocable in one tap.
  2. 2Lender requests a scorePOST /credit-scores/calculate with the person_id. Tenant isolation is enforced from the JWT.
  3. 3Signals are pulledIdentity (Fayda / Wardya), linked accounts (bank, mobile money, MFI, SACCO), behavioral events with time decay, fraud signals, optional CreditChek bureau lookup, optional ML signal sidecar.
  4. 4Score is computedEach component lands on a 0–200 sub-range; weighted by the tenant policy; projected to 300–850; fraud penalty subtracted; clamped.
  5. 5Decision Layer derives recommendationPD%, risk level, recommended limit (tied to cashflow), recommended tenor, decision (Approve / Review / Reject), reasons[], fraud and human-review flags.
  6. 6Optional AI narrationA loan officer can request a 2–3 sentence Claude-narrated explanation of why this score / why this decision. The LLM is never the scorer; narration is post-hoc and audit-frozen.
  7. 7Audit row writtengenerated_credit_scores row records the score, components, weights_source, explanation, decision fields, fraud/review flags. Every input is traceable for replay.
  8. 8Outcome feeds backWhen the loan resolves, the lender POSTs the outcome (paid_off / late / default / written_off). It joins back to the originating score and improves validation.
Audit

What is logged on every score.

EventRecorded
Score requestcaller_id, role, request_id, tenant, IP / API-key hash
Inputs readidentity rows, account ids, txn windows, consent ids in effect
Score computedcomponent sub-scores, weights_source, policy version
Decision LayerPD%, risk_level, recommended_limit, recommended_tenor, decision, reasons[]
Explanationnarrative (when AI-explained), model version, frozen for replay
Outcome ingestedstatus, max_days_late, defaulted_at, recovered_amount, observed_at

See the trace on your data.

Book a walkthrough and we'll trace a real decision end to end — signals, score, reasons and audit.