What is the difference between transaction monitoring and fraud detection?

Transaction monitoring focuses on detecting suspicious activity that may indicate money laundering, terrorist financing, or sanctions violations. It is driven by regulatory requirements (BSA, AML Directives) and results in regulatory reports (SARs, CTRs). Fraud detection focuses on protecting the platform and its users from financial theft. The two overlap significantly in technique (rules, ML models, alert workflows) but differ in purpose and regulatory treatment. Many fintech products operate both systems. See the [fraud detection requirements template](/templates/fraud-detection-requirements-template) for the fraud-focused specification.

How do I set initial thresholds for monitoring rules?

Start with regulatory guidance and industry benchmarks. FinCEN advisories and FFIEC examination procedures provide threshold ranges for common typologies. Then calibrate against your own data: run proposed rules against 90 days of historical transactions to estimate alert volume and productive rate. Set thresholds conservatively at first (lower thresholds, more alerts) and tune upward as you gather data on false positives. Document your calibration rationale for examiners.

How many alerts per analyst per day is sustainable?

Industry benchmarks range from 15-30 alerts per analyst per day, depending on case complexity. High-priority alerts (potential SARs) take 45-90 minutes each. Low-priority alerts take 10-20 minutes. If your alert volume exceeds analyst capacity, either hire more analysts, tune rules to reduce false positives, or implement tiered automation (auto-clear obvious false positives, route only ambiguous cases to humans). Use the [AI ROI Calculator](/tools/ai-roi-calculator) to model the cost savings of automating low-risk alert triage.

What documentation do regulators expect for rule tuning decisions?

Regulators expect a written record of every rule change: what was changed, why, the supporting analysis, who approved it, and the before/after impact on detection and false positive rates. Maintain a rule changelog with these fields. If you reduce coverage (raise thresholds, remove a rule), document the risk-based rationale clearly. Examiners may challenge any change that appears to reduce monitoring sensitivity without adequate justification.

Do I need transaction monitoring if I use a banking-as-a-service provider?

Usually yes, though the scope depends on your partnership model. Most BaaS providers (e.g., Unit, Treasury Prime, Synapse) handle CTR filing and some baseline monitoring, but the fintech partner typically retains responsibility for its own risk-based monitoring program. Your regulatory counsel should clarify the division of responsibilities in the BaaS agreement. At minimum, you need visibility into your transaction data and the ability to file SARs for activity your own systems detect. ---

Transaction Monitoring Rules Template

What This Template Is For

Transaction monitoring is a regulatory requirement for any financial product that moves money. US Bank Secrecy Act, EU Anti-Money Laundering Directives, and similar regulations worldwide require financial institutions to detect and report suspicious activity. Failure to maintain an effective monitoring program can result in consent orders, fines in the hundreds of millions, and criminal liability for compliance officers.

This template helps product managers and compliance teams specify transaction monitoring rules, alert thresholds, escalation workflows, and reporting processes. It bridges the gap between regulatory requirements and technical implementation. Use it to document your monitoring rule set, define alert handling procedures, and establish a tuning process that keeps rules effective as your product grows. Pair this with your fraud detection requirements for the broader detection system and your fintech compliance checklist for the regulatory framework.

How to Use This Template

Copy the template into your compliance documentation system.
Work with your BSA/AML officer to define monitoring rule categories and thresholds.
Document each rule with its trigger condition, alert priority, and expected analyst action.
Define the alert investigation workflow with your operations or compliance team.
Establish a rule tuning process: monthly reviews of rule effectiveness and false positive rates.
Review the completed spec with compliance, engineering, and operations before implementation.

The Template

Monitoring Program Overview

Field	Details
Program Name	[e.g., AML Transaction Monitoring Program]
Author	[PM or BSA Officer name]
Date	[Date]
Status	Draft / In Review / Approved
BSA Officer	[Name]
Monitoring System	[e.g., Actimize, Featurespace, custom-built]
Scope	[Which products, transaction types, and customer segments are monitored]
Last Independent Review	[Date]

Monitoring Rule Categories

☐ Rule categories defined and aligned with risk assessment
☐ Each category covers a specific typology of suspicious activity
☐ Rules cover both individual transactions and aggregate patterns

Category	Description	Typologies Covered
Structuring	Transactions split to avoid reporting thresholds	CTR avoidance, smurfing
Rapid Movement	Funds received and immediately sent out	Pass-through, layering
Unusual Volume	Transaction frequency outside normal patterns	Burst activity, dormant-to-active
Geographic Risk	Transactions involving high-risk jurisdictions	FATF high-risk countries, sanctioned regions
Inconsistent Profile	Activity inconsistent with stated purpose or income	Business type mismatch, income mismatch
Round Amounts	Repeated round-dollar transactions	Structuring indicator, shell company activity
Peer Network	Related accounts exhibiting coordinated behavior	Funnel accounts, mule networks
[Custom category]	[Description]	[Typologies]

Monitoring Rules Specification

☐ Each rule has a unique ID, description, and regulatory basis
☐ Thresholds calibrated to product-specific risk factors
☐ Rules tested against historical data before deployment

Rule ID	Category	Trigger Condition	Lookback Window	Alert Priority	Regulatory Basis
TM-001	Structuring	> [X] cash deposits within [Y] days, each between $[A] and $[B]	[X] days	High	BSA 31 CFR 1010.320
TM-002	Rapid Movement	Funds received and > [X]% transferred out within [Y] hours	[X] hours	High	FinCEN Advisory FIN-2020-A003
TM-003	Unusual Volume	Transaction count > [X]x customer's 90-day average	1 day	Medium	BSA risk-based approach
TM-004	Geographic Risk	Transaction with counterparty in FATF high-risk jurisdiction	Per transaction	High	FATF Recommendations
TM-005	Inconsistent Profile	Monthly transaction volume > [X]x stated annual income	30 days	Medium	CDD requirements
TM-006	Round Amounts	> [X] round-dollar transactions ($X00) within [Y] days	[X] days	Low	BSA guidance
TM-007	[Category]	[Condition]	[Window]	[Priority]	[Basis]

Alert Handling Workflow

☐ Alert priority levels defined with SLAs
☐ Analyst investigation steps documented
☐ Decision options and documentation requirements defined
☐ Escalation path for complex cases defined
☐ Quality assurance review process defined

Alert Lifecycle

Stage	Description	SLA	Owner
Generated	System creates alert based on rule trigger	Immediate	System
Assigned	Alert routed to analyst based on priority and capacity	< [X] hours	System / Team Lead
Investigation	Analyst reviews transaction history, customer profile, and supporting data	< [X] business days	Analyst
Decision	Analyst documents finding: cleared, escalated, or SAR recommended	Within investigation SLA	Analyst
QA Review	Senior analyst reviews a sample of decisions	< [X] business days	Senior Analyst
SAR Filing	If warranted, SAR drafted and filed within regulatory timeframe	30 calendar days from decision	BSA Officer

Investigation Checklist

☐ Review triggering transactions (amounts, dates, counterparties)
☐ Review customer profile (account type, stated purpose, KYC tier, risk rating)
☐ Review 90-day transaction history for broader patterns
☐ Check for prior alerts on this customer
☐ Check counterparties against sanctions and watchlists
☐ Review any available external data (adverse media, public records)
☐ Document findings and rationale for decision
☐ If SAR recommended, draft narrative and gather supporting documentation

Decision Options

Decision	Criteria	Action
Clear (false positive)	Activity explained by customer profile, legitimate business purpose	Close alert, update customer profile if needed
Clear (true alert, not suspicious)	Alert fired correctly but activity is lawful	Close alert, document rationale
Escalate	Complex case requiring senior or compliance review	Route to senior analyst or BSA officer
SAR Recommended	Activity meets SAR filing criteria	Draft SAR, route to BSA officer for review and filing
Account Action	Activity warrants account restriction or closure	Recommend to compliance for action

SAR Filing Process

☐ SAR filing triggers defined and documented
☐ SAR narrative template available for analysts
☐ Filing timeline tracked (30 days from determination)
☐ SAR supporting documentation archived
☐ 90-day continuing activity reviews scheduled for filed SARs

Step	Action	Timeline	Owner
1	Analyst recommends SAR filing	Day 0	Analyst
2	BSA officer reviews recommendation and supporting evidence	Within 5 business days	BSA Officer
3	SAR narrative drafted	Within 10 business days	Analyst + BSA Officer
4	SAR filed with FinCEN	Within 30 calendar days of determination	BSA Officer
5	SAR confirmation number recorded	Filing day	BSA Officer
6	90-day continuing review scheduled	Day 90 after filing	System / BSA Officer

Currency Transaction Reporting (CTR)

☐ CTR filing automated for cash transactions > $10,000
☐ Aggregation logic for multiple transactions by same customer in one business day
☐ CTR filing within 15 days of transaction
☐ CTR exemptions documented and reviewed annually

Rule Tuning and Effectiveness

☐ Monthly rule effectiveness review scheduled
☐ Tuning process defined (who proposes, who approves, how tested)
☐ Below-the-line testing for new rules before deployment

Metric	Target	Review Frequency
Productive alert rate (SAR filed / total alerts)	> [X]%	Monthly
False positive rate per rule	< [X]%	Monthly
Alert volume per analyst per day	[X]-[Y] alerts	Weekly
SAR filing timeliness (within 30 days)	100%	Monthly
Mean investigation time by priority	[Targets by priority]	Monthly

Tuning Process

Step	Action	Owner
1	Identify underperforming rule (high false positives or low detection)	Compliance Analyst
2	Analyze root cause and propose threshold adjustment	Compliance + Data Team
3	Test adjusted rule against 90 days of historical data	Engineering
4	Review test results with BSA officer	BSA Officer
5	Approve and deploy change	BSA Officer
6	Document change with rationale in rule changelog	Compliance

Filled Example: Digital Payment Platform

Monitoring Rules (Excerpt)

Rule ID	Category	Trigger	Window	Priority
TM-001	Structuring	> 3 deposits between $3,000 and $9,500	7 days	High
TM-002	Rapid Movement	> 80% of received funds transferred out	48 hours	High
TM-003	Unusual Volume	Daily transaction count > 5x 90-day average	1 day	Medium
TM-004	Geographic Risk	Any transaction with counterparty in Iran, North Korea, Syria, or Myanmar	Per transaction	Critical
TM-005	Inconsistent Profile	Monthly volume > 3x stated monthly income	30 days	Medium

Rule Effectiveness (Excerpt)

☑ TM-001 (Structuring): 14% productive rate, 2.3 alerts/day. Threshold increased from $2,000 to $3,000 in January.
☑ TM-002 (Rapid Movement): 22% productive rate, 1.1 alerts/day. Performing well, no tuning needed.
☑ TM-003 (Unusual Volume): 4% productive rate, 8.7 alerts/day. Under review for threshold adjustment.
☑ TM-004 (Geographic Risk): 38% productive rate, 0.3 alerts/day. Critical priority maintained.
☐ TM-005 (Inconsistent Profile): New rule deployed February 2026, effectiveness review due May 2026.

Key Takeaways

Transaction monitoring is a regulatory requirement, not optional. Build it into your product from the start
Define rules with specific thresholds, lookback windows, and regulatory basis. Vague rules create compliance risk
Establish a regular tuning process. Rules that generate excessive false positives waste analyst time and degrade detection quality
Document everything: rule changes, tuning rationale, investigation decisions, and SAR filings. Examiners will review your records
Monitor analyst capacity. Alert volumes that exceed capacity lead to missed suspicious activity

About This Template

Created by: Tim Adair

Last Updated: 3/4/2026

Version: 1.0.0

License: Free for personal and commercial use

Transaction Monitoring Rules Template