Payments come from:
Live transactions times are simulated
Waiting for transactions…
Select a transaction to see exactly why it was scored the way it was.
Where it's happening last few seconds
Money, cumulative simulation truth
Detection by attack type simulation truth
Is traffic still what the model was trained on? checking
Collecting traffic…
Needs a decision
Payments the engine challenged or declined that nobody has confirmed yet. Your answer feeds the engine and the audit log.
Loading…
Pick a payment to review it.
Try it on your own data
Replay a CSV of past payments through the engine and see what it would have caught, what it would have cost good customers, and why. Nothing live is touched.
File format
Any common CSV works: column names are matched automatically (sender_id, amount_inr, timestamp, fraud_flag ...) and a note lists what was guessed. The canonical names are:
Required: ts, uid, amt, chan, mid and a location: city or lat, lon.
ts is epoch seconds or ISO-8601 (no zone means IST). chan is upi, ecom, pos, atm or imps. mid is the payee or merchant.
Optional: cat, dev, ip, pers, coll, rat, sim, and label: 0 good, 1 fraud the customer did not make, 2 fraud the customer was tricked into. With labels you get catch rates and money saved.
History matters. Give at least a month: the engine judges each payment against that customer's past, so a short file overstates friction.
Required: ts, uid, amt, chan, mid and a location: city or lat, lon.
ts is epoch seconds or ISO-8601 (no zone means IST). chan is upi, ecom, pos, atm or imps. mid is the payee or merchant.
Optional: cat, dev, ip, pers, coll, rat, sim, and label: 0 good, 1 fraud the customer did not make, 2 fraud the customer was tricked into. With labels you get catch rates and money saved.
History matters. Give at least a month: the engine judges each payment against that customer's past, so a short file overstates friction.
Run the sample to see the report.
The engine attacks itself
An automated fraudster tries thousands of strategies against copies of real customers' history: how many payments, how much, to whom, from which device and network, at what hour, whether the customer is tricked into approving a challenge. The production engine decides every payment. Whatever slips through is the engine's blind spot.
What this does not prove
The attacker only has the levers listed in the table: a fixed menu, not a creative human. It attacks a simulator, and counts a challenge as letting through 8% of ordinary fraud and 50% of fraud the customer is tricked into. A clean result means these holes are closed, not that none remain.
Run it to see what the attacker finds.
Real public datasets
Loading…
How to read this tab
Everything on this tab uses real public data, not the simulator. Files are fetched from their original public sources onto the server, or you can upload your own copy. Nothing is stored in the repository. The card-fraud data has no customer, device or payee ids (they were anonymised), so it tests the model, not the behavioural engine. Full caveats: docs/BENCHMARKS.md.
1. Real card fraud: fit the model and test it
2. Replay real card transactions through that model
3. Scam Shield on real text messages
Check before you pay
Paste a message, a UPI handle, a QR link (upi://pay?...) or a web link. Nothing leaves your browser in the demo; on the live server the text is checked and not stored.
Or try a real message, with its true label:
What this can and cannot do
It reads wording and structure against known Indian scam patterns (OTP and PIN requests, screen-sharing apps, electricity-bill threats, fake KYC, 'digital arrest', look-alike payment handles, bad links). On the live server it also asks the risk engine whether the payee has many first-time senders or fraud complaints. It cannot tell who owns a payment handle, so it never says "safe".
Pick an example or paste something, then press Check.
Suspected mule hubs
Loading…
Share with other banks
Network
Connections
Loading…
Send a Razorpay-shaped payment
Point Razorpay at this
Dashboard → Settings → Webhooks → add , tick payment.authorized, payment.captured, payment.failed, copy the secret into the server's RAZORPAY_WEBHOOK_SECRET. Use test mode. Pass notes.ip, notes.device_id, notes.city at checkout for the strongest signals. Requests are accepted only with a valid HMAC signature. Phone numbers and emails are hashed before they reach the engine.
Latest decisions from the wire
No webhook payments yet. Send one on the left.
Engine speed
Business costs
Compose a transaction
Dry run: nothing is remembered.
Try a scenario
Score a transaction to see the decision and its explanation.