Most AI underwriting projects don't die because the model was bad. They die because nobody could explain the model to the people who are legally required to understand it: model risk management, fair lending officers, and eventually regulators.
We've watched lenders spend nine months building a gradient-boosted approval model with a 12% lift in approval rates at constant loss, only to have it stall in model governance for another year. The lesson we took from that: compliance is not a review gate at the end. It's a design constraint at the start.
The regulatory floor is not negotiable
If you lend in the US, three things shape every underwriting model you ship:
- ECOA and Regulation B. Every declined applicant gets an adverse action notice with specific, accurate principal reasons. "The model said no" is not a reason. Your reason codes must reflect what actually drove the decision.
- Fair lending. Disparate impact analysis isn't optional. You need to test approval rates and pricing outcomes across protected classes before launch and continuously afterward, and you need documented searches for less-discriminatory alternatives.
- SR 11-7 model risk management. Independent validation, documented assumptions, ongoing monitoring, defined model boundaries. If your model documentation can't survive a validator who wasn't in the room when you built it, it isn't done.
None of this prohibits machine learning. It prohibits unaccountable machine learning. That distinction is where the engineering work lives.
Explainability you can defend, not just demo
SHAP plots in a notebook are table stakes. What matters in production is a reason-code pipeline that is deterministic, tested, and consistent with the model's actual behavior.
Our standard build looks like this:
- Constrain the model where domain logic demands it. Monotonic constraints on features like debt-to-income and delinquency counts. If more delinquencies ever increase an approval score, you have a model you cannot explain and a lawsuit waiting to happen.
- Generate reason codes from attributions, not from a lookup table. We compute per-decision attributions, map them to a governed library of adverse-action reasons, and log the mapping with the decision. Every notice is reproducible from the audit record.
- Test the explanations like code. We maintain a suite of synthetic applicants with known characteristics and assert that reason codes come out sensibly. When the model is retrained, the explanation tests run in CI alongside performance evals.
If your reason codes are generated by a separate surrogate model, validate the fidelity gap explicitly. We've seen surrogate agreement below 80% on declined applications — which means one in five adverse action notices was describing a decision the real model didn't make.
Fair lending as a continuous eval, not an annual audit
The pattern that works: treat fairness metrics exactly like accuracy metrics. Same dashboards, same alerting, same retrain triggers.
Concretely, we instrument approval-rate ratios and score distributions across BISG-proxied demographic groups, computed weekly on production traffic. Thresholds are set with compliance counsel before launch. When a metric drifts — and it will, because applicant populations shift — the alert routes to both the ML team and the fair lending officer with the same severity as a performance regression.
We also bake the less-discriminatory-alternative search into the training pipeline itself: for every candidate model, we automatically train constrained variants and report the fairness/performance frontier. The model risk file then documents an actual search, not a retrospective justification.
What production actually requires
Beyond the model, an underwriting system that survives contact with reality needs:
- Decision logging with full input snapshots. Not "we can reconstruct it from the warehouse." The exact feature vector, model version, score, threshold, and reason codes, immutable, retained per your record-keeping policy.
- Champion/challenger with hard guardrails. Challengers score in shadow for weeks before any traffic allocation. Overrides and manual reviews are logged as labeled data.
- Population stability monitoring. PSI on inputs and score distributions, because underwriting models degrade quietly when marketing changes the applicant mix.
- A documented human path. Second-look processes and override policies that are themselves monitored for fairness effects. Human overrides can reintroduce the bias your model removed.
Where we start
Our underwriting engagements begin with a 4–6 week Pilot: one product line, one decision point, a shadow-mode model with the full explainability and fair-lending harness attached from day one. The deliverable isn't a slide deck about feasibility — it's a running system scoring live applications in shadow, a model risk documentation package, and measured lift against the incumbent scorecard.
From there, a Co-Build takes it through validation and into the primary decision path, typically over 3–6 months, with your model risk and compliance teams in the loop at every gate rather than at the end.
The teams that win with AI underwriting aren't the ones with the fanciest architectures. They're the ones who made the model explainable, monitorable, and defensible before anyone asked — because in lending, "production" includes the examination room.