Section 1
What real-time actually demands
Real-time means the decision fits inside a checkout, which leaves a budget measured in tens or low hundreds of milliseconds, including everything the system needs to look up. That constraint shapes the design more than model choice. Features must be available instantly, which means precomputed and stored, not calculated on demand across a history table. Velocity checks, how many attempts from this card in an hour, how many accounts from this device today, are cheap and effective because they can be maintained incrementally. Not every decision needs to be real-time. Split it. Block clear cases synchronously, hold ambiguous ones for review within minutes, and run deeper analysis nightly. Doing everything in the checkout is how teams end up with a slow site and a mediocre model. Scoping that split before building is the approach in [AI Automation in Product Development: From Idea to Launch](/blog/ai-automation-in-product-development-from-idea-to-launch).
Section 2
Rules and models are not alternatives
Rules are explicit, instant, and explainable. Never accept this card country with that shipping country. Block a fourth attempt from the same device in ten minutes. They handle known patterns and give you something to point at when a customer asks why. Models catch combinations nobody wrote down, where each individual signal is unremarkable and the pattern is not. Use both, and know what each is for. Rules are your fast response when a new attack appears at two in the morning, because you can deploy one immediately. Models are your standing defence. Models alone react slowly; rules alone accumulate into hundreds nobody dares delete. The structured-extraction discipline behind good feature data is described in [Using AI to Analyze Customer Feedback at Scale](/blog/using-ai-to-analyze-customer-feedback-at-scale).
Section 3
Your labels arrive late and incomplete
This is the problem specific to fraud, and it invalidates a lot of otherwise sensible modelling. A chargeback can arrive months after the transaction, so today's model is being judged on last quarter's outcomes. Worse, the transactions you declined have no outcome at all. You never learn whether they were fraudulent, so the model retrains on the population it already filtered, and its blind spots harden. Two practical mitigations. Let a small random sample through the block rules, accepting the loss, to keep learning what you are declining. And use faster proxies alongside chargebacks: customer complaints, refund requests, delivery failures, account takeover reports. They are noisier and they arrive in days rather than months.
Section 4
The adversary adapts, so the model decays
Fraud is the one automation domain with an opponent who studies your defences. When a pattern stops working they change it, so performance decays for reasons unrelated to your data pipeline. Plan for retraining as an operating routine rather than a project. Monitor the score distribution weekly, since a shift there is the earliest warning that something changed. Watch approval rate and fraud rate together, because a drop in caught fraud can mean the attack stopped or that you stopped seeing it. Build for fast deployment of a new rule. When a novel pattern appears, the useful capability is not a better model. It is shipping a targeted rule within the hour and retiring it once the model has learned the pattern.
Section 5
Declines are decisions about people
An automated decline is a consequential decision made about a customer by a system, and in many jurisdictions it comes with obligations: an explanation, a route to challenge it, and a record of how the decision was made. Build for that from the start. Log the inputs and the reason for every decline, in a form a human can read months later. Give front-line staff a way to see why a customer was blocked and the authority to override, with the override recorded. Watch for uneven impact across regions, payment methods, or customer groups. A model trained on historical outcomes can encode historical bias, and a decline rate that differs sharply by geography is worth investigating even when no protected characteristic is in the data. Someone senior should own this review, not the vendor.
Section 6
Count both errors, in money
The dashboard that shows only fraud prevented is the one that lets a system quietly strangle revenue. Track fraud loss and false decline cost side by side, both in currency. Estimate the second from declined transactions that customers later completed, from complaint volume, and from the lifetime value of accounts that stopped ordering after a block. Add manual review volume and cost per case, and the review queue's own accuracy. The decisive number is total cost of fraud: losses, plus declined good revenue, plus review labour, plus chargeback fees. Optimise that one figure. Presenting it convincingly, so a board understands why the fraud rate rose on purpose, is the work described in [Using AI and Data Analytics to Enhance Storytelling](/blog/using-ai-and-data-analytics-to-enhance-storytelling).