A scorecard's age bands break monotonic WoE in one bin — how do you fix the binning?

## Why monotonicity is a requirement, not a preference In a scorecard built for a consumer-credit decision a regulator or an internal reviewer will audit, each ordered characteristic is expected to tell a one-sentence risk story: *older applicants default less, and each older band is at least as safe as the one below it*. A weight-of-evidence run that rises, dips and rises again breaks that story in three ways: 1. **It is usually noise.** A dip in a middle band is far more often sampling variation than a real reversal in behaviour, and fitting it means the scorecard has memorised the development sample. 2. **It is fragile.** A non-monotone shape rarely reproduces on out-of-time data. When the applicant mix drifts, the dip moves or disappears, and the points table starts contradicting itself. 3. **It is hard to defend.** A points table where an applicant becomes *worse off* by getting older invites the reviewer's next question, and "the data said so" is not an answer that survives it. ## The diagnostic step first Do not reach for the merge before looking at the counts. For the offending band, read off the number of accounts and, more importantly, the number of **defaults**. Weight of evidence is a ratio of class shares, and the share of defaults is estimated from the default count alone — a band holding 12 defaults produces a WoE with a wide confidence interval, easily wide enough to swallow the dip. Compare the reversal's size to that uncertainty. If the band is large and the dip is big, you may be looking at a real effect worth investigating (a product boundary, a policy rule that only applies in that range, a data-quality break) before you smooth it away. ## The fix **Merge, do not split.** Combine the offending band with the adjacent bin whose WoE it is closest to, recompute the collapsed bin's counts and WoE, and check the run again. Repeat until the sequence is monotone. Two things follow from doing it this way: - Bins only get larger, so estimates get more stable, not less. - Information value falls slightly at every merge. That drop is expected and is the correct trade; a rise in IV from re-binning is the warning sign, not the goal. **Do it systematically.** Rather than hand-merging, re-cut with a monotone-constrained binning: a merge-based algorithm such as ChiMerge, which repeatedly combines the adjacent pair of bins whose outcome distributions differ least by a chi-squared test, or a shallow decision tree on the single characteristic to propose candidate cut points, followed by monotone merging. Either way the constraint is applied during binning, not patched afterwards. **Respect the minimum bin size.** Common practice is that no bin holds less than roughly 5% of accounts, and that every bin holds enough defaults for its WoE to mean something. A bin with **zero** defaults is a special case: its share of bads is zero, so its WoE is infinite. Merge it into a neighbour, or add a small constant such as 0.5 to both counts as a temporary measure, and treat the result as provisional. **Aim for few bins.** A continuous characteristic typically ends up with a handful — roughly five to ten. More bins raise IV on the development sample without improving out-of-time performance. ## When monotonicity does not apply Monotonicity only makes sense for a characteristic with an inherent order: age, income, months on book, number of enquiries. A nominal characteristic such as employment status has no order to be monotone in. For those you group levels with similar weights of evidence and enough volume, keep the grouping stable over time, and check that the grouping still makes business sense — not that the values ascend. There are also genuinely non-monotone continuous relationships. If the shape is large, reproducible on a held-out and out-of-time sample, and explainable, an approved exception is legitimate — but it should be a documented decision, not an accident of binning. ## The step people forget Cut points and WoE values are fitted from the target, so derive them on the **training data only** and apply that frozen table to validation, out-of-time and production. Tuning the cuts while watching validation performance leaks the outcome exactly as surely as computing the WoE on all the data does, and the monotone-looking result will not survive contact with next quarter's applications. ## What a strong answer sounds like Counts first, then merge toward the closest neighbour, then re-cut under a monotone constraint, then state the cost in information value and the guard rails (minimum bin size, few bins, training-only fitting) — and note that a nominal characteristic is exempt.