Is Feast suitable for managing streaming features in high-frequency fraud detection?

All answers to this question.

For high-frequency fraud detection, Feast supports "Push Sources" that are perfect for this. You can have a Flink or Spark Streaming job process your Kafka messages and then "push" the aggregated features directly into the Feast online store. This updates the feature values with sub-second latency. For the offline store, Feast will eventually sync these pushes so you can use the same streaming data for future model retraining. It’s a very robust way to handle the "velocity" aspect of Big Data without having to build a custom database for every new fraud feature your data scientists dream up.

   Answered 2025-01-17 by Shannon Montgomery

Do you find that managing the TTL (Time To Live) for these high-velocity features in the online store requires a lot of manual tuning?

   Answered 2025-01-18 by Derek Fisher

• It does require some attention, Derek. If you set the TTL too short, your models might get "null" values for infrequent users. If it's too long, you're paying for storage of stale data. We generally set a TTL based on the specific feature—for example, "login attempts" might only be relevant for 30 minutes, whereas "average monthly spend" can stay for weeks. Feast makes it easy to set these at the "Feature View" level, so you can have different expiration policies for different types of behavioral data within the same system.

     Commented 2025-01-19 by Marcus Thorne

Using Feast for streaming ensures that your real-time features are properly logged for backtesting, which is usually a nightmare to do manually.

   Answered 2025-01-20 by Christina Lowe

• Exactly, Christina. Being able to "replay" the stream for training is the secret sauce for improving fraud models over time.

     Commented 2025-01-20 by Kimberly Dawson