Grow the wallet and lend to the customer who will repay, with the lender keeping the decision.
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.
For Mobile financial services, bank and MFI credit risk, and collections teams.
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.
This applicant's probability of repaying, the limit it supports, and the lender's decision.
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
Before anything reaches the customer: Consent, purpose limitation, data approval, affordability and the lender's own policy checks pass.
What would reach them: The lender's credit engine approves, limits or declines; the customer sees the decision and its reasons in their own language. On USSD, App, Agent.
This applicant's probability of repaying, the limit it supports, and the lender's decision.
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.
Approve at the recommended limit
Approve at a lower limit, with the reason
Refer for a human decision
No loan, with the reason codes shown
What it does
Three things it helps you decide or do.
Decide the wallet action, including none
Growth, retention, personalisation and reactivation offers for the wallet are chosen from approved actions including no action, and a customer without consent or an ineligible product is not contacted.
Offer
service message
reward
channel change
human follow-up
suppress
do nothing
Estimate repayment from approved data, with reasons
A consenting applicant's calibrated probability of repayment is estimated from approved operator, wallet and lender attributes; eligibility, a limit recommendation, cross-sell and renewal carry reason codes.
customer_id
account_type
tenure_days
active_products
recharge_30d
usage_30d
revenue_30d
last_contact
consent_status
outcome_label
Watch the loan after it is made
Early delinquency detection, collections prioritisation and payment-promise prediction read the outcome ledger, so the portfolio is monitored against the decisions that built it.
Decision log
eligibility snapshot
price/order response
delivery receipt
control assignment
revenue/outcome ledger
The journey
Estimate who will repay, and let the lender decide
No demonstration is configured for this product yet.
Mobile financial services, bank and MFI credit risk teams
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.
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.
Consent, approved attributes, estimate and reason codes, limit recommendation, lender's decision, disbursement and repayment record.
Technical detail
Inputs, decision logic, systems touched, records kept.
Four questions an evaluation asks in a different order every time. Every field is the workbook’s own, unedited.
What would we need from your systems, and how much history?
Attributes required
customer_id
account_type
tenure_days
active_products
recharge_30d
usage_30d
revenue_30d
last_contact
consent_status
outcome_label
Also useful, not required
Network experience
digital clickstream
complaints
location cohort
household/account links
partner purchases
8-12 weeks of customer, usage, revenue, product, contact and outcome history; stable customer key; one executable channel
How is the action chosen, and what stops it?
Actions it may choose between
Offer
service message
reward
channel change
human follow-up
suppress
do nothing
Conditions that stop execution
No consent
ineligible product
price/catalogue mismatch
contact cap
credit/fraud block
channel unavailable
control assignment
Fail closed on eligibility/consent/price; queue retryable events; do not duplicate orders; route exception to campaign operations
What does it connect to, and what stays authoritative?
Your systems involved
CRM/CDP
campaign manager
product catalogue
OCS
order management
billing
consent registry
Interfaces
Customer/profile API
catalogue/eligibility API
campaign API
charging/order API
consent API
outcome event API
Channels
SMS
USSD
app
web
WhatsApp
outbound call
agent desktop
Charging, billing, catalogue, consent and order systems remain authoritative; HeuriTel decides only within approved policy.
What is kept, and how would a claim be tested?
Evidence required
Decision log
eligibility snapshot
price/order response
delivery receipt
control assignment
revenue/outcome ledger
The measures
Eligible population
treatment rate
conversion
incremental revenue
ARPU
churn
contact rate
margin
opt-out
decision latency
Privacy and regulation
Purpose limitation
consent and suppression
data minimisation
retention
explainability for material customer effects
local marketing rules
Randomised holdout where feasible; intent-to-treat primary view; pre-declared denominator; guardrails for complaints, margin and opt-out
The 28 definitions underneath
28 in this product
HeuriTel Mobile MoneyDecision definitionHT-0276
Identify eligible records for mobile money, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
/d/HT-0276
HeuriTel Wallet GrowthDecision definitionHT-0277
Identify eligible records for wallet growth, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
Identify eligible records for wallet retention, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
Identify eligible records for wallet personalisation, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
Identify eligible records for wallet reactivation, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
/d/HT-0280
HeuriTel Mobile LendingDecision definitionHT-0281
Support mobile lending with approved, purpose-limited data, documented policy, human/credit-engine authority, reason codes and outcome monitoring.
Estimate a consenting applicant's calibrated probability of repayment from approved operator, wallet and lender attributes; the lender remains the decision authority.
Support loan cross-sell with approved, purpose-limited data, documented policy, human/credit-engine authority, reason codes and outcome monitoring.
/d/HT-0285
HeuriTel Loan RenewalDecision definitionHT-0286
Support loan renewal with approved, purpose-limited data, documented policy, human/credit-engine authority, reason codes and outcome monitoring.
/d/HT-0286
HeuriTel Early Delinquency DetectionDecision definitionHT-0287
Support early delinquency detection with approved, purpose-limited data, documented policy, human/credit-engine authority, reason codes and outcome monitoring.
Support payment promise prediction with approved, purpose-limited data, documented policy, human/credit-engine authority, reason codes and outcome monitoring.
/d/HT-0289
HeuriTel InsuranceDecision definitionHT-0290
Identify eligible records for insurance, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
Identify eligible records for insurance propensity, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
Identify eligible records for merchant payments, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
/d/HT-0292
HeuriTel PaymentsDecision definitionHT-0293
Identify eligible records for payments, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
/d/HT-0293
HeuriTel RemittanceDecision definitionHT-0294
Identify eligible records for remittance, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
/d/HT-0294
HeuriTel SavingsDecision definitionHT-0295
Identify eligible records for savings, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
Identify eligible records for savings propensity, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
Identify eligible records for financial services personalisation, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
Identify eligible records for microfinance customer verification, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
Identify eligible records for microfinance portfolio monitoring, choose from approved actions including no action, execute through the system of record, and measure the agreed business outcome.
Four stages, and what has to be true before the next one starts.
12-16 weeks to pilot; 2-4 additional weeks per market after reusable interfaces exist. A team of 8 roles, named in the record rather than promised.
01
Scope
One use case, one value unit and a denominator finance has agreed to. Without these there is nothing a later result can be compared against.
Confirm value unit
select use case
baseline denominator
02
Connect
The attributes mapped from your systems, and the decision and outcome interfaces working in both directions.
map attributes
integrate decision and outcome APIs
03
Validate
Eligibility agreed, a dry run with nothing sent, then a controlled pilot with a holdout that is actually respected.
build eligibility
dry run
controlled pilot
04
Operate
The live loop: decide, check, execute through your systems, capture what came back, and measure against the control.
Ingest
qualify
score
apply limits/consent
assign control
execute approved action
capture delivery and business outcome
monitor/retrain
Who does it. 1 telecom product lead · 1 CVM specialist · 1 data engineer · 1 ML engineer · 1 integration developer · 0.5 QA · 0.5 DevSecOps · 1 deployment coordinator
Four states are tracked, and each is assessed against your systems.
Readiness is assessed per client: nothing is offered as pilot-ready until your data, your integration and your authority have been checked.
Readiness
Needs client data and integration review
The client’s data and integration position.Runtime / build state
Target product definition
What exists as running software.Surface state
Not audited
Whether this product shows the entry anywhere.Client status
Not assessed
Where a named client has reached.
Next steps from here.
28 definitions sit under Mobile Money, Credit & Financial Services. The two links that matter first are the journey this page describes, and the rest of the family it belongs to.
What can the network itself do for a bank, an agency or a planner?
CAMARA & GSMA Open Gateway APIsLet a bank or an app verify a number, a SIM change or a location from the network itself, with the customer's consent recorded.
Network Investment & IntelligencePut the next site, upgrade or fibre route where the customers and the revenue are, and show afterwards what the money did.
Government & Public SectorGive a public service the aggregate picture and the citizen contact it needs, without exposing a single subscriber's data.
Jobs & Social ImpactRun a jobs programme that can say who it reached, who was placed and who stayed employed.
Fraud, Identity & Customer ProtectionStop the SIM swap, the takeover and the subscription fraud before the money moves, and let the fraud system make the call.
Mobile Money, Credit & Financial Services · HeuriTel
