Stop fraud without stopping customers.
A no-code simulator that lets risk teams back-test fraud rules on last month’s payments before they go live, so every rule change shows its trade-off between fraud caught and good customers blocked.
Built with simulated data for a fictional payments company, Kavach Pay. No real customer data is used.
Fraud teams are flying blind, and good customers pay for it.
Digital payments in India have grown quickly, and fraud has grown with them. Most mid-size payment companies still defend themselves with hard-coded “if-this-then-block” rules. Nobody can test those rules before they ship, and nobody measures them after.
Good customers get blocked
Blunt rules like “block anything above ₹25,000” or “block all international” decline genuine customers. Industry research widely reports that false declines cost merchants more than fraud itself, and many customers who are declined never come back.
Rule changes take weeks
Every tweak is a Jira ticket for engineering. During a fraud attack, the risk team waits 2–3 weeks for a threshold change, then switches on a blanket block that hurts conversion.
No one knows which rules work
Rules pile up over years. No one can answer “what does this rule actually catch, and how many good users does it hit?” So rules are never retired, and the noise keeps growing.
“When fraud spikes I can only turn rules on or off and hope. I find out whether I over-blocked when the merchant escalates, or when chargebacks arrive 45 days later.”
How might we let risk teams design, test and safely ship fraud rules on their own, so they catch more fraud while blocking fewer genuine customers, and can measure the trade-off before going live?
Too loose → fraud losses
- Stolen money + chargeback fees
- Scheme penalties for high chargeback ratios
- Regulatory & reputational risk
Too tight → false declines
- Lost sales and merchant revenue
- Customers churn to competitors
- Overloaded manual-review teams
Turn fraud rules into a product decision you can measure.
I treated rule management as a product problem: understand the users, size the cost of each mistake, then design a tool that makes the trade-off visible.
Discover
Mapped the jobs-to-be-done of risk analysts, risk leads and merchant success. The top need is to change a rule with confidence, quickly.
Diagnose
Audited the legacy rule set against labelled history. Single-signal hard blocks were the main cause of false declines, and they missed fraud that combines several weak signals.
Design
Replaced “any rule blocks” with a points-based risk score and three outcomes: allow · review · block. Each rule adds evidence, and no single rule decides on its own.
Validate
Every change is back-tested on 30 days of labelled payments and priced in rupees: fraud loss + false-decline cost + review cost.
Fraud rarely looks like one strong signal. It looks like several weak signals together: a new device, plus failed OTPs, plus a first payment to a new payee. Hard blocks on single signals are noisy. Combining signals into a score is precise.
Success metric (North Star)
Total cost of fraud (₹) = fraud losses + false-decline cost + review cost. One number, so teams stop optimising only one side.
Guardrails
False-decline rate < 1% · Review queue within analyst capacity · Fraud caught ≥ legacy for every fraud type.
Non-goals (v1)
Real-time ML models, case management, and live production deployment. v1 proves the value of simulation first.
The playground: change a rule, see the impact instantly.
Every change is re-scored live against 10,000 simulated payments from September 2026 (– confirmed fraud). Start from a preset, then adjust toggles, thresholds and weights.
More fraud caught, far fewer good customers blocked.
Legacy rules vs the tuned risk score, back-tested on the same month of payments. The prototype computes these numbers live; they are not hard-coded.
What worked
- Behaviour beats size. Velocity and failed-OTP signals have far higher lift than “high amount”, which mostly fires on genuine big-ticket buyers.
- A review band is cheap insurance. About 13 reviews a day absorbs uncertain cases instead of hard-blocking them.
- One cost metric aligns teams. Risk and growth argue about the same rupee number, not competing KPIs.
What rules still can’t do (honest limits)
- Social-engineering scams look like genuine payments made by the real user on their own device. Rules catch only about 60%; this needs payee-risk intelligence and in-app warnings.
- Synthetic accounts need identity and consortium signals beyond transaction data.
- Labels arrive late: chargebacks land 30–90 days after the payment, so back-tests run on matured data.
Roadmap
Shadow mode
Run a new rule on live traffic and log its decisions without acting on them, before it goes live.
Champion / challenger
Send 5% of traffic to a candidate rule set and compare it with the current one on live outcomes.
Step-up instead of block
Ask for extra authentication (OTP or biometric) in the uncertain band instead of declining.
ML score as a signal
Feed an ML model’s probability in as one more weighted signal, so rules stay explainable.