NotesMethodMachine-learning models

Scorecard or gradient boosting? Let held-out data decide

No method is presumed better. The held-out data, the policy, and the validator's questions pick the production model.

By Can Demir · Founder of eqlxPublished 8 min read

A credit risk head asks a fair question: should the new application model be a scorecard or a gradient-boosted model? The honest answer is that neither is presumed better. A logistic-regression scorecard, a gradient-boosted tree ensemble, a neural network, or a hybrid of them can each be the right production model. Which one is right depends on the institution's data, on what the score has to do once it leaves the model, and on what the independent validation unit needs to see. The choice is made on evidence, and the evidence has more than one part.

Why the question keeps coming back

Gradient boosting often ranks applicants well on rich, uneven data, because it finds interactions a scorecard has to be told about. A scorecard is compact, its points read line by line, and many risk teams have years of practice monitoring one. Both statements are true at once. That is why the question cannot be settled by preference, and why it should not be settled by one number on one test set either.

Build the test before the models

A comparison is only as good as the data it runs on. Before either model is trained, we fix three samples:

  1. Development data, where the candidates are fit and tuned.
  2. Held-out data from the same period, never touched during tuning, to see how each candidate ranks cases it has not seen.
  3. Out-of-time data, from a later period, to see how each candidate holds up once the portfolio, the economy, or the process has moved.

The revised US model risk guidance (SR 26-2, issued in April 2026 by the Federal Reserve, the FDIC, and the OCC) describes model testing as ranging “from out-of-sample and out-of-time testing, to a comparison of alternative assumptions and methodologies.” That is the shape of the work: every candidate faces the same samples, the same definition of a bad outcome, and the same performance window.

Five things to compare, not one

Ranking power. The area under the curve (AUC), or its rescaled form, the Gini coefficient, says how well a model orders the cases that went bad above the ones that did not. It matters. It is also only the first column.

Calibration. A credit decision uses probabilities, not just an order. When a well-calibrated model says one in ten, about one in ten such cases should default. A model can rank well and still be badly calibrated, and a combined score can hide it: the scikit-learn documentation notes that “a lower Brier loss, for instance, does not necessarily mean a better calibrated model.” Recalibration can repair the probabilities; it cannot repair the ranking.

Stability. Compare each candidate's results on held-out data with its results out of time, and how steady its score distribution and main inputs are across periods. A candidate that wins in development and falls back out of time is telling you how it will age.

Reasons. A declined applicant is owed specific reasons. In the United States, the Consumer Financial Protection Bureau's Circular 2022-03 says creditors may not “use complex algorithms when doing so means they cannot provide the specific and accurate reasons for adverse actions.” Whatever rules apply locally, the practical test is the same: produce the reason codes for a sample of declines from each candidate, and have the credit team read them. A scorecard gives them from its points. A tree ensemble needs an attribution method, and its reasons have to be checked for being stable and true to the model, not just plausible.

Documentation. The independent validation unit has to be able to challenge the model: intended use, data and lineage, the method and its limits, test results, and why this method was chosen over the others. A candidate that cannot be documented to that level is not ready, whatever its Gini.

Why one metric cannot decide

There are three reasons. First, a small difference in AUC on one sample can sit inside that sample's noise; a gap that does not hold out of time is not a gap. Second, a metric measures the model, not the decision: two candidates with the same AUC can approve different people at the institution's cut-off, with different losses. Third, the metric says nothing about calibration, reasons, stability, or how the model will be monitored.

SR 26-2 asks for “effective challenge” by people with the expertise and “sufficient independence to maintain objectivity.” That challenge needs more than one number. So we also put the candidates side by side at the decision itself: at the cut-offs the policy is considering, what each approves and declines, its expected loss, and which applicants swap between them. The swap set, the applicants one candidate approves and the other declines, is often the most telling table in the report, because the credit team can read those files and say which candidate is right about them.

Hybrids and the honest middle

The choice is not always either-or. A scorecard can use bins and interactions first found with a boosted model. A boosted model can be constrained so the score moves in one direction only as an input rises; the XGBoost documentation describes this as enforcing “monotonicity constraints on any features used in a boosted model,” which makes its reasons easier to defend. A segment with different behavior can get its own model. Each of these is one more candidate, and it goes through the same five tests on the same samples.

What the institution receives

The chosen model, its pipeline, and an evaluation report that shows every candidate on the same samples: ranking power, calibration, stability, sample reason codes, and the comparison at the policy's cut-offs. The documentation is written for the institution's independent validation. We prepare the evidence; the validation unit judges it, and the institution chooses the method that goes into production.

Sources

https://eqlx.ai/blog/scorecard-or-gradient-boosting · Printed copy; the website is the current version.