Fraud detection at the transaction layer is primarily a feature freshness issue, not a model architecture issue. A gradient-boosted tree trained on stale velocity features is not inherently worse than one trained on fresh features. It receives different input. If a card's velocity feature is four hours old during inference, the model scores risk from behavior four hours earlier rather than from the last fifteen minutes, when the fraudulent pattern is unfolding.
The failure occurs when velocity-based fraud stays below an individual transaction threshold but exceeds an aggregate pattern threshold. A card making six transactions in fifteen minutes, each below the individual limit, could be involved in account takeover or card testing. If the pipeline refreshes the 15-minute velocity count every four hours, the model sees zero velocity during the attack's first four hours. It cannot detect a pattern that is not visible.
What the feature pipeline must compute
A production fraud feature set for card-not-present transactions generally has three feature classes: card-level velocity over several windows (15 minutes, 1 hour, 24 hours), card-level merchant category exposure (the merchant categories where the card recently transacted), and cross-entity signals (whether this merchant currently has elevated decline rates or chargeback velocity).
Each class depends on aggregations over recent transaction history. The windows are short enough that hourly batch pipelines cannot refresh them often enough. Cross-entity signals are particularly time-sensitive: a sudden increase in declines at one merchant must reach the fraud model within minutes, not hours.
-- Card velocity across multiple windows
CREATE MATERIALIZED VIEW card_velocity_features AS
SELECT
card_id,
COUNT(*) FILTER (WHERE ts >= NOW() - INTERVAL '15 minutes') AS txn_count_15m,
COUNT(*) FILTER (WHERE ts >= NOW() - INTERVAL '1 hour') AS txn_count_1h,
COUNT(DISTINCT merchant_id) FILTER (
WHERE ts >= NOW() - INTERVAL '1 hour'
) AS unique_merchants_1h,
SUM(amount) FILTER (WHERE ts >= NOW() - INTERVAL '24 hours') AS total_amount_24h
FROM transactions
GROUP BY card_id;
-- Merchant-level decline signal
CREATE MATERIALIZED VIEW merchant_decline_rate AS
SELECT
merchant_id,
COUNT(*) FILTER (WHERE status = 'declined') AS declines_1h,
COUNT(*) AS attempts_1h,
ROUND(
100.0 * COUNT(*) FILTER (WHERE status = 'declined') /
NULLIF(COUNT(*), 0), 2
) AS decline_rate_pct
FROM transactions
WHERE ts >= NOW() - INTERVAL '1 hour'
GROUP BY merchant_id;Feldera continuously maintains both views. Each new transaction event immediately updates that card's card-level velocity counts. Each decline event updates the merchant-level decline rate. Downstream consumers reading the feature store receive post-update values within the pipeline's propagation latency, rather than waiting for the next scheduled batch job.
The end-to-end pipeline architecture
A production fraud feature pipeline built with Feldera has four stages. The transaction processing system writes authorization and decline events to a Kafka topic. Feldera subscribes as a streaming input, applies incremental view maintenance, and produces updated rows in materialized views for entities affected by each event. Feldera's sink connector writes those rows to the online feature store, Redis or another low-latency key-value store. At inference time, the fraud scoring model reads the feature store using the evaluated transaction's entity keys.
Latency from Kafka event arrival to feature availability in Redis varies with pipeline configuration and infrastructure sizing. In internal benchmarks using a single-node Feldera deployment with a co-located Redis instance, simple aggregation views complete end-to-end in under 200 milliseconds. Pipelines with JOIN operations across multiple source tables take 500-800 milliseconds, depending on join fanout. Both timings suit fraud detection: scoring uses features reflecting events from the last second or two, rather than from an hour earlier.
Bootstrapping the initial state
Starting an incremental pipeline requires more than connecting it to a live Kafka topic. Materialized views must first be populated with historical data. A cold-started pipeline has zero velocity counts, creating misleading features for entities with prior transaction history.
Bootstrap is a one-time batch load. Feldera reads a historical transactions-table snapshot, typically from Postgres or S3 and ending at a specified timestamp, computes the initial state of every view from the full history, and then switches to the live Kafka topic at the corresponding offset. Careful coordination prevents double-counting and gaps, while Feldera's checkpoint mechanism treats the transition as a standard pipeline initialization sequence.
Bootstrapping is the most operationally costly stage of deploying an incremental pipeline. With several years of transaction history and millions of cards, the initial load may take hours. After the pipeline goes live, steady-state cost is low. Bootstrap is a one-time investment and does not recur while the pipeline remains running. Following a failure, the checkpoint enables recovery from the last consistent state without repeating the full bootstrap.
What incremental pipelines cannot solve
The limits are important. Fresh incremental features are necessary but not sufficient for effective fraud detection. A model trained months ago on a distribution that has drifted will score poorly regardless of serving-feature freshness. Freshness reduces the serving-time delay between raw events and model inputs, but it does not resolve model staleness, feature relevance drift, or weak signal selection in the feature library.
Some fraud patterns depend on features that are inherently difficult to compute incrementally at low latency. Graph-based features involving relationships between entities, such as whether this card's address was associated with N other cards in the last week, require multi-hop joins that are difficult to maintain at high event rates. These can be powerful signals for organized fraud, but are usually computed on slower batch schedules and used alongside faster velocity features. For most production fraud pipelines, the appropriate architecture is hybrid: fast incremental processing for velocity and slower batch processing for graph features, rather than forcing every feature to run at sub-second latency. [CTA-H2] Build your first incremental pipeline today [CTA-PARA] Feldera is free to start. Connect your data source, write a SQL view, and watch features update in milliseconds as events arrive.