Fraud Monitoring Rules and Scenarios: How to Configure Detection Logic for Fraud

Fraud detection logic lives or dies on configuration. The most sophisticated detection engine in the world is only as effective as the rules running inside it and a poorly tuned rule is worse than no rule at all, drowning analysts in false positives while the actual fraud slips through unexamined. Getting the logic right is where fraud prevention is won or lost.

What Are Fraud Monitoring Rules?

Fraud monitoring rules are the configurable conditions that define what suspicious activity looks like and what should happen when it appears. For example, blocking a transaction when a login from a new device is immediately followed by a high-value transfer. They form the deterministic backbone of any fraud program: Explainable, fast, and reliable against known attack patterns. But writing them well requires understanding how fraud detection differs from Anti-Money Laundering (AML) monitoring, where rules end and behavioral analytics begin, and how to calibrate thresholds that catch theft without strangling legitimate customers.

This article walks through the core fraud rule archetypes, the internal-fraud scenarios most teams overlook, and the calibration methodology that keeps false positives manageable.

The following topics are going to be covered in this article;

1. How Fraud Rules Differ from Anti-Money Laundering Transaction Monitoring Rules
2. Rules vs Behavioral Analytics: Two Approaches, Best Together
3. Core Fraud Rule Archetypes
4. Internal Fraud Scenarios: When the Threat Is Inside
5. Tuning Rules to Reduce False Positives Without Missing Fraud
6. Rules and ML Together: The Layered Detection Architecture
7. Building Your Fraud Rule Library: A Starter Kit
8. How Sanction Scanner's Fraud Rule Engine Works

How Fraud Rules Differ from Anti-Money Laundering Transaction Monitoring Rules

Fraud monitoring rules and Anti-Money Laundering (AML) Transaction monitoring rules are often run on the same engine, but they are solving fundamentally different problems.

AML rules detect money laundering patterns: Structuring below reporting thresholds, rapid cross-border fund flows, layering through complex corporate structures, dormant account reactivation. What these patterns have in common is intent; someone is trying to disguise the origin of funds. Each of these typologies has its own configuration logic, which Sanction Scanner's Practitioner's Guide to Transaction Monitoring Rules covers in detail; the focus here stays on the fraud side.

Fraud rules detect unauthorized or deceptive activity: Account takeover, where someone other than the legitimate customer is controlling the account; payment manipulation, where a legitimate payment is redirected to a fraudster; identity fraud, where the person isn't who they claim to be; and internal exploitation, where an employee abuses their access. The common thread here is theft; someone is trying to steal funds or access, not conceal where money came from.

That difference drives several operational distinctions. AML rules often fire post-transaction, surfacing a suspicious pattern that developed over days or weeks; fraud rules have to fire pre-transaction or in real time, because the theft has to be stopped now. The responses differ too: An AML alert leads to investigation and potentially a Suspicious Activity Report (SAR) filing, while a fraud alert means blocking the transaction first, then investigating. AML tolerates some detection latency (a SAR can be filed within 30 days) whereas fraud is unforgiving, with funds gone in minutes. While AML rules draw on transaction history, customer profiles, and geographic data, fraud rules add session data, device signals, and behavioral biometrics on top.

The same engine can configure both: Sanction Scanner's FUSION platform handles fraud and AML rules in one interface, but the rules themselves are built around opposite questions.

There's a practical reason this convergence matters beyond operational tidiness. Fraud and money laundering increasingly occur in the same transaction chain. A scam victim's payment is a fraud event, but the moment it lands in a mule account and starts moving, it becomes a laundering event. Teams that run fraud and AML detection in completely separate systems (with separate alerts, separate analysts, and no shared view) routinely miss the link between the two halves of a single scheme. The fraud team sees an unusual outbound payment and clears it; the AML team sees a suspicious inbound flow weeks later and can't connect it back to its origin. Configuring both rule types on one engine doesn't just save licensing cost; it lets a single composite picture form across what used to be two blind spots. That said, keeping the rule sets conceptually distinct still matters; a fraud rule tuned for real-time blocking should never inherit the latency tolerance of an AML pattern rule, and vice versa.

Rules vs Behavioral Analytics: Two Approaches, Best Together

Knowing where rules fit in the broader detection architecture matters as much as writing the rules themselves.

Rule-based detection works on pre-defined conditions: If condition A and condition B, then alert. It's deterministic; the same input always produces the same output which makes it transparent and easy to explain to regulators, fast to deploy, and reliable against known typologies. Its weaknesses are the flip side of those strengths: It can't detect patterns nobody has codified yet, it needs manual tuning, and its fixed thresholds create blind spots. A typical rule might flag Account-Takeover (ATO) risk when five or more failed login attempts occur within ten minutes from a new device.

Behavioral analytics and machine learning take a different approach, learning a "normal" baseline for each customer and flagging deviations from it. This is probabilistic rather than deterministic; the same input can lead to different outputs depending on context. Its strengths are detecting unknown patterns, adapting to evolving fraud, and reducing false positives over time; its weaknesses are the "black box" explainability concern, the need for training data, and a cold-start problem for brand-new customers with no history. Where a rule sees a fixed threshold, behavioral analytics sees context: A customer who normally transacts between 9 am and 5 pm on weekdays suddenly initiating transfers at 3 am on a Saturday registers as a deviation.

Neither approach is sufficient alone. The strongest programs run both. Rules provide a deterministic safety net so known typologies are always caught, while behavioral analytics catch the novel patterns and subtle deviations that rules miss.

The division of labor between the two is worth getting right because each covers the other's weakest point. Rules struggle most with the unknown; a fraud pattern nobody has seen before simply won't match any condition that's been written, so it passes through untouched until an analyst notices the losses and codifies a new rule after the fact. Behavioral analytics struggle most at the beginning of a customer relationship, where the cold-start problem leaves the model with no baseline to judge against; a brand-new account has no "normal" yet, so a first-week fraud looks no different from a first-week legitimate user. Rules cover that early window with fixed conditions that don't depend on history, while behavioral models gradually take over as the customer accumulates a track record. Treating the two as competing philosophies (picking one and dismissing the other) tends to leave exactly these gaps wide open.

Core Fraud Rule Archetypes

This is the practical heart of any fraud rule library. Six archetypes cover the overwhelming majority of external fraud scenarios.

Velocity and frequency rules

They detect rapid-fire activity that exceeds normal human behavior: Card testing, account takeover, bot attacks. The configuration counts a given event type within a time window per entity and alerts when the count exceeds a threshold: Five or more payment attempts in ten minutes from one device signals card testing; three or more new beneficiaries added in 24 hours suggests mule preparation or ATO; ten or more login attempts in five minutes from different IPs indicates credential stuffing. The classic calibration mistake is setting velocity too low, which buries the team in alerts from power users, or too high, which misses moderate-speed attacks. A reliable tuning method is to analyze the 95th percentile of legitimate customer velocity and set the threshold at twice that level.

Amount threshold rules

They detect transactions that breach risk boundaries: A single transaction exceeding a customer's historical maximum by 5x, cumulative daily outbound exceeding 80% of the account balance (a rapid-drain signal for ATO or mule cash-out), or a transaction priced just below a dual-approval threshold ($24,950 against a $25,000 limit) which suggests deliberate threshold testing. The most common mistake is applying a single global threshold across all customers; a $10,000 payment is routine for a corporate account but alarming for a student one. Segment by customer type and set thresholds per segment based on each one's historical distribution.

Geolocation and IP rules

They detect geographic impossibility and high-risk location signals: A login from the UK followed by a payment initiated from Nigeria 30 minutes later (impossible travel, a strong ATO signal), a payment to a country the customer has never transacted with, a session routed through a TOR or VPN exit node, or multiple accounts accessing from the same IP. Calibration means defining impossible-travel parameters (distance against time), maintaining country risk scores, and whitelisting legitimate VPN use such as remote workers.

Device and session rules

They detect access from unauthorized or suspicious devices: A login from an unrecognized device followed immediately by a high-value transfer, a device fingerprint shared across five or more accounts (a fraud ring or mule herder), a sudden browser/OS change combined with cleared cookies and a new fingerprint (session hijacking), or multiple simultaneous sessions from different locations. These rules depend on device fingerprinting, session tracking, and browser metadata.

Beneficiary risk rules

They detect payments to risky destinations: A payment to a beneficiary added within the past hour (an impulsive or coerced payment, often an APP fraud signal), a beneficiary account less than 30 days old (a potential mule), a beneficiary in an unfamiliar country, or a confirmation-of-payee name mismatch suggesting invoice redirection. Pairing sanctions and PEP screening on the beneficiary with fraud risk scoring turns this into a combined compliance-and-fraud check in a single step.

Pattern break rules

They detect sudden behavioral changes that don't fit the historical profile: A customer with a two-year history of sub-$1,000 monthly activity suddenly moving $50,000, a dormant account receiving a large inbound transfer after six months of silence, or a mobile-only customer suddenly transacting via desktop browser. These work best alongside behavioral analytics; the rule defines the "break," while machine learning defines what "normal" was in the first place.

Internal Fraud Scenarios: When the Threat Is Inside

Most fraud rule content covers external attackers only, but the threat from inside an organization, in other words, employee fraud, is both costly and slow to surface; the ACFE's research consistently finds that the median occupational fraud scheme runs about 12 months before it's detected. A handful of rules target this directly.

After-hours access monitoring flags an employee accessing customer records or initiating transactions outside normal business hours. Define "normal" per role (customer service 8am–8pm, back office 9am–6pm) and alert on activity outside that window. Given how long internal fraud typically goes unnoticed, off-hours activity is one of the strongest early signals available.

Unusual override patterns are an employee overriding system controls (approval limits, verification requirements) more often than their peers. Overrides are valid in edge cases, so the rule should trigger when an individual's override rate is 2x or more above the peer-group average; systemic overrides suggest someone is deliberately circumventing controls.

Vendor master file manipulation flags an employee who adds a new vendor and then approves a payment to that same vendor within a short window. With proper segregation of duties this should be impossible, but systems aren't always configured correctly and fake vendor creation is the single most common internal invoice fraud method, so any instance warrants an alert.

Customer data access without a transaction flags an employee viewing customer account details without processing a transaction or opening a case. When views exceed a defined daily count with no corresponding work items, it may indicate snooping, gathering information for identity theft or to sell customer data.

Tuning Rules to Reduce False Positives Without Missing Fraud

Rules are only as good as their calibration, and calibration comes down to a genuine paradox. Set thresholds too sensitively, with low cutoffs, and false positives pile up, analyst fatigue sets in, and real fraud ends up buried in the noise. Set them too loosely, with high cutoffs, and too few alerts fire, which means missed fraud, financial losses, and regulatory risk. The objective is to maximize precision without sacrificing recall, the share of actual fraud that gets caught. Those two goals pull against each other, which is exactly why calibration is a process rather than a one-time setting.

A disciplined, step-by-step methodology is what keeps that process from becoming guesswork:

Step 1 - Segment the customer base

Separate retail, business, and corporate customers, because each segment has a completely different definition of "normal." A single threshold across all of them is the most common source of both false positives and missed fraud.

Step 2 - Baseline each segment

Analyze 90 days of transaction history per segment and calculate the distribution statistics that matter: Mean, median, 95th percentile, and maximum.

Step 3 - Establish initial thresholds

Put them at the 95th percentile, with a little buffer. This will catch real outliers but allow for normal variation that real customers generate.

Step 4 - Test in a sandbox

Test the rules against historical data in a sandbox environment and measure the results: How many alerts fire, what percentage are known fraud, and what percentage are false positives.

Step 5 - Tune

Modify thresholds based on what the sandbox showed, tighten where the false-positive rate is low, loosen where it's running high.

Step 6 - Deploy with monitoring

Track alert volume, false-positive rate, and detection rate closely for the first 30 days in production, where real behavior often differs from historical data.

Step 7 - Quarterly recalibration

Fraud patterns change and customer behavior evolves, so thresholds that were accurate last quarter drift out of alignment. Calibration is never finished.

Rules and Machine Learning (ML) Together: The Layered Detection Architecture

The most effective fraud programs combine both approaches in a layered architecture rather than choosing between them.

The first layer is rules: Deterministic detection of known fraud typologies is fast, transparent, and explainable. It catches card testing through velocity rules, impossible travel through geolocation rules, threshold breaches through amount rules, and known mule patterns. The second layer is machine learning and behavioral analytics: Probabilistic detection of unknown or evolving patterns, catching subtle behavioral deviations, novel typologies not yet codified as rules, and complex multi-variable patterns. The third layer is combined scoring, where rule alerts and the ML risk score fuse into a single composite fraud score, high rule confidence plus a high ML score becomes a critical alert, low rule confidence plus a high ML score becomes an elevated alert for review, and low-and-low clears.

The point worth emphasizing for examiner readiness: Regulators accept machine learning provided the logic can be explained. Rules supply the explainable baseline; ML adds detection power. Together they satisfy both regulatory expectations and detection effectiveness.

Building Your Fraud Rule Library: A Starter Kit

A prioritized rollout beats trying to deploy everything at once. The rules below are grouped into three tiers by risk and configuration complexity.

Tier 1 - deploy immediately (highest risk, easiest to configure): Velocity rule for 5+ payment attempts in 10 minutes (card testing/bot); impossible travel across two countries within an hour (ATO); new device plus immediate high-value transfer (ATO); beneficiary added and paid within an hour (APP fraud); and after-hours employee access (internal fraud).

Tier 2 - deploy within 30 days (medium complexity): Amount exceeding 5x historical maximum (profile deviation); dormant account reactivation with immediate outbound (mule activation); multiple accounts sharing a device fingerprint (fraud ring); cumulative daily outbound exceeding 80% of balance (rapid drain); and override rate exceeding peer group by 2x (internal fraud).

Tier 3 - deploy within 90 days (requires data and segmentation): A multi-condition mule scenario combining a new account under 90 days old, three or more inbound sources, and outbound within 24 hours; behavioral baseline deviation (requires 90+ days of history); cross-channel anomaly for a mobile-only customer suddenly using desktop; and customer data access without a transaction (snooping detection).

Each of these maps directly to a no-code rule configuration, no engineering required to build or adjust them.

A fraud rule library is never finished. The threat landscape shifts, fraudsters adapt to the thresholds they can infer, and a rule that caught yesterday's attack can become tomorrow's source of false positives. The programs that stay effective treat their rule set as something to review and retune on a schedule, not something to set once and forget.

Minhac Celik

Marketing Lead

View full profile →