Credit Default Risk Analysis

A lender relied on a rules-based scorecard and manual review to manage credit-card risk. The process was consistent, but it reacted late. By the time an account showed a missed payment, the cheapest interventions were gone: the limit had already been used, the collection call was already a recovery call, and the customer relationship had already taken the damage.

The decision

The risk team wanted to identify, three months ahead, which accounts were likely to default. But the useful question was narrower and more operational: which accounts should we contact, through which channel, and at what cost? The collections team had a monthly contact capacity, the business had a loss tolerance, and the model had to fit between them. That framing determined the default definition, the evaluation metric and the cut-off.

What we used

Three families of data were combined at the account level:

• Application data: income, employment tenure, product type and requested limit captured at origination.
• Bureau data: tradelines, utilisation, delinquency history and recent credit-seeking behaviour.
• Behavioural data: payment ratios, balance trends, cash-advance use, transaction volatility and prior collections activity.

Default was defined as 90 or more days past due within a three-month performance window. We built monthly observation points, and only information available before each point was allowed into the model. A default is rare, so the outcome was imbalanced and accuracy would have been a misleading headline.

The traps we designed around

• Hindsight leakage. Monthly observation points can quietly include the very month in which the account went bad. Every feature's availability date was checked against the observation date.
• Random splits on time-series behaviour. A random split lets the model learn from later months to predict earlier ones. Validation moved forward in time.
• Accuracy as a comfort blanket. Predicting "no default" for everyone is right most of the time and worthless. AUC, KS, calibration and lift by risk decile carried the evaluation.
• A threshold without an owner. The cut-off is a business policy about loss tolerance and contact capacity. It cannot be left as a default probability produced by software.

How the score was built

1. Define the outcome and the decision together. Default definition, performance window, intervention capacity and loss tolerance were agreed with the business before modelling. A score that ranks perfectly is still useless if the team can only contact 500 accounts a month.
2. Engineer behavioural features. Utilisation trend, payment ratio, delinquency roll rates, balance volatility, cash-advance frequency and income stability were constructed over 3, 6 and 12-month windows.
3. Build an interpretable baseline. A logistic scorecard with weight-of-evidence bins gave the team a transparent benchmark and a set of reason codes it could defend to reviewers and auditors.
4. Make the challenger earn its place. A gradient-boosted model captured non-linear interactions. It was compared with the baseline on AUC, KS, calibration and lift, and adopted only where it improved the decision without becoming unexplainable.
5. Turn scores into policy. A cost matrix for false positives versus missed defaults produced risk bands and contact thresholds. Every score was accompanied by its strongest contributing factors.
6. Operationalise and monitor. A portfolio dashboard tracked score distribution, delinquency migration, override rates and population stability. The monitoring plan covered drift, recalibration triggers and periodic fair-lending review.

What this changes

• Intervention moved earlier. Accounts could be prioritised before the first missed payment, while a limit adjustment or a payment reminder could still change the outcome.
• Decisions became explainable. Reason codes allowed the risk team to explain a flag to a customer, a reviewer or an internal auditor without reconstructing the model.
• Policy replaced convention. Risk bands, contact thresholds and cost assumptions had named owners and documented logic.
• Monitoring survived staff turnover. Score distribution, migration and override rates became a standing process rather than a one-off validation exercise.

What we delivered

• A calibrated default-risk score with reason codes for each account.
• A threshold and contact policy aligned with team capacity and loss tolerance.
• A portfolio dashboard showing risk bands, migration and early-warning signals.
• Model documentation, validation results and a monitoring plan suitable for internal audit and regulatory review.

Where this applies

This fits card issuers, consumer lenders and banks managing a book with bureau and behavioural data. The minimum inputs are an account identifier, application and bureau attributes, at least twelve months of behavioural history, a collections outcome and a known monthly contact capacity. The first deliverable is usually the outcome definition, the observation-point design and the capacity conversation — the three decisions that determine whether a good model can become a working policy.

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 delivery method for credit-risk projects.