Context
A plausible income estimate is not a verified income label
In digital lending, a customer’s actual income can be difficult to observe directly. That makes it challenging to evaluate a provider’s income-related data: agreement with another proxy does not prove that either measure is accurate.
I approached this as an evidence problem. Did the signal have a credible interpretation? Did it distinguish repayment outcomes? Could it support a useful decision in the existing business context?
Those questions are related, but they are not interchangeable. A variable can look reasonable without helping risk differentiation, or show statistical separation without a clear and dependable business application.
Approach
01Start with a testable business hypothesis
Before interpreting a variable, I considered what it was intended to represent. For income and repayment-capacity signals, I used supporting information such as social-insurance continuity, credit-card limits and credit ratings to examine whether the patterns were broadly coherent.
For other signals, the starting point could be a hypothesis about financial pressure. For example, borrowing from high-cost platforms might indicate stress, but the signal itself was not sufficient proof of inadequate repayment capacity. The hypothesis needed to be tested against customer characteristics and repayment outcomes.
02Look for converging evidence
I compared the external signals with proxy information and observed credit performance. The aim was to build a reasoned interpretation from multiple imperfect sources, rather than presenting a proxy comparison as direct income validation.
Provider discussions and sample preparation were part of that work: understanding the product and testing it on the relevant customer population mattered before drawing a conclusion about usefulness.
| Evidence | Question | What it cannot establish alone |
|---|---|---|
| Social-insurance continuity and credit-related proxies | Is the signal consistent with a plausible customer profile? | Exact income accuracy |
| Lookup coverage | How much of the relevant population has usable information? | Predictive usefulness |
| Repayment outcomes across bins | Does the signal distinguish observed risk? | A causal relationship |
| Variable combinations | Does a combination reveal a useful segment? | Production suitability without further validation |
| Post-launch observations | Does coverage or observed behaviour change in use? | Permanent stability |
The assessment combined distinct forms of evidence. No single metric answered the entire adoption question.
03Explore thresholds and combinations
Across relevant assessments, I used Python for data preparation, statistical analysis and decision-tree exploration of candidate splits and variable combinations. Measures such as IV, KS and PSI supported the relevant checks of differentiation and stability; the test selection depended on the product and the question.
Decision-tree splits were useful for identifying candidate segments with different observed outcomes. Their role was analytical: to help assess whether a source might be worth introducing and how its variables might be used in a policy. This work was not the development of a new production machine-learning model.
- Start from a business hypothesis.
- Assess the sample and signal.
- Check proxy consistency and risk differentiation.
- Explore candidate thresholds and combinations.
- Make a recommendation and proposed use.
- Monitor products that are deployed.
A useful statistical pattern needed a credible interpretation and an application. Individual products followed the checks relevant to their use case.
04Carry the conclusion into a recommendation
My contribution included discussing the products with providers, preparing samples, conducting the assessment and presenting recommendations to management. For products that went live, I monitored lookup coverage and whether observed behaviour remained consistent with the original assessment.
Technology integration and interface requirements were handled outside my role. I do not equate evaluating a product with deploying its API or owning the procurement decision.
Worked exampleIllustrative method
A split is useful only when you can interpret the segment it creates
The fictional signal below is ordered from lower to higher. Each band contains 1,000 observed borrowers.
| Fictional signal band | Observed borrowers | Bad outcomes | Observed bad-outcome rate | Lift vs sample average |
|---|---|---|---|---|
| Low | 1,000 | 40 | 4.0% | 2.0× |
| Medium | 1,000 | 15 | 1.5% | 0.75× |
| High | 1,000 | 5 | 0.5% | 0.25× |
| Total | 3,000 | 60 | 2.0% | 1.0× |
Synthetic values and outcomes, not a vendor result. The fictional signal separates observed risk in this sample. This alone does not establish incremental value over existing information, robustness in a new period or suitability for a production rule.
A proposed use still needs to account for sample size, coverage, consistency and the existing decision process. These are interpretation criteria for the example, not a claim that an identical validation protocol was completed for every product.
Outcome
Evidence to support adoption and application decisions
The assessment work covered more than sixty external data products. It supported management decisions on whether a source was useful and how relevant signals might contribute to lending policy.
The value of the work was in making those recommendations defensible: separating plausible interpretations from observed risk patterns, exploring candidate applications and revisiting deployed data as coverage and performance evolved. I do not attribute a quantified portfolio loss reduction or procurement saving to this work without a verified measurement.