Real-time fraud scoring on AWS that scales with the traffic spikes

[A Series-B fintech] · AI/ML · MLOps · Cloud · AWS

Real-time fraud scoring on AWS that scales with the traffic spikes

Context

A Series-B fintech processing a growing volume of transactions needed to score each one for fraud risk in real time, in the payment path. Their business was scaling fast and unevenly — traffic spiked hard around paydays, promotions, and time-of-day peaks. They needed fraud scoring that kept up with those spikes without either falling over or being permanently over-provisioned for the peak.

Challenge

Two pressures pulled against each other. Scoring had to happen inside the transaction flow, so latency had a hard budget — a slow fraud check is a slow checkout, and that costs real money. At the same time, fraud patterns shift continuously, so a model trained once and left alone decays: fraudsters adapt, and stale models either miss new patterns or start flagging legitimate customers. The existing setup also produced too many false positives, and every false positive is a real customer blocked and a support ticket opened.

The client was already committed to AWS and wanted to stay there — the goal was to build this properly on the platform they ran, with elasticity for the spikes and an automated path to keep the model fresh.

Approach

We scoped this as a streaming-inference problem with an MLOps loop wrapped around it, not a one-off model. The model is the easy part; keeping it fast under spikes and keeping it current under drift is the engagement.

For latency, we designed the scoring service to auto-scale with traffic so the p95 stayed within budget during spikes without paying for peak capacity around the clock. For accuracy, we focused specifically on the false-positive problem, because that was the pain the business actually felt — tuning the model and decision threshold to cut false positives while holding fraud-catch performance.

The piece that made it durable was automating retraining. Rather than a human remembering to retrain when performance slipped, we built a weekly automated retraining loop on fresh labeled data, with evaluation gates so a worse model couldn't silently get promoted into the payment path.

Architecture

The system runs on AWS, using managed services so the client's team wasn't maintaining undifferentiated infrastructure.

• Model training and serving: built on Amazon SageMaker, with model endpoints serving real-time scores.
• Streaming ingestion: transaction events flow through a streaming layer that feeds the scoring service in real time, so a score is available within the transaction's latency budget.
• Auto-scaling: the scoring endpoints scale with incoming traffic, absorbing spikes and scaling back down afterward — elasticity is the reason this lives in the cloud rather than on fixed hardware.
• Automated retraining loop: a scheduled pipeline retrains on fresh labeled data weekly, evaluates the candidate against held-out data and the current production model, and only promotes it if it clears the gates. This is the MLOps backbone that keeps the model from decaying.
• Monitoring: scoring latency, model performance, and data drift are tracked so degradation is visible before it becomes a business problem.

This is the deliberate counterpart to an on-prem deployment: when the defining requirement is elastic scale against spiky traffic, the cloud's elasticity is the right answer, and we built to use it well.

Results

• p95 scoring latency under ~100ms, held during traffic spikes via auto-scaling.
• False positives down ~25% — measurably fewer legitimate customers blocked.
• Automated weekly retraining with evaluation gates, so the model stays current without manual intervention and a worse model can't reach production.
• Elastic cost profile: capacity follows traffic instead of being provisioned for the permanent peak.

Stack

Amazon SageMaker · AWS streaming ingestion · auto-scaling real-time endpoints · automated retraining pipeline with evaluation gates · drift and latency monitoring · AWS cloud infrastructure.

---

When the defining requirement is elastic scale, the cloud is the right tool — and using it well is its own discipline. See how we build and operate cloud ML →, or read the on-prem clinical case for when the answer is the opposite.