Explaining the ECL Walk: Small AI Agents for CECL and IFRS 9 Allowance Movements
Oct 20, 2026 · @Luiz Henrique Outi Kauffmann
How a team of small open models investigates why the allowance moved, using only deterministic risk tools, and ties every explanation back to the booked number.
If you’ve worked on a CECL or IFRS 9 month-end, you know producing the allowance is only half the job. The other half is the walk: explaining to the CFO, the ACL committee, auditors and examiners why the number moved. That walk is still mostly built by hand, in spreadsheets, across Finance, Credit Risk, Model Risk, the economists and the portfolio managers.
I’ve wanted to build an explanation layer for that walk for a long time. The NVIDIA x Red Hat Small Models Hack in Raleigh gave me the push and the constraint that made it interesting: every model had to be open and 33 billion parameters or fewer. That constraint matches what a bank actually needs. An agent small enough to run on a risk analyst’s laptop, or on the same infrastructure that already runs the CECL and IFRS 9 engine, means loan-level data never has to leave the building.
With Andre John de Souza and Gus Cavanaugh (Team Residual Zero), we built RiskLens AI. Its tagline is the whole brief: explain every dollar of credit loss.
The problem: a $19.24M move, before the close
Our synthetic bank holds 50,000 loans across CRE, C&I, mortgage, auto, consumer, cards and leases. Its allowance rose from $99.06M on July 31 to $118.30M on August 31: up $19.24M, or 19.4%, on a book that grew only 0.3%.
The questions are the ones every practitioner will recognize. Which portfolio caused it? Which borrowers should we look at? Was it the macro forecast, credit quality or growth? Did we change a model or the scenario weights? And does the explanation tie to the booked number?
The difficulty isn’t specific to one standard. CECL books lifetime loss from day one; IFRS 9 adds stage moves between 12-month and lifetime ECL. Both run several weighted scenarios that get re-forecast and re-weighted, both sit beside judgmental overlays, and in both cases auditors expect the drivers to sum to the booked change.
The rule: the agents never compute a number
A fluent explanation of a $19M allowance increase is worse than useless if one figure in it is invented. So RiskLens splits the work three ways:
- LLMs reason. They read the question, plan the investigation, delegate to specialists, pick tools and write the explanation, keeping fact separate from interpretation.
- Python computes. 33 deterministic tools run over the booked run: attribution, migration, macro Shapley, model inventory, reconciliation. Every tool returns JSON, never prose.
- Guardrails verify. Every figure in an answer is checked against tool outputs, and every call is logged with its parameters, a timestamp and a SHA-256 hash of the result.
A CECL Orchestrator delegates to eight specialists: Portfolio, Credit, Macro, Model Risk, Reconciliation, Quant, Reporting and Regulatory. Each sees only the inputs and tools its job needs, through allow-lists in config. All calls pass through one gateway that validates schemas, repairs malformed arguments, returns typed errors the model can retry on, and records provenance.
The agents explain and prioritize. They don’t make lending or booking decisions; people do.
Underneath: one engine for CECL and IFRS 9
The agents sit on a full month-end pipeline, not a toy dataset. Source extracts (loans, counterparties, macro vintages, weights, overlays) pass 17 pre-run controls covering data quality, model approval and weights. Then an official run books the allowance and writes a run log, which is exactly what the tools read and reconcile to.
The models are deliberately standard. PD comes from logistic scorecards with a macro logit shift, LGD from collateral coverage with macro sensitivity, and EAD from balance plus a CCF on undrawn amounts for revolvers. The engine projects marginal PD × LGD × EAD per loan, per year and per scenario over the contractual life, weights baseline, adverse and severe, and adds overlays.
The same book produces both results. CECL (ASC 326) is lifetime ECL for every loan. IFRS 9 gives 12-month ECL for Stage 1 and EIR-discounted lifetime ECL for Stages 2 and 3, with SICR triggered by PD change, rating notches, days past due and the watchlist. The engine was checked against a hand calculation and an independent loop implementation.
Every model ID, parameter and weight lives in config and a model inventory, so the agents can inspect them through tools instead of guessing.
The hard part: attribution order, not arithmetic
After I shared the idea on LinkedIn, a practitioner made the point every allowance team learns the hard way: the arguments are never about the total. They’re about the order in which you peel the drivers, because the drivers interact.
They interact for concrete reasons. PD is logistic, so the same macro shock lifts a downgraded borrower’s PD far more than a healthy one. PD × LGD × EAD multiply, so credit and macro changes compound. And scenario weights act on stressed ECL: in August the severe scenario alone is $189M against $95M baseline.
RiskLens answers this with an exact counterfactual walk. It starts from July inputs, swaps one input set at a time (exits, balances and terms, new loans, credit attributes, each macro variable, scenario weights, model versions, overlays), and reruns the engine after each step. Each step telescopes, so the walk sums exactly, and the residual is a real one, measured against an independent August run.
Then it measures the interaction instead of hiding it. A reversed walk and an exact Shapley decomposition (32 driver runs, 64 macro runs) show how much credit each driver gets under different orderings. Unemployment gets $4.25M in the walk and $4.41M under Shapley; CRE prices $3.07M and $2.94M. The agents report each driver with its robustness, and the Reconciliation Agent raises a WARNING when the methods disagree.
Get luizhenrique outikauffmann’s stories in your inbox
Join Medium for free to get updates from this writer.
This replaced the plugged waterfall in our earlier Dataiku ECL workbench, which rescaled the drivers to hit the total. That made the residual zero by construction, which is exactly why it couldn’t be trusted.
What the agents found
Macro and credit deterioration drove 93% of the $19.24M increase. Macro added $10.34M and credit $7.48M; growth added $2.19M, the severe-weight change $1.88M, and runoff took $2.66M off. Model versions contributed exactly $0.00M.
The walk reconciles to the booked change with a $0.00M residual, and all seven reconciliation controls pass. Macro stays the primary driver under the forward walk, the reversed walk and exact Shapley, so the headline doesn’t depend on the ordering.
The drill-down goes from portfolio to borrower. CRE accounts for $13.89M, or 72% of the change. Unemployment is the largest macro variable. The top borrower, CP_040408, went from BB+ to B+ with DSCR falling from 1.33 to 1.16 and LTV rising from 0.68 to 0.74, and its 12-month PD moved from 1.8% to 8.1%. The CRE PD model stayed CRE_PD_v4, so the whole methodology bucket is the move of the severe weight from 10% to 12%.
Those answers can be checked, because the synthetic story was written in on purpose: a worse macro forecast, about 20 CRE downgrades, $40M of new CRE, normal runoff and no model change. Its ground truth is stored apart from the tools, and a test confirms no tool or agent can read it. The agents matched all five labels: primary driver, primary portfolio, macro variable, model change and largest borrower.
Small models, running where the data lives
We scored every model on the same 15 validation questions practitioners would ask, from “what was July’s allowance?” to “does it reconcile?”, with the same tools, data and verifier. As a frontier reference, Claude Opus 5.5 scored 0.997 with an identical prompt and tools.
- Nemotron 3.5 Lightning (30B total, about 3B active), served with Red Hat vLLM on a single NVIDIA Brev A100, scored 0.977: 98% of frontier. On a held-out story with different correct answers it still scored 0.959.
- Nemotron 3 Nano 4B, on a 16 GB laptop through Ollama, scored 0.898 as a single agent. Nothing left the machine.
That second result matters most to me. A 4B model on a laptop gets 90% of frontier quality on this task because it doesn’t need to know CECL or IFRS 9. It needs to know which tool to call next.
On the laptop, the multi-agent team (0.892) tied the single agent overall but won the analytical questions: reconciliation scored 1.00 against 0.59, major drivers 0.86 against 0.74, and “what happened in CRE” 0.82 against 0.72. It lost on a long hand-off for the top-borrower question, and each delegation is another local model call, so the team took about 192 seconds per question against 89. Next, we’ll route simple lookups straight to one specialist and keep the team for drivers, CRE and reconciliation.
One practical lesson: Ollama’s 4k default context silently cut our 11.8k-token prompt. Raising it to 32k and warming the model up was the difference between a broken run and 0.898.
Scoring it, then teaching it
An explanation that sounds right isn’t the same as one that is right. We built a NeMo Gym environment that exposes the 33 tools as endpoints and adds a verifier, which scores every answer against the hidden ground truth. The reward weights correctness at 0.55, numeric grounding at 0.20, tool selection at 0.10, call validity at 0.10 and efficiency at 0.05. A give-up scores zero.
The same environment also produces training data. We ran 540 Nemotron investigations across five stories (the base story plus credit-led, growth-led, weights-shift and consumer-stress variants), kept the 401 runs that scored 0.95 or higher, and trained a LoRA (rank 16, 67 minutes on one A100 80 GB).
We tested it on a property-shock story it had never seen, with reasoning turned off. The mean reward rose from 0.751 to 0.939. More importantly for a bank, answers with no tool call fell from 14 of 60 to zero. Without the LoRA, the base model made up figures, for example a $45.3M July allowance when the engine said $97.49M. The fine-tuned model calls the tool first. The adapter is published on Hugging Face.
It isn’t finished. With reasoning on, the LoRA adds nothing yet, and it hasn’t learned the CRE borrower drill-down.
Where this goes: an agent beside the engine
The reason I care about small models here isn’t the leaderboard. It’s where the agent can live. A 4B model on an analyst’s laptop, or a 30B model on the same GPU or vLLM cluster that already runs the CECL and IFRS 9 engine, can explain the allowance without loan-level data ever leaving the bank.
RiskLens isn’t meant to replace anyone’s engine. It reads a booked run, from whichever vendor produced it, and explains it. Point it at extracts with the same columns (we prepared a path from Dataiku) and rerun, with no code changes. The people who own the allowance stay responsible for it; the agents just make the walk faster to build and easier to audit.
Next on the list: routing simple lookups straight to one specialist, running the team on vLLM instead of a laptop, teaching the fine-tune the CRE drill-down, and adding IFRS 9 staging explanations and a quarterly ACL committee pack.
If you own a CECL or IFRS 9 allowance, validate the models behind it, or audit it, I’d value your view:
- How does your team fix the attribution order, and who signs off on it?
- What would an automated explanation need before you’d put it in a committee pack?
- Would you run something like this on your own extracts as a pilot?
The code is at github.com/Luizkauffmann/Nvidia-Redhat-RiskLens. All figures above come from a synthetic bank (seed 20260831) and the deterministic engine or the Gym verifier, not from any real institution.
