Zipline for Payments

Ship a new fraud signal in days

Within five days of a card being compromised, a third of those accounts already see fraud¹, so whether your models can answer in days rather than quarters comes down to your feature infrastructure.

[d] Book a POC scoping call

[v] View docs

False declines cost more than the fraud does

$33.4B

global card fraud in 2024²

$50.7B

lost to false declines in one year, across just four countries³

$4.61

what each $1 of fraud costs a merchant all-in⁴

Beyond the fraud itself, 42% of falsely declined customers never come back³, and merchants turn away 5% of orders when only 3% are actually fraudulent⁵, because thin or stale signals make over-blocking the safe default.

Better features pay on both sides of that decision, and it shows in the numbers Stripe and Adyen report: Stripe's retry models recovered $6B in falsely declined payments in 2024⁶, and Adyen's merchants saw up to 6% more conversion in its pilot⁷, which is why a tenth of a percent of authorization turns into real money at this scale.

Where payments ML is heading

Fraud models have moved through three generations, and each one asks more of the data underneath it.

Gradient-boosted trees

over hand-built velocity features, the long-standing baseline.

Sequence models

over raw transaction streams, where Feedzai measured a 9.7% recall gain at the same false-positive rate after making the jump⁸.

Foundation models

trained on transaction histories, where Stripe reported lifting detection of attacks on large businesses 64% practically overnight⁹ and Nubank now runs one for over 100 million customers¹⁰.

Every one of them has to score inside the authorization window, where published budgets run from about a millisecond to under a hundred, and every one leans on the same infrastructure: point-in-time correct histories for training and millisecond-fresh values online.

Velocity features usually get built twice

The workhorse feature in payments ML is the windowed aggregate, the count of attempts from a card, device, or IP over the last hour, day, or week. In most stacks it ends up written twice, once in the warehouse for training and again in the decision engine for serving, usually by different teams in different languages, so the two copies drift and iteration slows to the pace of the second team. Labels make it harder still, because fraud confirmations arrive from issuers days after the transaction as TC40 reports, which means honest training data has to reconstruct what was actually knowable at decision time.

The attacks themselves move at machine speed, and at the 2022 card-testing peak Stripe was blocking more than 20 million attempts a day¹¹. Uber's first fraud-rules platform took a year and a half to ship 300 rules, and once the team rebuilt its iteration loop the next 200 shipped in three months¹².

How Zipline works

A single definition computes the point-in-time correct backfill, with label delay modeled in, and serves that same feature online, so there is no second implementation left to drift out of sync. In production that gives you:

<10 ms P95 fetch

inside the authorization window

<1 s P99 freshness

on streaming velocity counters

Full-history backfills

consistent with serving by construction

We built Chronon at Airbnb for exactly this loop, and Stripe adopted it in 2022 as the foundation of its own feature platform, reporting p99 feature freshness of 150 ms and a new SEPA fraud model that blocks tens of millions of dollars of additional fraud a year¹³.

"Chronon's point-in-time correctness and single engine for both historical and real-time processing let us migrate the vast majority of Stripe's fraud-detection features in just a few months, serving thousands of features to our models while meaningfully cutting infrastructure spend with no impact on latency or availability."

Arash Rai, ML Engineer, Stripe

Backtest a fraud signal before it ships

A candidate velocity feature or embedding becomes a training-data column in hours. You define it, backfill it across your transaction history, retrain, and read the lift against last year's attack waves. A backtest can't promise that tomorrow's attack looks like yesterday's, but it does tell you which signals are worth a shadow deployment while the attack is still running.

Foundation models still need this layer

Behavioral embeddings run through this layer too. Stripe serves its foundation-model embeddings from the same Chronon-based platform, which is what lets a new fraud or authorization model become a weekend project rather than a quarter one. Once the features and embeddings are in place, authorization optimization, retry timing, and dispute deflection each become another model on top rather than another pipeline to build.

Proof

Stripe runs its fraud feature platform on Chronon and co-maintains the project, and Credit Karma, an Intuit company, is a Zipline customer. Chronon also runs in production at teams like Airbnb, Netflix, and OpenAI, with payments-adjacent adopters including Sardine AI and Airwallex.

See how a POC works →

Try it on your own transactions

A POC takes two to four weeks on a single decision point, whether that's a set of card-testing velocity features, an auth-retry model, or a dispute-risk signal. You backfill, serve, and measure consistency against your current pipeline, all inside your own cloud on AWS, GCP, or Azure, air-gapped where compliance requires it, so transaction data never leaves.