---
title: "Tutorial: Stream fraud velocity features with Feast"
description: "Push fresh fraud velocity features to Aerospike with Feast PushSource and store.push(), then serve them through a FeatureService."
---

# Tutorial: Stream fraud velocity features with Feast

> For the complete documentation index see: [llms.txt](https://aerospike.com/docs/llms.txt)
> 
> All documentation pages available in markdown.

::: note
Developers building real-time fraud or risk scoring pipelines with Feast and Aerospike.
:::
::: undefined
This tutorial should take between 30 and 45 minutes.
:::

## Objectives

By the end of this tutorial, you will be able to:

-   Define velocity features on a `PushSource` and write fresh values to Aerospike with `store.push()`.
-   Identify the freshness responsibility and boundary of a push-based feature pipeline.
-   Configure Aerospike record TTL, then read pushed values and inspect their event timestamps.

## Introduction

Imagine a payment app with fraud protection. On the backend, a fraud detection model runs whenever a customer starts a transaction. It has to return an approve or decline decision fast enough to keep checkout smooth. To evaluate the transaction, the model needs recent history for the account behind it:

-   How many transactions did this account place in the last five minutes?
-   How much was spent across those transactions?
-   How many distinct merchants were involved?

Those values change continuously as new transactions arrive, so the model needs an answer that is both current and available in a single fast read.

The feature values the model needs are called _velocity features_: rolling aggregates that capture recent behavior. Two approaches fall short, for different reasons:

-   On-the-fly aggregation: The model reads the account’s recent transactions and aggregates them while scoring. That work lands inside the request and can exceed the latency budget.
-   Scheduled batch materialization: A job recomputes the aggregates on a fixed interval and loads the results into the online store. Scoring stays fast, but a five-minute window recomputed hourly is stale for most of the hour.

Both point at the same fix, and the difference is cadence rather than architecture: compute the aggregates outside the request, but do it continuously instead of on a schedule. [Feast](https://feast.dev/) models this with a `PushSource`. A background process consumes transactions as they arrive, maintains the rolling windows, and calls `store.push()` to write each new value into Aerospike. The fraud model reads the stored value with `get_online_features()` at scoring time and performs no aggregation of its own.

**Why push pre-computed values:** The tradeoff is that freshness now depends on that background process. If it stalls, Feast keeps returning the last value written. Push cadence, event-timestamp monitoring, and Aerospike record time to live (TTL) bound how old a served value can become.

In this tutorial, you push one velocity snapshot manually. It does not run a transaction consumer or maintain rolling windows.

## Key terms

| Term | Meaning |
| :-- | :-- |
| Velocity features | Rolling aggregates that capture recent account behavior, such as transaction count and spend in the last five minutes. |
| Rolling window | A time-based sliding aggregate that updates continuously as new events arrive. |
| Velocity snapshot | The latest velocity feature values for one entity at a point in time, written to Aerospike with `store.push()`. |
| `PushSource` | Feast data source for features written through `store.push()`. |
| `store.push()` | API that writes feature values to the online store (and optionally offline). |
| `feast apply` | Command that reads your project’s Python definitions and registers the entities, feature views, and feature services in the Feast registry. |
| `FeatureService` | Named bundle of feature views your model requests together. |
| `ttl_seconds` | Online-store time to live (TTL) stamped on Aerospike records at write time. |

## When to use this pattern

Use this tutorial when your model needs features that reflect events from the last few minutes and you have, or plan to build, a process that computes those values before scoring.

If the Aerospike online store layout is unfamiliar, start with [Tutorial: Serve real-time Feast features with Aerospike](https://aerospike.com/docs/develop/feast-aerospike-online-store). If you need velocity features on a dedicated memory namespace, see the [tiering tutorial](https://aerospike.com/docs/develop/feast-aerospike-tiering) after this one.

## What you do

-   Define a push-backed feature view and register it with `feast apply`.
-   Push a velocity snapshot manually and read it back through the Python SDK.
-   Fetch features over HTTP using `feast serve`.

The wrap-up explains how to connect a stream job after the demo works.

On the next page, you install Feast and Aerospike locally.

::: undefined
-   I understand the benefit, freshness responsibility, and demo boundary of push-based velocity features.
:::

[Next  
Prerequisites](https://aerospike.com/docs/develop/feast-aerospike-fraud-velocity/step/1/part/0/prerequisites)