When’s the last time someone stress-tested the assumptions underneath your fraud stack?
When we were building Kintana in the late nineties, one of the things that kept us honest was a simple engineering question: what assumptions are baked into this system, and are those assumptions still true? Every architecture makes bets. The ones that survive are the ones where the bets age well. The ones that fail, often quietly and expensively, are the ones where the world moved and the system didn’t notice.
I’ve been thinking about that question a lot lately. Because the fraud prevention systems running inside most enterprise commerce operations right now are sitting on assumptions that haven’t been true for years.
The Review Time to Real-Time Paradox
The core assumption is about time. Rules-based fraud systems were built in an era when there was a meaningful gap between when a transaction was initiated and when it cleared. That gap was the working window: there was time to check, flag, review, and intervene. The whole architecture was shaped around that window.
It doesn’t exist anymore. One-click checkout, instant payments, BNPL, and agent-assisted purchasing allow modern commerce to authorize and settle in seconds, sometimes milliseconds. A system designed to work in the gap between those two moments is now being asked to operate in an environment where that gap is effectively zero. And it shows. Latency that was acceptable in 2010 causes abandoned carts in 2026. Review queues that made sense when you had hours now create friction that loses customers in real time.
That’s not a configuration problem. You can’t tune your way out of a wrong architectural assumption.
Fraud Breaks the Rules (Literally)
The second thing—and this one took me longer to fully appreciate—is what rules actually are from an attacker’s perspective. A ruleset is a specification. It tells a sophisticated actor exactly what the system is looking for. So organized fraud rings don’t attack your system blindly; they probe it, map its shape, and route around it. They build account histories that look legitimate because they know what legitimate looks like to your rules. They time transactions to stay under velocity thresholds. They exploit the edges you didn’t think to cover.
The rules you wrote last quarter are already partially public knowledge to anyone who’s testing against your system. That’s not a hypothetical, it’s just how any sufficiently motivated adversary interacts with a published constraint. And the more sophisticated the fraud operation, the faster the iteration cycle. Which means rule writers are perpetually behind.
I’m not saying rules have no role. They do. But if rules are your primary defense, you’ve handed the attacker an enormous structural advantage and you might not realize it until the chargeback data comes in. The conversation usually goes wrong when people hear “legacy fraud systems are breaking” and immediately translate that into “we need better AI models.” That’s the wrong frame.
A model is not the hard part. Models improve constantly; that’s essentially a commodity problem at this point. The hard part is orchestration, and building a decisioning layer that can ingest signals from across the full customer journey, sequence them correctly, weight them against live context, and produce a decision. And, it all needs to happen inside a window measured in milliseconds without either letting fraud through or blocking a real customer who’s just using a new device.
That’s a workflow problem. I’ve spent thirty years building systems that make complex, high-stakes decisions at scale, and the bottleneck is never the intelligence layer. It’s the architecture that routes inputs to that layer, governs the decision logic, and manages what happens when the signal is ambiguous. Which is most of the time.
Fixing the Model Won’t Fix the Pipeline
What most commerce operations have is a fraud model sitting at the end of a pipeline that wasn’t designed for the volume, speed, or signal diversity of modern e-commerce. Improving the model doesn’t fix the pipeline. The outcomes this produces are both more and less visible than people expect.
The fraud getting through is less visible than it used to be. The high-volume, obvious attacks that older systems were built for have largely given way to slower, more patient approaches (accounts seasoned over months; synthetic identities built from real data fragments; coordinated abuse that looks like normal behavior in any single transaction, but is only detectable as a pattern across thousands). By the time a rules-based system has seen enough instances to write a rule, the exposure is already significant.
The legitimate customers being blocked are completely invisible. They don’t call to complain. They just buy somewhere else. That $30 million in annual revenue that never shows up in any report. No alert, no flag, no post-mortem; that’s not a fraud problem, it’s a systems design problem that fraud infrastructure is causing. Both failures have the same root cause: a system making binary, transaction-level decisions without the context to make those decisions well.
The fix is not a better algorithm sitting on top of the same broken architecture. It’s a decisioning layer built for the actual conditions of real-time commerce; one that sees sessions, not just transactions; patterns, not just moments; and holds both fraud prevention and revenue protection as first-class objectives in the same decision. That requires rethinking the orchestration layer. Not the model underneath it.
The real analysis must be laser-focused on whatever assumptions the architecture is built on. Whether the window it was designed for still exists. Whether the signal inputs are rich enough. Whether the system was ever designed to hold two objectives simultaneously. In my experience, the answer is usually that those questions simply haven’t been asked. Not because anyone was negligent, but because the system was working well enough for long enough that no one needed to ask them.
The window to act isn’t the next time fraud spikes. It’s now, before the architecture you haven’t questioned becomes the incident you can’t explain.
