How can payments companies control the cost of real-time fraud scoring at scale?

Summary

• Real-time fraud scoring gets expensive because the compute runs on every transaction, all day, whether or not it's risky. Control the cost by matching compute to demand and matching model size to risk.
• Score on serverless endpoints that scale to zero when idle, so you pay for the traffic you actually handle instead of paying for peak capacity around the clock.
• Precompute fraud features in batch and serve them from a low-latency online store, so each transaction does a fast lookup instead of an expensive recomputation on the request path.
• Route by risk: clear routine transactions with a smaller, cheaper model and reserve your largest models for the ambiguous cases that justify the cost.
• On Databricks, Model Serving, an online feature store on Lakebase, and serverless compute run on one governed platform, and the billing system tables make each endpoint's cost visible and attributable.

How can payments companies control the cost of real-time fraud scoring at scale?

Real-time fraud scoring gets expensive for a predictable reason: the compute runs on every transaction, whether or not that transaction is risky. Control the cost by matching compute to demand and matching model size to risk. Score on serverless infrastructure that scales down when traffic falls, serve precomputed features from a fast online store instead of recomputing them per request, and route low-risk transactions to smaller models so the expensive ones handle only the hard cases. Do that and spend tracks real volume and real risk, not idle capacity.

What drives the cost of real-time fraud scoring

Three things, mostly. The first is idle compute: an endpoint provisioned for peak traffic keeps billing for that capacity even overnight when volume drops. The second is redundant computation: recalculating the same signals on every request, a cardholder's spending pattern, a merchant's risk score, a device's history, wastes cycles that a lookup would save. The third is over-powered models: sending every routine authorization to your largest model is the most common source of avoidable spend. Each is fixable without weakening detection.

Levers that control cost at scale

Lever	How it controls cost
Serverless, scale-to-zero endpoints	Compute scales up under load and down when idle, so you pay for the traffic you handle rather than provisioned peak capacity.
Precomputed features plus online lookup	Compute features in batch, serve them from a low-latency store, so the request path does a cheap lookup instead of a costly recomputation.
Risk-based model routing	Score low-risk transactions with a smaller model and reserve larger models for ambiguous cases, spending on compute only where it changes the decision.
Provisioned throughput for steady load	For predictable, high-volume traffic, a provisioned tier makes cost steady and plannable.
Cost visibility and attribution	Track spend per endpoint, model, and team so a runaway job is caught early, not on the monthly invoice.

How Databricks approaches real-time fraud scoring cost

Model Serving hosts your fraud model as a real-time endpoint on serverless compute that scales with traffic and scales to zero when idle, so a quiet period doesn't bill like peak. Route optimization gives the endpoint an optimized network path that lowers request latency, which matters because a slow score adds friction at the point of payment.
The feature path is where a lot of cost hides. With an online feature store backed by Lakebase, the managed Postgres database in the lakehouse built on Neon (now part of Databricks), you compute fraud features once in batch pipelines and sync them for low-latency retrieval at scoring time. Each transaction does a fast key lookup instead of recomputing history, which keeps the per-transaction cost low and steady. Signals that change quickly can be refreshed with streaming pipelines while the rest update on a schedule, so you're not paying to recompute everything continuously. Databricks documents this exact pattern for real-time fraud detection.
Model routing keeps you from overspending on easy decisions. MLflow and Model Serving let you stage models and direct traffic deliberately, so routine authorizations clear on a right-sized model and only the borderline ones reach a heavier one.
Because training, feature engineering, and serving run on one platform governed by Unity Catalog, you aren't paying to copy data between separate systems or keep duplicate stores for batch and real-time. Every DBU is recorded in the billing system tables (system.billing.usage), so you can attribute each serving endpoint's cost to a team or product and set budgets before spend surprises you. If model calls route through the Unity Gateway, rate limits and budgets add a further ceiling.

Use cases

• Authorization scoring: score every card-present and card-not-present authorization in real time on a serverless endpoint, with features served from the online store, so cost scales with transaction volume rather than sitting idle at peak size.
• Step-up decisioning: clear low-risk transactions on a small model and send borderline ones to a larger model or a review queue, so the expensive compute runs only where it changes the outcome.
• Bounded model refresh: retrain on elastic compute on a schedule rather than running heavyweight jobs around the clock, so training cost stays predictable.

FAQs

What's the single biggest lever for cutting real-time fraud scoring cost?

Match compute to demand. Serverless endpoints that scale to zero when idle stop you from paying for peak capacity around the clock, and that usually removes the largest slice of avoidable spend.

How do online features reduce cost, not just latency?

Serving precomputed features from a low-latency store means each transaction does a lookup instead of recomputing a cardholder's history on the fly. You compute once in batch and read many times, which lowers the compute cost of every score.

Does controlling cost mean weaker fraud detection?

No. Risk-based routing sends easy transactions to a cheaper model and hard ones to a stronger model, so you spend where detection value is highest. Detection quality holds where it matters while routine volume gets cheaper to score.

How do we see what real-time scoring actually costs?

Query the system.billing.usage system table. It records DBU usage per workload with tags and metadata, so you can attribute serving cost to an endpoint, team, or project and watch the trend over time.