Every fraud control program operates between what machines can process and what humans can interpret. You're under pressure to block more fraud, meet regulatory mandates, and avoid false positives that alienate customers. The solution isn't choosing between automated rules and manual review. It's about designing the handoff between them.
Scope: What This Guide Covers
This guide focuses on fraud risk management controls for transaction monitoring, account verification, and payment authorization workflows. It covers:
- The distinction between preventive and detective controls
- When to use mandatory, manual, and automated controls
- How to structure escalation thresholds between automated and human review
- Regulatory frameworks that dictate control requirements
It does not cover AML transaction monitoring (see the Bank Secrecy Act and FFIEC BSA/AML Examination Manual) or cardholder data protection (see PCI DSS requirements).
Key Concepts and Definitions
Preventive controls stop fraud before it occurs. Examples include velocity limits on card-not-present transactions, device fingerprinting, and Multi-Factor Authentication (MFA) at login.
Detective controls identify fraud after the event. Examples include post-authorization transaction review, anomaly detection on spending patterns, and periodic account reconciliation.
Mandatory controls are non-negotiable and implemented to meet legal or regulatory requirements. Zero-tolerance processes like KYC verification or Suspicious Activity Report (SAR) filing fall here. You can't accept a "low" fraud rate when regulation demands compliance on every transaction.
Manual controls require human judgment. An analyst reviews flagged transactions, approves high-value wire transfers, or investigates account takeover claims.
Automated controls execute without human intervention. They're programmed into your transaction processing system, payment gateway, or fraud detection platform. Parameters may be rule-based or driven by machine learning models.
Requirements Breakdown
Preventive vs. Detective: Where Each Applies
Preventive controls reduce your incident count. Use them where:
- The fraud typology is well-understood (card testing, account enumeration)
- Real-time decisioning is feasible
- False positives cause acceptable friction (step-up authentication, temporary holds)
Detective controls reduce your loss per incident. Use them where:
- The fraud pattern emerges over time (synthetic identity schemes, refund abuse)
- Immediate blocking would disrupt legitimate activity
- You need evidence for investigations or SAR filings
Mandatory Controls and Zero-Tolerance Policies
Certain processes demand zero tolerance. Anti-money laundering checks, KYC verification, and sanctions screening (Watchlist Screening) are mandatory under the Bank Secrecy Act and related regulations. You can't set a "risk appetite" for letting a Politically Exposed Person (PEP) slip through unscreened.
Declaring zero tolerance for all fraud is operationally unrealistic. You'll set realistic tolerance levels for transactional fraud based on:
- Your fraud loss ratio as a percentage of transaction volume
- Regulatory expectations for your industry
- Customer experience trade-offs
Consider a payment processor handling high-volume, low-value transactions. A zero-tolerance policy would require manual review of millions of payments daily. Instead, you define tolerance thresholds: block transactions above a risk score, flag mid-range scores for review, and auto-approve low scores with detective monitoring.
Manual vs. Automated: The Division of Labor
Manual controls scale with headcount. Automated controls scale with infrastructure. The division isn't arbitrary:
Manual review excels at:
- Contextual judgment (Is this wire transfer consistent with the customer's business?)
- Investigating ambiguous signals (Why did velocity spike on this account?)
- Approving exceptions to policy
Automated controls excel at:
- High-volume decisioning (blocking card-testing attacks in real time)
- Consistent application of rules (no analyst fatigue)
- Pattern recognition across large datasets
Your program fails when you ask manual review to do what automation should handle, or when you automate decisions that require human interpretation.
Implementation Guidance
Step 1: Map Your Fraud Risks to Control Types
Start with your fraud risk assessment. For each identified risk, determine:
- Can this be prevented, or only detected after the fact?
- Is this a mandatory control (regulatory requirement) or discretionary?
- Does decisioning require human judgment, or can it be automated?
Consider account takeover fraud. Preventive controls include MFA at login and device fingerprinting. Detective controls include monitoring for unusual transaction patterns post-login. The MFA requirement may be mandatory under Payment Services Directive 2 (PSD2) for European payment accounts. Device fingerprinting can be automated; investigating flagged sessions requires manual review.
Step 2: Define Escalation Thresholds
Automated systems should handle the clear cases. Manual review should focus on the ambiguous middle. Set thresholds based on:
- Risk score ranges: Auto-decline above 90, auto-approve below 30, queue 30-90 for review
- Transaction value: Manual review for wire transfers over a defined limit
- Customer segment: Higher scrutiny for newly onboarded accounts
Document these thresholds in your fraud risk management policies. They're not static. You'll adjust them as fraud patterns evolve and as you measure false positive rates.
Step 3: Build Subject Matter Expertise Into Automation
Automated fraud management controls require specialist knowledge to design. You need subject matter experts who understand both the regulatory requirements and the fraud risk factors in each process.
If you're automating transaction monitoring for structuring (smurfing) detection, your expert must know:
- Bank Secrecy Act reporting thresholds
- Typologies for breaking deposits into sub-$10,000 amounts
- Behavioral patterns that distinguish structuring from legitimate cash-intensive businesses
Without this expertise, your automated rules will generate noise, not actionable alerts.
Step 4: Document Everything
Policies and procedures aren't optional. They define:
- What controls apply to which processes
- Who owns each control (department, role)
- How to escalate exceptions
- How to investigate incidents and respond to confirmed fraud
Without documented procedures for fraud investigation and incident response, your program is incomplete. Regulators expect to see evidence that controls are defined, approved by senior management, and consistently applied.
Common Pitfalls
Pitfall 1: Automating without tuning. You deploy a fraud detection platform with default rules. False positives spike. Customer complaints increase. Your team disables alerts to reduce noise, and fraud slips through. Solution: Invest in tuning. Measure precision and recall. Adjust thresholds based on actual fraud rates in your environment.
Pitfall 2: Manual review without clear criteria. Analysts receive flagged transactions but lack guidance on what to investigate or approve. Decisions become inconsistent. Solution: Write decision trees. Define what evidence justifies approval, escalation, or decline.
Pitfall 3: Treating all fraud risks as zero-tolerance. You declare that no fraud is acceptable, then discover you can't operationalize that standard. Solution: Distinguish mandatory controls (where zero tolerance is legally required) from discretionary controls (where you balance risk and friction).
Pitfall 4: Ignoring legislative changes. Fraud legislation evolves. The Fraud Act consolidated offenses previously scattered across the Theft Acts and Companies Act. The Sarbanes-Oxley Act introduced requirements affecting UK and international organizations. Failing to update controls when laws change leaves you non-compliant. Solution: Assign ownership for monitoring regulatory updates. Review your control framework annually.
Pitfall 5: No feedback loop from manual review to automation. Analysts investigate cases manually but never feed findings back into automated rules. You miss the opportunity to prevent similar fraud in the future. Solution: Establish a process for converting investigation insights into rule updates or model retraining.
Quick Reference Table
| Control Type | Best Use Case | Example | Limitation |
|---|---|---|---|
| Preventive + Mandatory | Regulatory compliance | MFA for PSD2 SCA | No flexibility |
| Preventive + Automated | High-volume, known patterns | Velocity limits on card transactions | Misses novel fraud |
| Preventive + Manual | High-value approvals | Wire transfer authorization | Doesn't scale |
| Detective + Automated | Pattern recognition at scale | Anomaly detection on spending | Requires tuning |
| Detective + Manual | Contextual investigation | Account takeover claim review | Resource-intensive |
Your fraud risk management program works when automated controls handle volume and manual review handles judgment. Define the boundary clearly, document it in policy, and adjust as fraud evolves.
