How Jumio built a real-time feature store on AWS

Identity verification runs on speed. Jumio, which helps businesses spot fraud and verify who's really on the other end of a transaction, learned that the hard way when its machine learning models kept tripping over a fragmented feature pipeline. Different teams were running their own offline feature stores, redefining the same features in slightly different ways, then manually rewriting that logic in Java or Python for production. That's a recipe for bugs, mismatches, and wasted engineering hours, and it doesn't work when fraud detection needs answers in real time.

So Jumio built a streaming-first feature store on AWS, deployed across three regions — US East, Frankfurt, and Singapore. Events flow in through Amazon Kinesis Data Streams, get processed and enriched by Apache Flink applications, and land in Amazon SageMaker Feature Store for models to query during inference. A parallel batch path pushes events through Amazon Data Firehose into S3, where Amazon EMR handles heavier transformations and writes into Apache Iceberg tables for the offline store used in training and analysis.

The split between hot and cold data is where the cost savings live. Frequently accessed features sit in an in-memory layer built on Amazon ElastiCache for Valkey, which keeps reads fast and writes cheap. Everything else settles into SageMaker Feature Store's standard tier for durability at scale. Jumio also had to design around late-arriving events — some fraud-relevant data shows up minutes after an initial action, some weeks later after a review process — and the architecture accounts for that instead of treating every event as if it arrives on schedule.

The numbers back up the redesign. Jumio's 95th-percentile response time came in at 16.9 milliseconds, comfortably under the sub-100ms SLA fraud detection demands. Read latency sat at a P50 of 8.44 ms, write latency at 18.6 ms. And the tiered storage approach reportedly saved Jumio roughly $120,000 a year in operational costs compared to the old, scattered feature stores — without giving up any speed to get there.

What changed isn't just performance, it's process. Feature definitions are now centralized and reusable instead of duplicated across teams, and deployment is automated rather than something that used to take weeks by hand. Jumio frames this as a blueprint for any workload needing low-latency predictions, not just fraud scoring, and the write-up leans on five principles — streaming-first design, centralized definitions, tiered storage, active monitoring, and tight collaboration between backend, ML, and data teams — as the real takeaway for anyone trying to copy the approach.