Rethinking Risk in the Age of AI

I spent most of my career building fraud detection systems the old way: rules, thresholds, review queues. You'd write a rule, watch false positives pile up, tune it, repeat. Then someone on the data team would find a pattern you missed three months later.

AI flips that entirely. Not because it's magic, but because it can sit inside the transaction stream and adapt faster than any ruleset I've ever maintained.

What AI Actually Changes

The fundamental shift is moving from reactive to near-real-time detection. With rules, you can only catch what you've already seen and written a rule for. A model trained on transaction patterns can flag anomalies that don't match any existing rule: a purchase from a new device in a new location that still fits the user's spending profile otherwise, for example.

But there's a catch I didn't anticipate: models drift faster than rules. A rule either matches or it doesn't. A model's confidence thresholds shift as the data distribution changes. I've had models that performed great at deployment degrade noticeably within three months because fraud patterns evolved.

Where Rules Still Win

Not every fraud scenario benefits from ML. Simple velocity checks ("more than 5 transactions from this card in 10 minutes") are faster and more reliable as rules. The model might catch novel patterns, but it also introduces latency and complexity for cases that a three-line if-statement handles perfectly.

The line I use: if you can describe the fraud pattern in one sentence, write a rule. If the pattern is "I'll know it when I see it," train a model.

Deploying a Model in Production

The hardest lesson wasn't building the model: it was serving it. Real-time fraud detection needs inference in under 100ms. That meant:

• Feature engineering that runs at transaction time, not batch. Computing the "average transaction amount for this user in the last 24 hours" needs to happen instantly, not from a daily job.
• Model serialization that doesn't bloat. Pickle files with 200MB of dependencies don't belong in a payment pipeline.
• A fallback strategy. When the model server is down (and it will go down), the ruleset needs to keep running. I've seen teams build beautiful ML pipelines with no fallback, and the first outage took their entire risk system offline.

What I'd Tell Someone Starting Now

Start with rules for the obvious patterns. Add ML for the edge cases rules can't catch. Monitor model performance constantly: not just accuracy, but business impact (how many legitimate transactions are you blocking?). And always, always have a fallback.

The best risk systems I've seen aren't pure ML or pure rules. They're hybrids where each covers the other's blind spots.

You Might Also Like

• What I've Learned Building Checkout Flows with Wallets and AI Agents
• Building Intent-Based UIs: The Future of frontend Development
• Semantic Caching with Redis and Qdrant for LLM Cost Reduction
• DeepSeek V3 Architecture Deep Dive: Multi-Head Latent Attention (MLA), DeepSeekMoE & FP8 Mixed Precision

Frequently Asked Questions