Where AI Tools Actually Fit in Credit Modeling

There's no shortage of enthusiasm right now about applying large language models and AI agents to credit underwriting. We want to be clear about where we stand on that — and then make a more interesting point about where these tools genuinely do add value.

What LLMs Are Not For

We've written elsewhere about why supervised machine learning algorithms — gradient-boosted models like XGBoost in particular — remain the right foundation for credit underwriting. The reasons are well understood in the industry: they're powerful, interpretable, stable, and auditable. Tools like LLMs don't meet that bar for core decisioning. They can be opaque, they can be unstable, and they don't outperform purpose-built supervised models on structured credit prediction tasks. Nobody serious is proposing to use a generative AI model to underwrite loans.

But that's not the end of the conversation. It's actually the beginning of a more useful one.

What LLMs Are Good For

Where we've found these tools genuinely valuable is as enablers of the modeling process itself — not as the algorithm doing the decisioning, but as a force multiplier for the data scientists and analysts doing the work around it.

A few specific use cases:

Validation and code review. LLMs can quickly review modeling code for logical errors, flag unexpected behavior, and help confirm that implementations are doing what they're supposed to. This kind of rapid validation used to require significant time from a senior team member. It still requires that person's judgment — but the tool can accelerate the process considerably.

Data exploration and cleaning. Exploratory data analysis, feature engineering, and data cleaning are labor-intensive. AI tools can help move through these steps more efficiently, surfacing patterns and generating code that would otherwise take meaningful people-hours to produce.

Experiment generation. One of the more powerful applications we've seen: using AI tools to rapidly cycle through modeling experiments — different dependent variable definitions, different model structures, different feature sets — that previously would have required significant extra time and headcount to execute.

In each of these cases, the tool is making skilled people faster and more thorough. It's not replacing the judgment that makes the work sound.

A Useful Analogy

A recent episode of the Freakonomics podcast illustrated this dynamic in a way that stuck with us, even though it had nothing to do with credit modeling.

The episode featured a group of researchers who had published a study finding that traffic fatalities increase significantly on days when top-selling albums are released. The hypothesis: album releases drive streaming, streaming drives distracted driving, distracted driving causes accidents. The authors had run the study carefully — controlling, among other things, for the fact that major album releases almost always drop at midnight Eastern on Fridays, a time already associated with elevated traffic risk. Their controls compared release Fridays to the preceding and subsequent Fridays, and to the nearest equivalent Friday the prior year. The findings held up through peer review.

Before the interview, the Freakonomics hosts — who are comfortable with data and research but aren't specialists in traffic safety or causal inference — used Claude to replicate the study using publicly available data. It worked. The replication came together efficiently, and the findings held.

Then things got interesting. In the time between the paper's publication and the podcast taping, an additional year of data had become available. The hosts fed it in and found the results didn't hold for 2023 — which they brought back to the original authors.

The authors investigated and identified the problem: in 2023, there were very few album releases that met the study's threshold, and those that did fell on consecutive Fridays. That broke the control mechanism, since the comparison Fridays were themselves album release dates. Once the authors adjusted for this, the core findings held again.

What this illustrates for us: the AI tool did exactly what it should have — it enabled rapid, efficient replication of a complex analysis. But the step that rescued the finding required subject matter experts who understood the experiment's structure well enough to identify why the controls had broken down. Without that expertise in the loop, a finding that was actually valid would have appeared to be refuted.

What We've Seen in Practice

We've encountered versions of this dynamic in our own work.

In a recent advisory engagement with a BNPL lender in Latin America — a sophisticated team actively pushing the frontier of how they use AI in their modeling work — we were able to suggest a broad set of experiments throughout the model development process: different dependent variable definitions, different structural approaches, different feature treatments. A few years ago, cycling through that range of experiments would have required significant additional time and resources. With AI tools supporting the coding and execution, the team moved through them efficiently and surfaced some meaningful structural insights.

But at several points during review, results came back that didn't make sense. Certain segments were behaving in ways that were inconsistent with what we'd expect given the data. Tracing it back, the team found errors in how database fields had been encoded — the model's target variable had been constructed incorrectly in some cases as a result. The AI-assisted coding had accelerated the process, but it hadn't caught the error. Human review did.

We've seen the same dynamic in more hands-on work for a US client, where we were using AI tools to design and simulate credit policy scenarios — modeling the profitability and risk trade-offs of different underwriting configurations. The tools let us move quickly and stretch our team's capacity, including bringing team members into the analysis who don't typically work in code. We got through the simulation work much faster than we would have otherwise.

When we reviewed the outputs, though, a few of our analysts flagged that some results looked better than real-world outcomes would suggest. Looking closer, we found that the AI had used inconsistent time periods across the baseline and comparison scenarios, producing results that weren't apples-to-apples. When we surfaced that and corrected it, the analysis held up — but only because someone familiar with how these simulations should behave caught the inconsistency in the first place.

The Pattern

Across these examples, the same structure repeats. AI tools are genuinely useful: they make processes faster, enable more thorough testing, and extend what a skilled team can accomplish within a given timeframe. That's real value, and we expect it to grow.

But the oversight requirement doesn't go away. In fact, it may become more important as the tools become more capable and the outputs more polished. The errors we've described weren't obvious — they required people who understood the modeling context deeply enough to recognize when something didn't add up. That kind of domain expertise is what makes the human-in-the-loop not just a compliance checkbox but a genuine safeguard.

We're enthusiastic about what these tools can do for credit modeling workflows. We're also clear-eyed that deploying them well requires exactly the kind of subject matter expertise that's easy to underestimate when the outputs look compelling.