Card Fraud: Six Purchases Approved on an Account Already on Hold
A card lender's fraud team puts an account on hold in time, and card authorization approves six purchases on it anyway. An identity check links a new application to account R1's device and the case system puts R1 on hold, but the hold goes out like any status change: Debezium reads it, Kafka carries it, and a Flink job writes it to the Redis cache authorization reads, which takes eight seconds. In that window a fraud ring's AI shopping agent makes six purchases four tenths of a second apart, and authorization approves $7,565 on an account already on hold. Then the same hold with the case system writing it to Tacnode, where authorization reads R1's status, so all six purchases are declined and every decline is written back as context for the next check.
Overview
A Decision Replay of card fraud, on camera with Alex Kimball: why a fraud hold decided in time still let six purchases through, and the same hold with current context.
Topics Covered
- •A new application from a device tied to an open account
- •The fraud team's hold, and the pipeline it travels through
- •A fraud ring's AI shopping agent making six purchases in two seconds
- •Why authorization reads a cache instead of the case system
- •The same hold written to Tacnode, where authorization reads it
Key Takeaways
- ✓The fraud team decided in time; authorization couldn't see it yet
- ✓A hold that rides change capture, Kafka and Flink arrives eight seconds after it was placed
- ✓Eight seconds was enough for an agent to spend $7,565 on an account on hold
- ✓When each decline is written back, the next check on that device or ring sees it
More Product Demos
Past-Posting in Live Betting: Why Sportsbooks Keep Taking Bets After a Goal
A 4-minute walkthrough of a sportsbook that keeps taking bets for seven seconds after a goal, and the same goal with current context.
Do You Actually Need a Separate Vector Database?
A 3-minute explainer on when a separate vector database earns its place, and what changes when similarity search has to agree with live filters and state.
Why ClickHouse JOINs Are Slow (and Why Denormalizing Isn't the Fix)
A 4-minute explainer on why ClickHouse JOINs are slow, what denormalizing costs, and what it looks like when joins stay first-class.
Ready to get started?
Book a demo to see how Tacnode can power your real-time data infrastructure.