Your transaction monitoring system generates thousands of alerts, most of which are false positives. The issue isn't the technology, it's the ruleset you've provided.
This template offers a structured starting point for building effective transaction monitoring rules. You'll define thresholds, conditions, and alert routing in a format your compliance team can review and your system can implement.
Purpose of This Template
Transaction monitoring rules are the logic your AML software uses to flag potentially suspicious activity. Each rule defines:
- What transaction pattern triggers an alert
- Under what conditions the pattern matters
- How the system should prioritize the alert
- Who reviews it first
Without clear documentation, rules become black boxes. Compliance officers can't explain them to examiners, and risk teams can't adjust them when false positives spike. This template ensures you document the reasoning behind each rule before deployment.
Use it when you're:
- Building a new monitoring scenario from scratch
- Documenting an existing rule configured without written specifications
- Proposing changes to an underperforming rule
- Preparing for a BSA/AML examination
Prerequisites
Before using this template, ensure you have:
- Access to your institution's risk assessment: Your rules should reflect your actual risk profile, not generic industry patterns.
- Historical transaction data: At least six months of data is needed to test thresholds and estimate alert volumes.
- Defined customer segmentation: Different customer types need different thresholds (e.g., a $50,000 wire is normal for a commercial client, suspicious for a student account).
- Alert review capacity: Know how many alerts your team can investigate per day, there's no point deploying a rule that generates 500 alerts if you can review only 50.
The Template
RULE ID: [Unique identifier, e.g., STRUCT-001]
RULE NAME: [Descriptive name, e.g., Rapid Sequential Deposits Below CTR Threshold]
REGULATORY BASIS:
- Primary regulation: [e.g., Bank Secrecy Act, 31 CFR 1020.320]
- Typology addressed: [e.g., [Structuring (Smurfing)](/glossary/structuring-smurfing)]
- Risk level in institutional risk assessment: [High/Medium/Low]
BUSINESS LOGIC:
Trigger when: [Describe the pattern in plain language]
Example: "Customer makes 3 or more cash deposits within 5 business days, each between $8,000 and $9,999, totaling $25,000 or more"
CONDITIONS:
- Lookback period: [e.g., 5 business days]
- Transaction types included: [e.g., Cash deposits, wire transfers, ACH credits]
- Transaction types excluded: [e.g., Payroll deposits, known recurring transfers]
- Minimum transaction amount: [Dollar amount]
- Maximum transaction amount: [Dollar amount]
- Aggregate threshold: [Total dollar amount across lookback period]
- Minimum transaction count: [Number of transactions]
CUSTOMER SEGMENTATION:
Apply rule to:
- [X] Retail customers
- [ ] Commercial customers with annual revenue < $1M
- [ ] Commercial customers with annual revenue > $1M
- [ ] High-risk customer categories (specify): ___________
Exclude:
- Customers in monitoring suppression period (specify reason): ___________
- Accounts flagged for closure
- [Other exclusions based on your risk assessment]
ALERT PRIORITIZATION:
- Initial priority level: [High/Medium/Low]
- Escalation criteria: [What makes this alert urgent?]
Example: "Escalate to High if customer has prior SAR filing within 12 months"
ALERT ROUTING:
- Primary review queue: [Team or individual]
- Escalation path: [Who reviews if initial analyst escalates]
- Expected review SLA: [Hours or days]
TUNING PARAMETERS:
- Expected monthly alert volume: [Estimate based on testing]
- Acceptable false positive rate: [Percentage, typically 70-90% for new rules]
- Last tuning date: [Date]
- Next scheduled review: [Date]
TESTING NOTES:
- Test period: [Date range]
- Test population: [Number of accounts or transactions]
- Alerts generated during test: [Count]
- True positives identified: [Count]
- SARs filed from test alerts: [Count]
- Adjustments made based on testing: [Description]
DOCUMENTATION LINKS:
- Rule configuration file: [System path or document reference]
- Approval memo: [Document reference]
- Examiner guidance: [Reference to FFIEC BSA/AML Examination Manual section or other guidance]
Customizing the Template
Start with the typology, not the threshold. Your risk assessment should indicate which money laundering typologies are relevant. For a retail bank with many cash deposits, structuring is important. For a fintech with no cash handling, it isn't. Choose the typology first, then build the rule.
Set thresholds based on your data, not industry rumors. The $10,000 Currency Transaction Report threshold is law. The $8,000 structuring threshold is a convention. Analyze your actual transaction patterns. If your customers rarely deposit more than $3,000, a structuring rule starting at $8,000 will miss everything.
Define "normal" for each customer segment. A commercial construction company wiring $100,000 weekly is normal. A college student doing the same isn't. Segment your customers by type, transaction volume, and account age. Apply different thresholds to each segment. The template's customer segmentation section ensures clarity about rule applicability.
Test before you deploy. Run the rule against six months of historical data. Count the alerts. If it generates 2,000 alerts and your team can review 200 per month, you have a capacity problem. Tighten the thresholds or narrow the scope until the volume is manageable.
Document your tuning decisions. When you adjust a threshold from $25,000 to $30,000, write down why. When an examiner asks, "Why $30,000?", you need a solid answer. The testing notes section captures this.
Link to your system configuration. This template is documentation, not code. After finalizing the rule, reference where it lives in your monitoring system. If your platform uses XML config files, link to the file. If it's a GUI-based system, screenshot the configuration screen and attach it.
Review quarterly. Transaction patterns change. Your customer base grows. Regulatory guidance evolves. Set a reminder to review every rule quarterly. The "Next scheduled review" field makes this enforceable.
Validation Steps
After deploying the rule, validate it's working:
Verify alert generation: Within the first week, confirm the rule is firing. If you expected 20 alerts per week and you're seeing zero, check your configuration.
Spot-check alert quality: Pull 10 random alerts. Review them manually. Are they legitimate suspicious activity, or obvious false positives? If 9 out of 10 are junk, your thresholds are too loose.
Measure review time: Track how long analysts spend investigating alerts from this rule. If every alert takes 45 minutes to clear and you're generating 100 per day, you've created an operational problem.
Check for gaps: Identify a known suspicious transaction that should have triggered the rule. Manually verify it generated an alert. If it didn't, your conditions are too narrow.
Document the first SAR: When this rule generates its first Suspicious Activity Report, note it. That's proof the rule is doing its job. If six months pass with no SARs, either your thresholds are too conservative or you're monitoring the wrong pattern.
Keep the completed template in your compliance management system. When examiners arrive, hand them the documentation. They want to see you can explain your monitoring logic, prove you tested it, and show you review it regularly. This template provides all three.
