Mobile financial services, bank and MFI credit risk teams

Estimate who will repay, and let the lender decide

A wallet customer asks for a small loan before payday. The lender holds an approved, purpose-limited view of their operator and wallet history, and has to answer in seconds.

Request a working session The product that runs it: Mobile Money, Credit & Financial Services

No demonstration is configured for this journey yet.

Seen by the customer · USSD, Kiswahili

From the record, not a run: what would reach them, on USSD, App, Agent, in Kiswahili, English.

The case

Annotated from the record

What happened

A wallet customer asks for a small loan before payday, and the lender has an approved, purpose-limited view of their operator and wallet history.

A wallet customer asks for a small loan before payday. The lender holds an approved, purpose-limited view of their operator and wallet history, and has to answer in seconds.

What it reads

Consent and the approved, purpose-limited attributes
Wallet and operator history within the approved window
Affordability and existing obligations
The lender's policy and limits

Checks before anything is sent

Consent, purpose limitation, data approval, affordability and the lender's own policy checks pass.

Every option considered, including doing nothing

Approve at the recommended limitConsidered
Approve at a lower limit, with the reasonConsidered
Refer for a human decisionConsidered
No loan, with the reason codes shownConsidered

No action is a valid outcome, and it is recorded with its reason. Nothing is computed on this page: the options are the record's own, and no run has decided anything.

Evidence record

Preview

Reference: Issued when a run is saved. An evaluation that was never saved has none.
Decision: One of the options, including no action, with the reason.
Checks: Consent, purpose limitation, data approval, affordability and the lender's own policy checks pass.
Evidence kept: Consent
approved attributes
estimate
reason codes
limit recommendation
lender's decision
disbursement
repayment record
The measures: Repayment on time against the propensity estimated, and delinquency caught early.
Connection: Stated on every record. In the demonstration no operator system is connected, and each record carries that state.

The shape of the record, with no values. A reference appears only after a run is saved.

The improvement, and how it is measured

Hypothesis

A loan sized to repayment is repaid and renewed; one sized to the request is a collection.

Desired result: Incremental revenue or retention; lower contact waste; improved conversion with margin guardrails

Modelled not observed

No figure is modelled for this journey. The mechanism that could produce the result is stated instead.

Ingest → qualify → score → apply limits/consent → assign control → execute approved action → capture delivery and business outcome → monitor/retrain

Observed

Nothing yet. Measurement begins in a pilot’s validate stage, on your systems, against a comparison agreed first.

Randomised holdout where feasible; intent-to-treat primary view; pre-declared denominator; guardrails for complaints, margin and opt-out

Measured on: Eligible population; treatment rate; conversion; incremental revenue; ARPU; churn; contact rate; margin; opt-out; decision latency

Assumptions, costs and the record’s five answers

01
Desired result
The result wanted.
Incremental revenue or retention; lower contact waste; improved conversion with margin guardrails
02
Mechanism
The mechanism that could produce it.
Ingest → qualify → score → apply limits/consent → assign control → execute approved action → capture delivery and business outcome → monitor/retrain
03
Evidence required
The records kept to show it.
Decision log; eligibility snapshot; price/order response; delivery receipt; control assignment; revenue/outcome ledger
04
Costs and risks
The cost, and the ways it can go wrong.
Costs: Setup fee + annual product subscription; optional managed execution fee; optional verified-outcome fee with agreed baseline
If it fails: Fail closed on eligibility/consent/price; queue retryable events; do not duplicate orders; route exception to campaign operations
05
Measurement approach
The measure that shows it helped.
Randomised holdout where feasible; intent-to-treat primary view; pre-declared denominator; guardrails for complaints, margin and opt-out
Measured on: Eligible population; treatment rate; conversion; incremental revenue; ARPU; churn; contact rate; margin; opt-out; decision latency

Nothing has been observed for this product. Every line above is the record's own design intent; measurement begins in a pilot's validate stage, on your systems, with the comparison agreed first.

The business side

The change: Repayment on time against the propensity estimated, and delinquency caught early.
Running cost: Setup fee + annual product subscription; optional managed execution fee; optional verified-outcome fee with agreed baseline
What evidence supports it: Consent, approved attributes, estimate and reason codes, limit recommendation, lender's decision, disbursement and repayment record.

The journey in detail

Step by step, from both sides

Step	What the customer experiences	What the operator does
The momentThe moment that started it.	A wallet customer asks for a small loan before payday, and the lender has an approved, purpose-limited view of their operator and wallet history.	Reads consent and the approved, purpose-limited attributes, wallet and operator history within the approved window, affordability and existing obligations, the lender's policy and limits.
The decisionThe decision to be made.	Nothing reaches the customer yet.	Estimates the calibrated probability of repayment from the approved attributes, with reason codes, and recommends a limit; the lender decides.
The safeguardsThe conditions that stop it.	Still nothing. No action is sent until every check has passed.	Consent, purpose limitation, data approval, affordability and the lender's own policy checks pass.
The actionThe action that reaches the customer.	The lender's credit engine approves, limits or declines; the customer sees the decision and its reasons in their own language. Reaches them on USSD, App, Agent, in Kiswahili, English.	Recommends. The system that holds the right confirms, charges or provisions.
When it goes wrongRefusal, failure and recovery.	The estimate reads an attribute the purpose approval did not cover, and a decision is made on data the customer did not consent to.	The purpose-limitation check refuses the attribute before the estimate runs, the decision is made on the approved set, and the audit records which attribute was excluded and why.
The resultThe change it made.	What changed for them is what is counted; nothing else is claimed.	Repayment on time against the propensity estimated, and delinquency caught early.
The proofThe proof anyone can check.	Can be answered for, later, from the record.	Consent, approved attributes, estimate and reason codes, limit recommendation, lender's decision, disbursement and repayment record.

Operator systems remain authoritative. HeuriTel reads these to propose an action; it does not decide on their behalf.

Refusal, failure and recovery

What goes wrong

The estimate reads an attribute the purpose approval did not cover, and a decision is made on data the customer did not consent to.

What happens then

The purpose-limitation check refuses the attribute before the estimate runs, the decision is made on the approved set, and the audit records which attribute was excluded and why.

The products in this journey

Runs the decision
Mobile Money, Credit & Financial Services
Wallet growth, retention and reactivation are decided like any customer decision; credit eligibility, repayment propensity and a limit recommendation are estimated from approved, purpose-limited data with reason codes, and the lender or its credit engine decides.
Contributes
Fraud, Identity & Customer Protection
the identity and fraud checks a loan depends on
Contributes
Real-Time Revenue Moments
the emergency allowance that becomes credit when a regulated ledger decides
The definition it demonstratesHeuriTel Credit Repayment Propensity
Results it movesLaunch and monetise digital services · Reduce fraud and identity risk

Available to see today

No demonstration is configured for this journey yet.

Request a working session Request a working session