Zipline for Underwriting

Underwrite the transaction, not just the application

Affirm underwrites every purchase in real time and Klarna re-decisions every transaction, and for everyone else the hard part is getting fresh features into the decision engine at all.

[d] Book a POC scoping call

[v] View docs

Fresher data moves the approval/loss tradeoff

Underwriting trades approval rate against loss rate, and fresher data improves both at once by letting you approve more borrowers without taking on more losses. The cleanest evidence comes from FinRegLab's independent 2025 study, where models built on cash-flow and bureau data together approved about 4% more borrowers at mainstream cutoffs with no added loss¹.

Affirm reports delinquencies three to four times below credit cards and credits per-purchase underwriting for it², while Klarna's book turns over fast enough that 83% of it refreshes inside three months³. Decision speed matters for a plainer reason as well, since 68% of consumers have abandoned a financial application at least once⁴, and one bank that cut its SME time-to-yes from 20 days to under ten minutes grew win rates by a third⁵.

Where credit modeling is heading

Cash-flow underwriting, which scores from bank-transaction data rather than bureau files alone, has gone mainstream. Chase adopted it through Nova Credit⁶, and Plaid became a consumer reporting agency and published its stack, an XGBoost model over 145 features computed on 30, 60, and 90-day transaction windows with SHAP-derived adverse-action reason codes⁷. Rolling counts, sums, and ratios over transaction windows are exactly the workload a feature platform exists to compute.

At the frontier, Nubank fuses transaction-sequence embeddings into its tabular models and measured a 1.2% AUC lift, which it describes as two to three times what a typical annual release delivers, now running in production for more than 100 million customers⁸. Either way the dependency is the same: point-in-time correct history for training, and fresh features at decision time.

Where the 12–24 months goes

McKinsey puts the industry norm at 12 to 24 months to get a new decisioning model live⁹. Part of that is validation and effective challenge under the interagency guidance, formerly SR 11-7 and now SR 26-2¹⁰, which exists for good reasons and which no platform removes.

The rest is engineering, since features get recoded by hand from the modeling environment into the decision engine, a step SAS puts at six months or more with real risk of coding errors along the way¹¹. Zipline removes that engineering wait, because the definition that builds the training backfill also serves the decision engine, and validators get generated consistency evidence instead of a reimplementation to review.

Leakage hides in end-of-day snapshots

Training sets built from end-of-day warehouse snapshots can quietly include information from after the decision moment, which is the usual reason a KS above 70 reads as a red flag rather than a breakthrough. The damage inflates offline metrics and only surfaces later in the vintage curves, and Nubank puts the consequence plainly, warning that undetected skew "may cause high-risk customers to receive loans when they shouldn't"¹². Zipline enforces the as-of date in the engine, computing every backfilled feature as of the decision timestamp.

Backtest a challenger against prior vintages

A candidate feature becomes a training-data column in hours. You define it, backfill it as of past decision timestamps, retrain the challenger, and read KS and Gini against prior vintages. Model risk review still applies to whatever you promote, but the point of the backtest is that weak challengers never get that far.

How Zipline works

You define a feature once, over transaction, bureau-refresh, or application events, and Zipline backfills point-in-time correct training data while serving that same feature at decision time with under 10 ms P95 latency and sub-second streaming freshness. The same values feed your SHAP reason codes in training and in production. Because deployment runs inside your own cloud and can be fully air-gapped, applicant data never leaves and there is nothing new to add to the data-sharing inventory. The same architecture extends to insurance underwriting on behavioral data streams.

"Before Chronon the feature pipelines were a disaster. Code was everywhere, some in Java, some in Scala, some in SQL. It was very hard to trace a feature. Now it's 10 lines of code where before there were 100s of lines across languages."

Daochen (Frank) Zha, Machine Learning Engineer, Airbnb

Proof

Credit Karma, an Intuit company, runs Zipline. Underneath is Chronon, the engine we built at Airbnb, which Stripe co-maintains while running 200+ risk features on it at 150 ms p99 freshness¹³.

See how a POC works →

Try it on one decision flow

A POC takes two to four weeks, whether you start with a fresh cash-flow feature set or with freshness upgrades to the inputs of an existing scorecard. You backfill, benchmark against your current features, and stand up a serving endpoint your decision engine can call, on AWS, GCP, or Azure.