AI Fraud Detection: The Trade Off Nobody Puts in the Pitch

Fraud detection is presented as a technology problem with a technology answer. It is really a business decision wearing a technical costume, and the decision is this: how many genuine customers are you willing to block in order to stop one fraudster?

Every model has that dial. Nothing removes it. Teams that do not decide the setting deliberately end up with whatever the vendor shipped.

The trade off, concretely

Suppose ten thousand transactions a day and fifty are fraudulent.

• Aggressive setting: catches 45 of 50 frauds, and also blocks 300 genuine customers. You have prevented losses and created 300 angry people, some of whom will not come back.
• Conservative setting: catches 25 of 50, blocks 40 genuine customers. Lower friction, higher losses.

Which is correct depends entirely on your numbers: the average value of a fraudulent transaction, the lifetime value of a customer, and what a blocked customer does next. A lender and a food delivery business should not be at the same setting.

Do this calculation before evaluating any tool. It is the only way to judge whether a vendor’s accuracy claim means anything.

Rules first, models second

A well designed rule set catches a large share of fraud and has a property models lack: you can explain exactly why a transaction was blocked.

Rules worth having before any machine learning:

• Velocity checks: number of attempts per card, per device, per account in a time window
• Sudden change in transaction value against the account’s own history
• Multiple failed payment attempts followed by a success
• Shipping address differing from billing, combined with high value
• New account plus high value plus expedited delivery
• Device or IP appearing across many unrelated accounts

Models earn their place when the patterns are too subtle or too numerous for rules, and when you have enough labelled fraud to learn from. Not before.

What data you actually need

• Labelled outcomes. Confirmed fraud and confirmed legitimate. Most businesses have chargebacks recorded somewhere and never connected back to the transaction record. That connection is the prerequisite.
• Behaviour, not just the transaction. Time on page, typing pattern, navigation path, whether the card details were pasted or typed. Behavioural signals are often stronger than transaction attributes.
• Device and session data. Device fingerprint, IP, whether the connection is a known proxy.
• History per account and per device, not just the current event.

A model trained only on amount, time and location will underperform a decent rule set.

The Pakistan specific picture

• Cash on delivery fraud is the dominant pattern in local ecommerce, and it is not card fraud. Fake orders, refused deliveries, and address abuse. The signals are different: order patterns, address history, previous refusals. Most imported fraud tools do not model this at all.
• Wallet and mobile money flows have their own patterns, including account takeover through social engineering rather than technical compromise.
• Shared devices and shared connections are common, so device based rules that assume one person per device produce false positives here.
• Regulatory expectations for financial institutions around monitoring and reporting apply and should be confirmed with your compliance team rather than assumed.

How to deploy without damaging the business

1. Run in shadow mode first. Score every transaction, block nothing, for at least a month. Compare what it would have blocked against what actually turned out to be fraud. This is the only honest way to see the false positive rate.
2. Add a middle option. Not every flagged transaction should be blocked. A step up verification, an OTP, a callback, or a manual review queue converts many false positives into completed sales.
3. Start conservative and tighten. Blocking too many customers in week one damages trust you then spend months rebuilding.
4. Keep a manual review queue with a target response time. A flagged high value customer waiting two days is a lost customer.
5. Make every decision explainable. When a customer asks why they were blocked, someone needs an answer better than the model said so.
6. Monitor drift. Fraud patterns change deliberately in response to your controls. A model that is not retrained degrades faster than most.

What it costs

• Rules engine within your existing platform: 400,000 to 1,200,000 PKR to build properly.
• Third party fraud service: usually per transaction, which scales with volume and is the sensible starting point for most.
• Custom model with your own data: 2,000,000 and upward, plus ongoing retraining, and only worth it at genuine volume with labelled history.

Related reading: payment gateway integration and what running an AI feature costs.

Frequently asked questions

Do we need machine learning for fraud detection?

Not at first. A good rule set plus velocity checks handles a large share of fraud and is explainable. Models add value once you have volume and labelled outcomes.

How do we measure whether it is working?

Three numbers together: fraud losses, false positive rate, and the revenue from transactions you blocked incorrectly. Any one of them alone can be improved by making the others worse.

What about cash on delivery fraud?

Largely a different problem needing different signals: order and address history, previous refusals, and delivery outcomes. Most international tools do not cover it, so this is usually built locally.

How long does it take to see results?

A month of shadow running before you turn anything on, then measurable reduction within the following quarter. Anyone promising immediate results has not run it in shadow mode.

Ezitech builds risk, payment and AI systems for fintech and ecommerce clients across 42 countries. See our AI solutions or tell us what your fraud is costing.