Load the cardholder file
A profile comes back immediately, before any modeling starts.
This is our full cardholder file -- limit, demographics, six months of billing and payment history. Who's likely to default next month?
Loaded: 30000 accounts, 23 attributes. No missing values. I'll work from a balanced 8000-account sample for this session so each step stays quick.
Share of accounts that missed their payment the following month, across the full 30000-account file.
Build a model
A few rule-set sizes get compared before anything is finalized.
Build something collections can act on without needing a data scientist to interpret it.
Repayment history alone, one column at a time, was a weak signal here -- pairing two months of repayment status together did much better, so that's the version I compared:
12 paired-month rules score about as well as 16 -- no reason to carry the extra four.
Built -- and every one of the rules turned out to involve repayment status across two consecutive months, not bill or payment amounts.
Tune for collections' priority
Say what trade-off matters operationally -- the comparison runs itself.
We have outreach capacity to spare this month. I'd rather flag too many accounts than miss real defaults.
I compared four versions, weighting "will default" more heavily rather than adding more rules:
cw3 catches 0.509 of defaults instead of 0.310, at the cost of precision dropping from 0.729 to 0.540.
I've made that one active. reversible
Plain-language summary
A restatement of the model's own readout.
What's actually driving this -- in plain terms?
It isn't any single month of being late -- it's the combination across two months. The strongest rule is PAY_0=[2,8), PAY_3=[0,2) (coefficient +1.829).
Score this month's accounts
A table ready to hand straight to collections.
Score three accounts from this billing cycle.
| account | limit | age | PAY_0 | true | P(default) | flag |
|---|---|---|---|---|---|---|
| #26588 | 80000 | 55 | 2 | default | 0.926 | priority outreach |
| #23928 | 20000 | 22 | 0 | no default | 0.321 | routine |
| #25581 | 180000 | 31 | 1 | no default | 0.310 | routine |
All three match what actually happened the following month.
Rule analysis
Every rule behind the active model, ranked by how much it moves the score.
Show me all 12, ranked.
Every rule the model kept is a combination of repayment status across two billing cycles.
Explain a flag
For any single account, the exact arithmetic behind the score.
Walk me through account #26588 -- why 0.926?
7 of the 12 rules are active here. Running the combination in order of size:
Some active rules pull the score down; the strongest ones win out.
Hand off to risk operations
Trim to a shorter rule set if needed, with a logged reason for every change.
Risk ops wants this under 8 rules before it goes into the daily batch job. While you're trimming, can you also have it pull fresh bureau data automatically each month?
Trimming the rule set is something I can do directly. Wiring in an automatic monthly data feed is a separate integration question -- that touches your data pipeline rather than the model. Here's the trim:
removed (lowest |coefficient|): PAY_0=[2,8), PAY_4=[0,7) coef=+0.3261 PAY_2=[2,7), PAY_5=[0,7) coef=+0.1024 PAY_3=[2,8) coef=+0.2895 PAY_3=[2,8), PAY_5=[0,7) coef=-0.3429
AUC moves from 0.707 to 0.706; catch rate from 0.509 to 0.507.