Chime - Fraud Detection at Neobank Scale

Chime had 8.6 million active members when it filed its S-1 in March 2025. Each one has a debit card, a checking account, and access to early direct deposit. Most use the card multiple times a day. That's tens of millions of transactions flowing through a fraud system that needs to say yes or no before the card terminal times out.

The easy assumption is that Chime runs the same fraud stack as a traditional bank, just smaller, with fewer customers and simpler infrastructure. But a neobank's fraud surface looks nothing like a legacy bank's, and the architecture Chime built to handle it is a serverless streaming system that most bank engineers wouldn't recognize.

The neobank fraud surface

Traditional banks have branch networks, in-person identity verification, and multi-day settlement windows that create natural friction against fraud. A neobank removes all of that friction on purpose, because friction is what makes the legacy experience bad. The same features that attract customers also attract fraudsters.

Early direct deposit is the clearest example. Chime advances payroll funds up to two days before the employer's bank settles the ACH transfer. A legitimate customer sees their paycheck on Wednesday instead of Friday, but a fraudster sees a two-day window where Chime has extended credit against money that hasn't arrived yet and might never arrive.

SpotMe, Chime's fee-free overdraft feature, creates another surface. Customers can overdraw their account by up to $200 on debit purchases with no fee. A legitimate customer treats it as a safety net, but a fraud ring treats it as a $200 credit line on every synthetic identity that clears onboarding.

Visa Direct and instant transfers compress settlement windows from days to seconds. A fraudster who gains access to an account can move money out before any batch-based detection system runs its nightly sweep.

The pattern across all of these: every product feature that removes friction for customers simultaneously removes friction for fraud. The fraud system can't add the friction back, so it has to make faster decisions with less information.

What Chime built

Chime's fraud detection pipeline runs on AWS serverless infrastructure. The architecture was detailed in a joint AWS-Chime engineering post describing what they call Streaming 2.0.

The event ingestion layer handles over a million events per second through Kinesis, including not just card swipes but login attempts, balance checks, transfer initiations, profile changes, and device fingerprints. Every user action that might signal fraud context flows into the same stream.

AWS Glue processes the raw events, transforming and enriching them into features the ML models can consume. The processing target is a 5 to 15 second data freshness SLA, meaning a transaction that happens right now produces features that models can query within 15 seconds.

DynamoDB serves as the online feature store. When a card authorization arrives and the fraud model needs to know "how many transactions has this customer made in the last hour from this device," DynamoDB answers in single-digit milliseconds. The same data lands in S3 as an offline store, so the training pipeline sees exactly the same features the production models see. No training-serving skew.

SageMaker hosts the models. Chime runs 40 or more ML models in production, managed through an internal framework called MLKit. MLKit is config-driven. Teams define a model's features, thresholds, and rollout percentage in configuration files rather than deployment code. A new model version ships by changing a config, and rolls back the same way.

The entire streaming platform serves over 500 developers across Chime, not just the fraud team. Product analytics, risk scoring, compliance monitoring, and customer experience teams all consume the same event stream.

Why serverless matters for fraud

Most fraud detection architectures at traditional banks run on dedicated Kafka clusters with Flink or Spark Streaming for processing. Chime chose fully managed AWS services instead, and the trade-off is deliberate.

A self-managed Kafka cluster requires capacity planning. You provision for peak load, which means paying for Black Friday capacity on an average Tuesday. Kinesis scales with throughput. Chime's fraud pipeline processes a million events per second without an infrastructure team sizing broker partitions.

The same logic applies to Glue over Flink. A Flink cluster needs operators who understand checkpointing, state management, and recovery. Glue is fully managed. The trade-off is less control over processing semantics and higher per-event cost at massive scale. For Chime's volume, the operational simplicity wins over the cost optimization.

Most ML teams build feature stores on Redis or a dedicated platform like Feast or Tecton. DynamoDB gives Chime single-digit millisecond reads with automatic scaling, and it doubles as a general-purpose data layer that other teams already use. One fewer system to operate.

The cost is vendor lock-in. Chime's fraud pipeline is deeply coupled to AWS primitives. Migrating to GCP or Azure would mean rebuilding the entire streaming and serving layer. For a company that processes over $120 billion in annual payment volume through this pipeline, that's not a migration anyone is planning.

The 40-model problem

Running 40 or more ML models in production creates its own set of challenges that have nothing to do with model accuracy.

Each model needs features. Some features are shared, a customer's 30-day transaction average is useful to the card authorization model and the ACH scoring model. But each model also has unique features. Managing the dependency graph between models and features at Chime's scale is why MLKit exists.

MLKit abstracts model deployment into configuration. A fraud analyst who wants to test a new model against 5% of live traffic changes a config value. The framework handles canary deployment, metric collection, and automated rollback if error rates spike. Without this layer, deploying 40 models would require 40 deployment pipelines with 40 on-call rotations.

If the card authorization model tightens its threshold and declines more transactions, the ACH scoring model sees a different distribution of customers, because the riskiest card users are now being filtered upstream. The models are coupled through the customer population they share, even though they run independently. Chime's engineering blog doesn't describe how they handle this, but at 40 models the interaction effects are unavoidable.

What the architecture reveals

Chime's fraud system has a few properties worth noting for engineers building similar systems.

DynamoDB serves features to every model and every team, making the feature store the center of gravity. Replacing a model is a config change, but replacing the feature store would mean rebuilding the entire pipeline. The investment in feature infrastructure pays off when models are disposable but features are permanent.

The conventional wisdom in financial services is that latency-sensitive, high-throughput systems require dedicated infrastructure. Chime's pipeline processes over $120 billion in annual payment volume on fully managed services, and the trade-off is vendor dependency rather than performance.

Every feature Chime ships, from early direct deposit to instant transfers to fee-free overdraft, creates a new fraud vector. The fraud team needs to model the fraud implications of every product decision before it launches, not just respond to attacks after they arrive. At Chime, the fraud pipeline is as much a product constraint as a security layer.