Rules are where every fraud team starts, and for good reason. Rules are fast to write, intuitive to reason about, and directly responsive to what you're seeing.

However, when your business grows, their ceiling becomes quickly apparent. This creates operational complexity and makes strategy scaling much harder.

With every region, payment method, platform, and customer segments comes a unique risk profile. Teams see those different risk profiles and do what they know: add more rules, often as a quick fix for growing complexity. A new rule for European payments. An updated threshold for mobile. A new velocity check for B2B customers.

And for a while, this works. Until it doesn't.

Risk profiles aren't the only thing that changes across those dimensions. The relevant vendors change. The appropriate authentication flows change. The underlying data that's even available changes. 

You can set a rule for different risk levels, but you can't write a rule that says "call this KYB vendor for B2B customers in Germany, trigger 3DS for high-value transactions from new devices, and skip enrichment for verified recurring users."

That's where rules hit their limit. And that's where the workflow layer comes in.

Fraud rules vs. workflows

Let me define these two terms clearly, because the confusion between them is what causes most of the problems I'm about to describe.

A rule implements a tactic. It evaluates specific signals to flag or block a specific behavior within that context.

A workflow, on the other hand, implements your fraud prevention strategy. It determines which population a transaction or user belongs to, what checks apply to them, which vendors get called, and what actions are available as outcomes.

In short, it creates the operating context for better segmentation, better routing, and better decisions.

Here's what that looks like in practice:

A rule says: "Flag this transaction if the device is new and the IP is in a high-risk country."

A workflow says: "New users making payments over $500 go through enhanced review: call the identity enrichment vendor, run device intelligence, then evaluate fraud signals."

The workflow sets the stage, and the rule performs on it: neither works alone.

A workflow without sharp rules inside it is just sophisticated routing, with users moving through lanes without actually touching anything.

A rule without workflow context fires against the entire population indiscriminately, catching fraud in some segments and generating noise in others.

If you want a detailed walkthrough of writing and iterating on a detection rule in practice, this post walks through a real example end-to-end.

Fraud workflows do more than just route

Here's the part that most teams miss, even those that understand the basic distinction.

Workflows don't just categorize populations and send them down different paths. They also orchestrate the process by invoking external steps, collecting additional data, and continuing the evaluation, all without terminating the session.

When a transaction comes in, a workflow can call an identity enrichment vendor, wait for the response, and then call a device intelligence provider. Then, based on what it has learned, it can decide whether to trigger a 3DS challenge, invoke a biometric step-up, or proceed directly to fraud rule evaluation. 

All of this happens mid-flow, dynamically, before any final decision gets made.

Rules can't do this. A rule evaluates the signals that are already present at the time it fires. It doesn't reach out to gather more data, it doesn't hold the session open, and it doesn't conditionally trigger authentication based on what it found.

This is what makes the workflow the strategy layer. It decides not just who gets checked, but how, including which tools get invoked, in what order, and for which population.

The rules then perform detection on the enriched, fully-characterized event.

It also means that the two layers have completely different integration surfaces. Rules interact with signals, and workflows interact with vendors, authentication systems, and downstream actions. 

Conflating workflows and rules (or trying to run everything through one) is where the operational complexity starts to compound.

Why can’t you hack one to replace the other?

Teams sometimes do try that. But here's what usually happens:

Rules replacing workflows: Technically, it’s possible. You encode population context directly into rule conditions:
IF new_user AND payment > $500 AND region = EU AND segment = consumer, THEN... 

The problem with stringing these altogether is that every rule carries its own context. It can work, until you have three customer segments, six regions, and sixteen payment methods.

The combinatorial explosion is what creates the bloated ruleset problem. 

But more importantly, none of it solves the vendor orchestration challenge. Rules still can't call a KYB provider mid-session, trigger a 3DS flow, or hold an event open while waiting for an enrichment response. 

You managed to “hack” the routing problem but left the orchestration problem entirely unsolved.

Workflows replacing rules: This fails differently. Theoretically, you can create a workflow branch made of sequential nodes, each containing a single detection logic.

While this can work, it gets difficult to manage very quickly. Simulations might be misleading, as the logics are run sequentially instead of in parallel, making it hard to notice overlaps between the different “rules.”

This also means that your workflows become incredibly bloated, making it harder to monitor and orchestrate your strategy.

But most critically, it introduces a grave operational risk. Every time you tinker with a new rule or a version update (which can happen frequently), you put the entire workflow at risk.

Set the wrong value on a rule, and you’re not just missing fraud — you may also disrupt the entire process your workflow embodies. 

Do you really need workflows for real-time fraud detection?

Here’s what I get often: "We're a payments processor. We don't have complex onboarding flows, and everything is real-time. Do we actually need the workflow layer?"

Yes. Here's why.

It’s true that routing real-time events into different segments is usually a simpler use case. One that you can manage with rules only, even if albeit awkwardly. We’ve all seen it before.

But what we do miss is the orchestration piece.

Think about it like this: the riskier an event is, the more financial exposure I have. And the higher my exposure, the more I’ll be willing to invest in a more accurate decision.

This principle can manifest in different ways. For example:

1. A payment above $500 would be routed through a more expensive data enrichment pipeline.
2. A payment with a high model score would be routed to a second-line model. A model that might be slowing our SLA to a small portion of the population, but is far more accurate.
3. A login to an account with a high balance would get routed through a strong 2FA flow.

As you can see, these use cases are neither about detection logic or which thresholds to enforce. They are about which pipeline this event would go through, and for what cost.

Without a workflow layer, you're running the same pipeline against all of them. Which means you're either over-spending on your fraud prevention or under-checking your highest-risk events.

Usually both, in different places.

Real-time doesn't mean uniform. The workflow layer manages that population complexity at the speed the event requires, such as routing to the right vendors, triggering the right authentication, and applying the right ruleset, all within the same session.

The instinct to skip workflows in a real-time context usually comes from thinking of workflows as a batch or onboarding concept.

They're not. They're the operating context for every event, regardless of how fast that event moves.

Who needs to be in the room for fraud workflow decisions

As much as workflows are designed to manage complexity, they also introduce a level of complexity to your organization.

To explain that, let's first examine the rules.

A new fraud rule changes your detection logic. The stakeholder is the fraud team: they see a new attack pattern, they write a rule, they test it, they ship it. Fast cycle, contained scope, owned end-to-end. I've written about the full rule release process, including backtesting, shadow-mode validation, and live monitoring, in this blog here. 

Workflow changes are a different conversation, and often need multiple conversations at once.

Change which vendors get called in a workflow branch, and you've just made a cost decision. Vendor calls have per-transaction fees, and at any meaningful volume those add up fast. That's an operations and finance conversation.

Change whether a workflow triggers a 3DS challenge or a biometric step-up for a customer segment, and you've just changed the user experience for that population. That's a product conversation.

Change the routing logic itself of which customers go through which branch and you've changed your fraud posture for that segment. That's the fraud team's decision, but one with business implications that go beyond fraud.

Here’s the thing: workflow changes sit at the intersection of fraud, product, operations, and sometimes even finance. Moving them without all teams aligned is how well-intentioned changes create unexpected vendor costs, customer friction, or coverage gaps - sometimes all three at once.

But then again, organizational complexity is not exactly avoidable when scaling.

Two layers, one stack

Rules got every fraud team to where they are today. They're not going away, and they shouldn't. However, rules alone have a ceiling. 

And that ceiling has less to do about detection accuracy than it does about complexity. The moment your business spans multiple regions, payment methods, platforms, or customer segments, you're operating in a context that rules weren't designed to manage on their own. 

The vendor routing, the authentication orchestration, the population segmentation: these belong to the workflow layer.The two layers aren't rivals. They function as a stack where workflows implement the strategy and rules implement the tactics. Each does a job the other can't.

Rules detect risk. Workflows define the response.

Put simply, rules are how fraud teams detect suspicious activity, and workflows are how they operationalize the response. Rules evaluate signals and thresholds. Workflows decide what to do with that information, whether that means escalating for review, triggering authentication, calling a vendor, approving, or blocking.So the question worth asking your team isn't "should we use rules or workflows?" It's whether your workflow layer actually reflects your business complexity. And are the rules inside each branch calibrated for that specific population?

If you're still managing regional variation, customer segmentation, and vendor routing through rule conditions and exception logic, you've already hit the ceiling.

You just might not have named it yet.