Pass Just an ID and Features Arrive Automatically: Snowflake's Real-Time Fraud Detection Inference Solution

A model that performs well in training underperforms once it's live. The problem often isn't the model itself but the features: the features used in training and the features fed to the model at inference time come from different code paths and data sources, and even a small discrepancy throws off predictions. This pitfall is called training-serving skew.

Snowflake has published an official quick-start tutorial (Build Real-Time ML Inference with Feature Store) showing how to wire up this whole path using the Online Feature Store together with an inference service. What you build is a real-time fraud detection system: an external client submits a transaction ID, the online model service automatically pulls features from the feature store, runs an XGBoost classifier, and returns a fraud prediction.

The full flow: the source table TRANSACTION_FEATURES is synced to the Postgres online feature store at a configured refresh frequency and target latency (10 seconds in the tutorial). An external client calls POST /predict with only a TRANSACTION_ID, SPCS Ingress routes the request to the online model service, the service fetches features from the feature store, runs XGBoost, and returns the prediction to the caller.

The key is the feature_sources_per_function parameter at deployment time. Map the predict method to a Feature View, and the service automatically gains feature lookup capability. Callers don't need to know which features the model depends on, and they don't need to assemble features in the request — they just pass the entity key. After the gateway intercepts the request, it retrieves features such as transaction amount, merchant category, distance from home, time since last transaction, and number of transactions today from the online feature store, then forwards the complete payload to the model container.

This design has two immediate benefits. First, a simpler feature contract: if the features the model depends on change, as long as the Feature View is still syncing, the API doesn't need to change and callers don't need to touch anything. Second, controllable feature freshness: with a 10-second target latency, the online store keeps up quickly after the source table is updated.

The technical foundation is Snowflake's Postgres-backed Online Feature Store, with the model service deployed on Snowpark Container Services. Authentication uses a Programmatic Access Token, so an external client can call it by curling the REST endpoint directly.

One detail: the Python SDK's mv.run() and SQL service functions don't go through the gateway, so they don't trigger feature enrichment. This capability is meant for external real-time inference clients — web apps, microservices, mobile backends, and similar scenarios.

The tutorial covers every step with code: preparing the environment, generating synthetic data, registering the Entity and Feature View, training XGBoost, registering the model, creating a compute pool, deploying the service, and calling the endpoint. Teams struggling with training-serving skew can follow along end to end.