Use Case: Fraud Detection

Fraud scores based on the latest transaction, not last night

Batch jobs calculate velocity features nightly. Feldera updates them continuously, within milliseconds of every new payment event.

Build a fraud pipeline Read the walkthrough

The problem

Fraudsters exploit batch windows

Velocity features such as "transactions in the last hour" and "unique merchants in the last day" rank among the strongest payment fraud signals. They depend on recent history.

If features are calculated overnight, a card can complete dozens of fraudulent transactions before the model reflects them. It scores against state already 8 to 20 hours old.

The problem is feature freshness, not model quality. With current inputs, the model would catch the pattern.

Batch pipeline timeline

00:00
Nightly batch compute starts
02:30
Features written to store
09:15
Fraud begins. Features 9h stale.
14:42
29 transactions approved. Features 14h stale.
24:00
Next batch starts over

The solution

Incremental velocity features in Feldera

Write feature logic in SQL. Feldera continuously updates results from your Kafka payment stream. No batch jobs or waiting windows.

sql 
-- fraud_features.sql

CREATE VIEW card_velocity AS
SELECT
  card_id,
  COUNT(*) AS txn_count_1h,
  SUM(amount) AS spend_1h,
  COUNT(DISTINCT merchant_id) AS unique_merchants_1h
FROM transactions
WHERE event_time > NOW() - INTERVAL '1 hour'
GROUP BY card_id;

CREATE VIEW merchant_category_freq AS
SELECT
  card_id,
  category,
  COUNT(*) AS category_txn_count_24h
FROM transactions
WHERE event_time > NOW() - INTERVAL '24 hours'
GROUP BY card_id, category;

CREATE VIEW device_fingerprint_freq AS
SELECT
  device_fingerprint,
  COUNT(DISTINCT card_id) AS cards_on_device_6h
FROM transactions
WHERE event_time > NOW() - INTERVAL '6 hours'
GROUP BY device_fingerprint;

Sub-100ms feature updates

A new Kafka transaction produces a queryable feature update in <100ms in internal benchmarks. The fraud model sees the velocity signal in the same decisioning window.

No full rescan

Feldera keeps delta state for each aggregation. A new transaction changes only its card's aggregation, not every input row. Compute cost stays constant as history grows.

"Before Feldera, our fraud model's velocity features updated overnight. We scored transactions against signals 8 to 14 hours old. Incremental features changed how we view scoring architecture. The signal is available during the decision, not the next morning."

Jordan M., ML Infrastructure Lead, payments technology company

Use the quickstart to connect your Kafka payment stream and define incremental velocity features in standard SQL. Run locally in under 10 minutes.

Get started

Build your first fraud feature pipeline

Incremental. Real-Time. Always Fresh. AI features computed incrementally from streaming data.

Start the quickstart Create free account