Consilience vs. Zest AI (2026)

The refresh tax

At Affirm, I spent about four years on credit and fraud — most of it on the underwriting side, with a detour into loan pricing where I ended up patenting a reinforcement-learning approach. The work I loved was building the first model. The work that broke me was every refresh after that.

The build itself was tractable. Pull the data, run feature engineering, train, validate, ship. That’s the part data scientists are good at. The pain wasn’t in the modeling — it was everywhere else.

Three weeks of feature engineering would break because the data warehouse had migrated, an upstream team had deprecated a column, or a bureau had updated their format. The model risk team would push back on documentation that hadn’t kept pace with the code, and they were right to. By the time the refresh was “done,” the engineer who built the previous version was on a different team, and the refresh team was doing archaeology on six months of decisions to figure out what had changed and why.

The refresh tax is the part of credit ML nobody talks about at conferences. It’s also the part that decides whether a lender can actually respond when borrower behavior shifts mid-cycle. That’s what I built Consilience to fix — and the part most people miss is how.

How the factory actually works

The factory does what a senior credit data scientist does on a good day — and on top of that, it does what only an extremely well-staffed credit ML team manages on its best day. Two loops run at once.

The inner loop is feature iteration. The factory proposes new features against your data, trains a model, examines where the model is systematically wrong, proposes new features that address those errors, and prunes the ones that don’t pay off.

The outer loop is target iteration. The factory builds dozens of candidate models with different prediction targets, different time horizons, and different sub-population segmentations. The inner loop runs on each. The model that actually fits your portfolio surfaces from that search — not the model the data scientist happened to define on day one.

This is the search every senior credit ML team would run if they had unlimited engineer-weeks. They don’t. Consilience runs it on a measured compute budget, every refresh, without burning out a human.

That dual-loop search is why a refresh that took eight weeks at Affirm takes three days here, and why models come out meaningfully better than the ones they replace. Credit Key, a buy-now-pay-later lender we work with, came to us with a fraud problem. The factory built dozens of candidate models — varying not just the features but the prediction target itself, the time horizon, and the sub-population segmentation. The optimal model came out 9% higher AUC than their incumbent. End-to-end took roughly four days.

That 9% lift is what’s left on the table when a team skips this kind of search — which is what every team without an automated factory ends up doing the third or fourth time the model needs refreshing.

Zest AI is the most common managed-service alternative we see in evaluations. Here’s the honest call between the two.

Where the two products actually diverge

The 18-month catch

This is the section every prospect underestimates and every former managed-service customer learns the hard way.

When borrower behavior shifts — a fraud typology change, a rate cycle, a new-to-credit cohort showing up faster than expected — a managed-service customer submits a refresh request and waits for the vendor’s services bandwidth to deliver an updated model. By the time the model is updated, the portfolio has eaten the delta. I’ve watched this play out at three different lenders in the last twelve months. The pattern is identical:

1. Portfolio shock or behavioral shift (typically Q2 or Q4)
2. Urgent refresh request to the managed-service vendor
3. Vendor’s services bandwidth is constrained; engagement scheduled four to ten weeks out
4. Six to ten weeks of degraded portfolio performance while the refresh runs
5. Updated model deploys after the worst of the shock has already hit the loss curve

Consilience customers run the refresh themselves, on their own timeline, in days. The factory is theirs; the loop is theirs. The 18-month catch isn’t a hypothetical — it’s a structural property of the managed-service model.

My take

If you have any in-house Python literacy and any model roadmap that extends past a single underwriting model, buying Zest is the wrong call. I’ll say it plainly: you’ll pay the services premium twice — once on the build, again on every refresh — and at the end of it the artifacts aren’t yours.

Most lenders who tell me they have “no DS team” turn out to have one analyst who’s fluent in Python, a credit officer who lives in Looker, or a fraud lead who writes SQL. That’s enough to operate Consilience. If you genuinely don’t have any of those — and don’t plan to develop any over a multi-year horizon — Zest is a real option. But that segment is smaller in practice than it looks on a planning doc.

The harder question is the one I’d ask the CFO, not the head of credit: are you renting a model or building a capability? Renting works for the first quarter. By month 18, you’ve spent enough on services engagements to have built the capability — and you don’t have it.

Migrating from Zest to Consilience

Most Consilience customers running a Zest migration follow the same path:

1. Discovery (week 1). Map your existing Zest model variables, score cutoffs, and adverse-action workflow. Identify the data sources that already feed Zest — those become the Consilience inputs.
2. Parallel build (weeks 2-3). Consilience builds an equivalent model inside your AWS account using the same training data. The dual-loop search typically finds 15-30% of features Zest’s manual build didn’t propose, and often discovers a better-fitting prediction target than the one originally defined.
3. Parallel run (weeks 4-8). Both models score live applications. You compare approval rates, default rates by score band, adverse-action distributions, and disparate impact metrics. Your MRM team reviews both packages side by side.
4. MRM sign-off and cutover (weeks 9-10). Once your validators are comfortable, the Consilience model becomes champion. The Zest contract winds down at the next renewal point.

The migration is engineered for MRM sign-off, not for marketing optics. The expensive part is the parallel-run period, which is also the part that earns the validator’s trust.

FAQ