Fraud teams report what they prevented. What they rarely report, because it is invisible, is what they blocked that was legitimate — the customer whose card was declined, who tried once more, and then bought somewhere else. For most Indian merchants the cost of false positives exceeds the cost of the fraud, and a fraud system that is not measuring both numbers is optimising half the problem.
So start by measuring both. Fraud rate as a share of transactions and of value; false positive rate estimated from the customers who were blocked and subsequently completed a successful purchase, or who contacted support to complain. That second number is imperfect and it is far better than not having it, because it converts the discussion from how much fraud did we stop into what did the whole system cost us.
Build rules before models. A small set of deterministic rules — velocity limits per card, per device and per address, mismatches between billing and delivery geography, a first-time high-value order to a new address, an unusual number of failed attempts before a success — catches a large share of ordinary fraud, is explainable to a support agent, and can be changed in minutes when a new pattern appears. A model is worth adding when the rules are saturating, not before.
The most useful design decision is to have more than two outcomes. Approve and decline is a blunt system. A middle path — step up the authentication, hold for review, allow but flag for post-delivery checks, permit but restrict the payment method — lets you handle the large ambiguous middle without either losing the sale or accepting the risk. In Indian e-commerce, where cash on delivery introduces its own fraud shapes, that middle band is where most of the value is.
Watch the patterns specific to this market rather than importing a foreign rule set. Cash on delivery abuse, where orders are placed with no intention to accept, costs logistics rather than payment. Return fraud on high-value electronics. Coupon and referral abuse at scale, which is not usually classified as fraud and is often the largest leak in a growth-stage business. Address manipulation to trigger free delivery. None of these appear in a card-fraud model trained elsewhere.
Finally, give your support team the reason. When a transaction is blocked, an agent who can see which rule fired and why can resolve a genuine customer's problem in one call and let them through. An agent who sees only that the system declined it can do nothing except apologise, and the customer leaves. That transparency is cheap to build, it is the single largest improvement to the false positive cost, and it is almost always missing.
