Live demo
Real-Time Transaction Fraud Monitor
A simulated week of card transactions streams past the same detection rules the project's Kafka detector runs. Each purchase is checked for bursts of rapid spending, amounts far above the card's normal, and purchases in two countries too far apart to travel between. The simulator plants fraud in the stream, so every alert can be checked against the truth.
Results for the full simulated week
Scoring the full simulated week…
Transaction stream
Newest first · last 80 shown
| Time | Card | Country | Merchant | Amount | Result |
|---|
This replay so far
Alerts
What the detector would publish to the alerts topic
- No alerts yet.
Alerts per 15 minutes of simulated time
Fills in as the replay plays
How the full pipeline works
This page runs the highlighted box
Each purchase is keyed by card number, so all of a card's purchases land on the same Kafka partition, in order. That lets each detector replica keep per-card history in memory. Offsets are committed only after alerts are written (at-least-once), and malformed messages go to a dead-letter topic.
This page can't run Kafka: Vercel functions are short-lived, and Kafka needs an always-on broker and consumers. So the detector's rule engine (app/rules.py) runs here on a stream simulated for your visit. The full Kafka pipeline runs against real Apache Kafka in CI on every commit, and the build fails unless its alerts match this engine's alerts exactly.
Kafka pipeline benchmark
Measured end to end through Kafka, from the README
| Planted fraud caught (206K txns, 1,500 incidents) | 96.9% |
| Alerts that were real fraud | 92.6% |
| Throughput, 3 detectors × 6 partitions | ~49K msg/s |
| End-to-end latency p95 at 5K msg/s | 61 ms |
| Malformed messages dead-lettered | 3 of 3 |
| Kafka alerts vs. offline engine | identical |
Throughput and latency were measured on a 2-vCPU VM against Tansu, a Kafka-compatible broker. On real Apache Kafka in GitHub Actions, p95 was 79 ms at full speed. Details