Transaction Monitoring

After-the-fact surveillance of transactions, entities and networks to find fraud patterns, mules and slow-building schemes; feeds investigations, SARs, labels and new real-time rules.

What it is

Real-time scoring asks whether to let this transaction through. Monitoring asks what has been happening across these accounts over the past hours, weeks or months. It's the right tool when the evidence for fraud is spread across time or entities:

A mule account that receives many small credits from unrelated senders and sends them out quickly (Fast In Fast Out Patterns)
A ring of 200 cashback accounts submitting receipts from the same three stores, all paying out to five PayPal accounts (Entity Link Analysis)
A customer whose deposits and withdrawals form a kiting cycle across two institutions
An older customer whose spending pattern shifts after a new "friend" appears (Scam Victim Indicators)
An account slowly building good standing before a bust-out (Bust-Out Fraud)
A promo flaw being exploited, visible as an anomaly in the redemption-per-account distribution (Business Logic Exploitation)

In regulated institutions, fraud monitoring overlaps with BSA/AML suspicious-activity monitoring. The systems, alert types and owners often differ, but the data and many of the patterns are the same. Mature programs share entity resolution and case management while keeping regulatory accountabilities separate (Three Lines of Defense).

What it stops (and what it doesn't)

Strength	Why
Network and ring fraud	Patterns emerge only when you aggregate across accounts
Mule detection	Inbound-then-outbound flows over days
Slow first-party fraud	Behavior drifts over weeks
New attack discovery	Anomalies show up in aggregate before labels exist
Recovery	Finding a compromised account early enough to freeze before the next payout

Weakness	Mitigation
Too late for the first irreversible loss	Real-time scoring and holds on that rail
Alert volume swamps analysts	Prioritization, dollar-weighted risk, automated closure of low-risk alerts
Thresholds become known and gamed	Rotate thresholds, and add models and graph features on top of static rules
Labels lag (returns, chargebacks, scam reports)	Use early proxies and pattern-based labels

Design considerations

Decide what you monitor. Alerting at the entity level (customer, device, payout account, merchant or store) cuts alert counts and gives analysts context. Transaction-level alerts suit single high-risk events. Network-level alerts suit rings (Graph Analytics).
Start from single-event anomalies, then aggregate. Transaction Pattern Anomalies flag the odd transaction; monitoring connects many of them across accounts and time.
Use three detection styles:
- Scenario rules for known patterns (rapid in-out, structuring-like behavior, payout-account reuse)
- Anomaly detection for unknowns (peer-group deviations, distribution shifts)
- Supervised models for well-labeled mechanisms
Each one catches cases the other two miss.
Close the loop with real-time controls. For every confirmed monitoring finding, check whether it could have been stopped at the transaction. If it could, write a real-time rule or feature, and have the monitoring result become a label (Fraud Labeling and Feedback Loops).
Set monitoring speed by rail. On instant rails, near-real-time monitoring (minutes) can still catch the second and third payouts of an ATO or a mule. On ACH and checks, monitoring before settlement or return deadlines enables returns and recovery.
Queue by expected loss. Rank alerts by dollars at risk and how much can still be recovered (pending payouts, held funds) (Alert Review Operations).
Document dispositions for regulatory use. Alert dispositions need to be documented well enough to support a SAR decision or a closure rationale (Case Documentation Standards).
Use the industry lens:

Industry	High-value monitoring patterns
Brokerage	Deposit then immediate liquidation and withdrawal; coordinated buys of illiquid securities across unrelated accounts (Ramp-and-Dump via Account Takeover); ACATS out after contact change
Neobanks / consumer fintech	Mule inflows from many P2P senders; early direct-deposit plus instant-credit cycles; dormant-then-busy accounts
Payments / P2P	Fan-in/fan-out networks; payee concentration; scam-payee reuse across victims
Cashback / rewards	Receipt duplicates and near-duplicates; store or SKU concentration; payout-account reuse; referral graph clusters (Referral Graph Patterns)
Marketplaces	Buyer–seller collusion; refund-claim clusters; seller payout acceleration before claims mature
Retail / ecommerce	Return-rate outliers; gift-card purchase and redemption clusters; promo stacking by linked accounts

Implementation path

Stage	What it looks like	Prerequisites
Crawl	Daily batch scenario rules on key patterns (fast in/out, payout-account reuse, high return rates); a spreadsheet or basic queue; manual investigation	Transaction warehouse; analyst capacity
Walk	Near-real-time streaming scenarios; entity-level alerts; Case Management Systems; prioritization by dollars at risk; documented dispositions; feedback to real-time rules	Streaming pipeline; entity resolution; case tooling
Run	Graph-based network detection; anomaly sentinels on key distributions; supervised alert-prioritization models; automated low-risk closure with QA sampling; fraud/AML shared data layer	Graph Analytics; Machine Learning Models; Fraud QA Program; Fraud Data Architecture

Customer friction and trade-offs

Monitoring is invisible until it acts. Then the action (a freeze, an offboarding, a clawback) is high-friction and high-stakes. False positives in monitoring cost more per case than false positives in real-time step-ups.
Freezing accounts with legitimate funds causes complaints and regulatory exposure. Use graded responses: restrict payouts, then freeze, then offboard.
Offboarding mule accounts may conflict with law-enforcement requests to keep them open. Coordinate with compliance.

Measuring effectiveness

Alert-to-case and case-to-confirmed rates by scenario. Retire scenarios that produce mostly noise.
Dollar-weighted detection: confirmed fraud dollars found by monitoring, and the share found before the final payout (still recoverable).
Time to detect: from the first fraudulent event to the alert, by mechanism.
Recoveries: funds frozen, returned or clawed back because of monitoring.
Analyst productivity and QA scores (Fraud QA Program, Alert Review Operations).
Feedback rate: confirmed monitoring findings that led to a new or changed real-time control within N weeks.

Common failure modes

Alert factories: thousands of low-quality alerts, rubber-stamped closures, and the actual fraud missed.
Stale thresholds: static scenario thresholds that adversaries have learned.
Siloed systems: separate fraud and AML monitoring with no shared entity view, so rings fall between them.
No loop back: monitoring findings never become prevention, so the same pattern is found every month.
Uniform batch cadence: daily batch on instant rails, so alerts land after the money is gone.
Thin case notes: poor disposition documentation that fails audit or SAR quality review.

Regulatory and policy notes

BSA/AML suspicious activity reporting:
- Banks file SARs for criminal violations of $5,000 or more when a suspect is identified, and $25,000 or more when no suspect is identified. Insider abuse is reportable at any amount.
- Filing is due within 30 calendar days of initial detection, extendable to 60 days if no suspect is identified.
- Continuing activity should be reviewed at least every 90 days.
- The FFIEC manual notes the SAR section is being updated for interagency FAQs issued in 2021 and October 2025. See BSA-AML and SAR Filing.
Monitoring systems. The FFIEC BSA/AML manual expects automated monitoring rules and thresholds to be reasonable, periodically tested and independently validated.
Nacha 2026. Requires RDFIs to monitor incoming ACH credits for fraud (risk-based; pre-posting not required). Suggested red flags include SEC-code/account-type mismatch, atypical high-dollar amounts, bursts of similar credits, and new, dormant or mule accounts (Nacha Rules and ACH Risk).
Elder exploitation. Brokerage holds under FINRA Rule 2165 and state reporting obligations (Trusted Contact and Senior Investor Holds).

Mechanisms addressed

Sources and further reading

FFIEC BSA/AML Manual: Suspicious Activity Reporting: SAR thresholds and timelines; manual and automated monitoring expectations; 2025 FAQ update note.
Nacha: Fraud Monitoring Phase 1: RDFI credit monitoring red flags and R17/R06 return options.
Nacha: Fraud Monitoring Phase 2: extension to all RDFIs and originators.
FINRA Rule 2165: temporary holds for suspected exploitation of specified adults.