Risk Analytics · Python · LightGBM · SHAP
A customer-level risk analytics system built for Narsent to identify deteriorating payment behavior before it became obvious in traditional receivables reporting.
The system combined predictive modeling, risk calibration, portfolio segmentation, exposure analysis, and explainability into a single scoring pipeline designed to support finance and collection decisions.
The risk-scoring system was developed by a three-person team. My primary contribution was designing the analytical framework: defining how PD, LGD, DPD, exposure, risk buckets, and explainability should fit together, and adapting the system to receivables and financial-risk use cases.
That meant translating business and sector requirements into analytical and modeling requirements, and defining how model outputs should support portfolio and collection decisions. I also wrote code — co-developing the implementation and contributing directly to the Python modeling pipeline and validation work — but the implementation was collaborative rather than solely mine.
Traditional receivables reports are largely backward-looking. They tell a finance team which accounts are already overdue, but provide less help in distinguishing temporary payment friction from customers whose risk is materially deteriorating.
I approached the problem as three related risk dimensions:
The system modeled these through PD, LGD, and DPD signals and translated them into a portfolio-level scoring framework.
PD and LGD in this implementation are engineered proxy targets derived from payment behavior and exposure variables, rather than regulatory-grade estimates trained on realized default and recovery outcomes.
DPD is based on observed payment-delay behavior.
The modeling layer combines gradient boosting with linear models so that non-linear customer behavior can be captured without relying on a single modeling approach.
LightGBM captures non-linear relationships and interactions, while the regression branch provides a simpler complementary model.
The implementation uses a time-based 80/20 split rather than a random split.
The shared feature layer is StandardScaler-transformed features, not a neural-network embedding.
The scoring module consumes customer-level engineered features from an upstream payment-prediction pipeline.
Optional external and collections enrichment is supported as a system capability, and is not assumed present in every training run.
The output is designed for portfolio triage and prioritization, not simply as an ML prediction.
A high probability of payment stress does not carry the same business consequence for every customer.
The pipeline therefore combines risk information with current outstanding debt to produce a risk-adjusted exposure measure. This creates a more useful portfolio view: finance teams can distinguish between customers who are risky but financially small and accounts where deterioration could materially affect cash collection.
The final output also identifies high-risk customers and generates urgent-contact flags for accounts crossing both score and probability thresholds.
A portfolio score is difficult to use operationally if the user cannot understand what is driving it.
The pipeline uses SHAP TreeExplainers on the LightGBM models to calculate customer-level feature contributions for PD, LGD, and DPD.
The three explanation layers are combined using the same conceptual risk weighting: PD: 50% · LGD: 30% · DPD: 20%.
For each customer, the system can surface the most influential risk factors rather than returning only a score.
Examples of interpretable risk drivers in the implementation include payment delays, current debt, payment ratios, severe-delay frequency, risk volatility, and recent risk trends.
This makes the model output more useful for analyst review and operational follow-up.
Different risk targets require different evaluation approaches.
The implementation uses an ordered 80/20 holdout rather than a random split, preserving the sequence of the input data.
This system was developed as an operational receivables-risk layer within a broader decision pipeline, not as a regulatory credit underwriting model.
PD and LGD targets in the current implementation are engineered proxies based on observed payment behavior, debt, payment ratios, and upstream risk signals rather than realized default and recovery histories.
Where realized outcomes are unavailable, the calibration layer can operate using self-calibration. A production credit-risk implementation would instead require observed outcomes, out-of-time validation, stability monitoring, calibration testing, and formal model-governance controls.
The original risk-scoring system was connected to a broader AWS-based data pipeline. Production data and upstream pipeline inputs are confidential and intentionally excluded from the public repository, so the public notebooks do not contain a reproducible production run or publishable performance outputs.
For that reason, this case study focuses on the system design, risk framework, modeling methodology, calibration logic, and explainability rather than showing unverifiable performance charts.
The project changed how I think about risk modeling.
A useful risk system is not only about maximizing predictive performance. It also requires a clear definition of risk, appropriate validation, calibrated outputs, exposure context, interpretable drivers, and a way to translate model signals into portfolio decisions.
Working across those layers made the distinction between building a model and building a usable risk-analysis system much more concrete for me.