A consumer lender could see delinquency in its portfolio reports, but only after a payment had been missed. By then the customer had already incurred a fee, the collections team was working a recovery case rather than a prevention case, and the cheapest intervention — a reminder, a shifted due date, a short payment plan — was no longer available.
The decision
Every morning the collections team could contact a fixed number of accounts. The question was not "who is risky?" in general but "which accounts should we contact today, and what should we say?" The score had to be produced before the due date, from behaviour already observed, and it had to fit the team's capacity rather than a statistical default.
What we worked with
The lender had three behavioural families available before a payment fell due:
- Repayment behaviour: loan counts and values, repayment ratios over 30 and 90 days, and the current loan-cycle marker.
- Top-up behaviour: recharge frequency and amount, median balance before a top-up, and days since the last recharge.
- Account context: tenure on the network and payback indicators.
The outcome was a short-horizon delinquency flag. It was rare in the population, and the modelling sample deliberately over-represented it — a sensible way to train a model and a reliable way to produce probabilities that are wrong everywhere else.
The traps we designed around
- Oversampling. The delinquency rate in the sample did not match the portfolio. Left uncorrected, every probability would be inflated. We treated the gap as a design fact and corrected for it rather than tuning it away.
- Leakage at the due date. Features are frozen at the point the score is produced. Anything recorded after that point — including the missed payment itself and the collections activity that follows — is outcome, not input.
- Ranking and calibration are different jobs. A list can rank well and still be wrong about the level of risk. The team needed both: an order to work the list, and a probability they could use to choose between a reminder and a payment plan.
How the score was built
- Fix the event and the action window. We defined what counts as delinquency, how far ahead the score must look, and the exact date at which each account's features were frozen.
- Correct the sampling with an offset. The correction was applied as a constant offset in the logistic model. It recalibrates the probability without changing the ranking — a distinction that matters when explaining why the same account keeps the same position on the list.
- Build behaviour features, not vanity features. Recharge recency, recharge frequency trend, loan size relative to top-up capacity and repayment ratio carried most of the signal. Sparse and near-constant variables were removed.
- Validate on a held-out period. We reported AUC, KS and lift by decile, not accuracy. Lift answers the operational question: how many delinquencies are captured in the slice of accounts the team can actually call.
- Set the threshold from capacity. The cut-off came from the number of accounts the team could contact each day. Each account carried its strongest drivers as reason codes, so the call could be scripted around a real cause.
- Plan for decay. A delinquency score is sensitive to changes in lending policy, payment channels and seasonality. We left a monitoring plan for score distribution, delinquency migration and recalibration triggers.
What this changes
- Contact moved before the due date. The team started working accounts while a reminder or a due-date change could still prevent the miss.
- The portfolio conversation shifted. Delinquency concentrated among low-activity customers with weak repayment capacity, not simply among customers with the largest loans. That changed who the team looked for.
- Interventions became graded. The score was paired with a policy — reminder, payment plan or manual review — so collections stopped applying the same call to every flag.
What we delivered
- A calibrated delinquency score with account-level reason codes.
- A daily worklist sized to the collections team's contact capacity.
- A threshold policy separating reminders, payment plans and manual review.
- Validation results and a monitoring plan covering drift and recalibration.
Where this applies
This approach fits lenders and subscription businesses that can see behaviour before a payment fails — top-ups, usage, partial payments or service contacts. The minimum inputs are a stable account identifier, the repayment calendar, at least six months of behavioural history and a team with a known daily capacity. The first deliverable is usually the event definition, the leakage review and a capacity-based threshold, not a model.
This is an illustrative case study built on an anonymized dataset; it does not report results from a specific client engagement. It reflects our standard method for short-horizon credit-risk modelling.
