Processor Rules Configuration

Prerequisites

Before configuring processor rules, understand:

• Risk scoring fundamentals
• Velocity rules concepts
• 3D Secure basics for liability shift
• Fraud types you're trying to prevent

Your processor's fraud tools block transactions. Out of the box, they're tuned for average merchants. You're not average. Default settings block too much good revenue or let too much fraud through. Learn to configure them.

Most SMBs never touch their fraud settings. They accept whatever Stripe or their processor decides. This costs them money on both ends: blocked good orders and accepted bad ones.

What Matters

1. Defaults are conservative. Processors don't want fraud on their platform, so they block aggressively.
2. False positives cost more than you think. Every blocked good customer is lost revenue plus acquisition cost. See economics of fraud.
3. Custom rules beat default ML for your edge cases. Processors see patterns across merchants, but they don't know your business.
4. 3DS can shift liability. Use it strategically, not everywhere. See first-time 3DS setup.
5. Monitor and tune continuously. One-time setup doesn't work. Track your fraud metrics.

---

Understanding Processor Fraud Tools

What Processors Offer

Processor	Fraud Tool	Included?	ML Scoring?
Stripe	Radar	Basic included, Radar for Fraud Teams extra	Yes
Braintree	Fraud Protection	Basic included, Advanced extra	Yes
Adyen	RevenueProtect	Included	Yes
Square	Basic built-in	Included	Limited
PayPal	Built-in screening	Included	Yes
Authorize.net	Advanced Fraud Detection Suite	Extra cost	Limited

What the ML Does

Processor ML models score transactions based on:

• Device fingerprint
• IP geolocation and velocity
• Card metadata (issuer, country, BIN)
• Email patterns (see identity verification)
• Behavioral signals
• Cross-merchant data (what they've seen from this card elsewhere)

The score is typically 0-100 (higher = riskier) or a risk level (high/medium/low). See risk scoring for threshold strategies.

What You Control

Control Type	Examples	Learn More
Block rules	Block if IP country != billing country	Velocity rules
Allow rules	Allow if customer has 3+ prior orders	Risk scoring
Review rules	Review if risk score > 75	Manual review
3DS rules	Require 3DS if order > $500	3DS setup
Velocity limits	Block if > 3 transactions from this card in 1 hour	Card testing

---

Stripe Radar Configuration

Stripe's Radar is the most commonly used processor fraud tool for SMBs.

Default Behavior

Radar blocks transactions when its ML model predicts high fraud risk. You don't control the ML, but you control rules that run on top of it.

Radar Rule Types

Type	What It Does	When Triggered
Block	Declines transaction immediately	Before auth
Allow	Bypasses other rules	Before other rules
Review	Marks for manual review	After auth
3DS	Requires 3D Secure	Before auth

Useful Starter Rules

Block rules:

# Block mismatched countries
Block if :ip_country: != :card_country:

# Block high velocity
Block if :total_charges_per_card_number_hourly: > 3

# Block risky email patterns
Block if :email_domain: in ('tempmail.com', 'guerrillamail.com')

Allow rules:

# Allow existing customers
Allow if :customer_id: != null AND :total_charges_per_customer_id_all_time: >= 3

# Allow repeat cards
Allow if :total_charges_per_card_number_all_time: >= 2

3DS rules:

# 3DS for high-value
Request 3D Secure if :amount_in_usd: > 500

# 3DS for high risk
Request 3D Secure if :risk_score: > 65

Radar for Fraud Teams

The paid version ($0.07/transaction screened) adds:

• Custom rule builder with more attributes
• Manual review queue
• Block and allow lists
• Advanced analytics

Worth it if you're over $500k/mo or have complex fraud patterns.

Ask Your Dev

"What Radar rules do we currently have? Are we on basic Radar or Radar for Fraud Teams?"

---

Braintree Configuration

Braintree's fraud tools are part of Braintree Gateway.

Basic Fraud Protection

Included with Braintree:

• AVS mismatch blocking
• CVV mismatch blocking
• Duplicate transaction detection
• Risk threshold configuration

Advanced Fraud Protection

Paid add-on with:

• Device fingerprinting
• ML risk scoring
• Custom velocity rules
• Kount integration option (see fraud vendors)

Key Settings to Configure

Setting	Recommendation
AVS response handling	Block on full mismatch, allow partial
CVV response handling	Block on mismatch
Risk threshold	Start at "Approve" for low/medium, "Review" for high
Duplicate transaction window	30 seconds

Braintree Custom Rules

Via Control Panel > Fraud Management:

# Example: Block international for domestic business
Rule: Card Country NOT equals US
Action: Decline

# Example: Review high-value
Rule: Transaction Amount greater than 1000
Action: Review

---

Adyen RevenueProtect Configuration

Adyen's fraud tool is included but needs configuration.

Risk Profiles

Adyen uses "Risk Profiles" that group settings by business type:

• E-commerce
• Retail
• Subscription
• Digital goods

Start with the profile matching your business, then customize.

Key Configuration Areas

Area	What to Set
Risk scoring	Set thresholds for accept/review/block
Velocity checks	Transactions per card/email/IP per hour/day
AVS/CVV handling	Decline vs. review on mismatch
3DS triggers	Amount thresholds, risk levels
Block/Allow lists	Cards, emails, IPs

Adyen RevenueProtect Rules

Via Customer Area > Risk:

1. Select profile
2. Add rules in order (first match wins)
3. Test with simulation before live

---

3DS Configuration Strategy

3D Secure adds an authentication step. Configure it strategically.

When to Require 3DS

Trigger	Why
High transaction amount (> $500)	High value = higher risk tolerance
High-risk score	Adds friction only for risky transactions
International transactions	Cross-border fraud is higher
First transaction with new card	No history to trust
Mismatched shipping/billing	Common fraud signal

When to Skip 3DS

Trigger	Why
Returning customer with history	Trust is established
Low-value transaction (< $50)	Fraud loss < conversion loss
Transaction qualifies for exemption	TRA, low-value, trusted beneficiary
Mobile checkout	3DS UX is painful on mobile

3DS Rule Examples

Stripe:

Request 3D Secure if :amount_in_usd: > 500
Request 3D Secure if :risk_score: > 65

Braintree:

3DS Required when: Amount > 500 AND Risk = High
3DS Optional when: Amount > 200 AND Customer new

3DS1 vs 3DS2

If you're still on 3DS1, upgrade. 3DS2 supports frictionless authentication (no customer challenge for low-risk), which dramatically reduces conversion impact.

Ask Your Dev

"Are we on 3DS1 or 3DS2? What's our frictionless rate?"

---

Common Mistakes

Mistake 1: Never Touching Defaults

Default settings are calibrated for the average merchant. If you're higher-risk, you'll get more fraud. If you're lower-risk, you'll block good customers.

Fix: Review and customize within 30 days of launch.

Mistake 2: Blocking Too Aggressively

Overly strict rules block good customers. A blocked good customer costs you:

• The transaction revenue
• Future LTV
• Acquisition cost wasted
• Potential bad review

Fix: Start with review instead of block. Analyze what you're blocking.

Mistake 3: Not Monitoring Rule Performance

A rule that worked in January may hurt in July. Traffic patterns change.

Fix: Monthly review of:

• Rule trigger rates
• False positive estimates
• Fraud that got through

Mistake 4: One-Size-Fits-All 3DS

Requiring 3DS on everything kills conversion. Skipping 3DS on everything invites fraud.

Fix: Risk-based 3DS triggers.

Mistake 5: No Allow Rules for Good Customers

If a repeat customer triggers a risk rule, they shouldn't be blocked.

Fix: Allow rules for trusted customers before block rules.

---

Rule Tuning Process

Monthly Review

1. Pull fraud losses - What got through that shouldn't have?
2. Pull block rates - What are we blocking?
3. Sample blocked transactions - Were they actually fraud?
4. Calculate false positive rate - Blocked good / Total blocked
5. Adjust rules - Tighten where fraud is high, loosen where false positives are high

Tuning Example

Problem: Rule "Block if IP country != card country" is blocking 5% of transactions.

Analysis:

• Pull sample of 50 blocked transactions
• Contact 10 customers from blocked list
• 8 of 10 were legitimate (travelers, VPN users)
• False positive rate: 80%

Solution: Change from Block to Review, or add exception for known VPN ASNs, or change to 3DS trigger instead of block.

---

Test to Run

2-week fraud rules audit:

Week 1: Discovery

• Document all current rules
• Pull rule trigger rates for past 30 days
• Pull fraud losses for past 30 days
• Identify top 5 rules by trigger volume

Week 2: Optimization

• Sample blocked transactions for false positive analysis
• Add allow rules for repeat customers
• Convert highest-FP block rules to review
• Add 3DS for high-risk instead of block

Success criteria: False positive rate decreases. Fraud rate doesn't increase.

---

Scale Callout

Volume	Focus
Under $100k/mo	Use processor defaults, add basic velocity rules, require 3DS over $500. Review isn't worth your time at this volume.
$100k-$1M/mo	Custom rules for your top fraud patterns. Monthly rule review. Consider Radar for Fraud Teams or similar.
Over $1M/mo	Dedicated fraud rules person or vendor. Real-time monitoring. A/B testing of rule changes. Multi-layer fraud stack.

---

Where This Breaks

1. High-risk categories with sophisticated fraud. Gift cards, electronics resale, cryptocurrency. Processor tools alone won't cut it. You need specialized fraud vendors.

2. Marketplaces and platforms. Fraud comes from sellers and buyers. Processor tools only see buyer transactions. You need platform-level fraud detection.

3. International with local payment methods. Processor tools are optimized for cards. Local methods (iDEAL, Boleto, etc.) need different fraud approaches.

---

Analyst Layer: Metrics to Track

Metric	What It Tells You	Target
Block rate	How much you're declining	< 3% typically
Review rate	Manual review load	Varies by capacity
False positive rate	Good customers blocked	< 30% of blocks
Fraud rate	What's getting through	< 0.5% of transactions
3DS challenge rate	Friction level	< 20% of 3DS transactions
3DS conversion rate	Challenge completion	> 80%

Rule Performance Dashboard

Track for each rule:

• Trigger count (how often it fires)
• Block/review/allow breakdown
• Fraud caught (confirmed fraud among blocked)
• False positives (legitimate among blocked)
• Revenue impact

Processor Rule Performance Analysis

Build a monthly rule effectiveness report:

Rule	Triggers	Blocks	Reviews	Fraud Caught	False Positives	FP Rate
High amount	500	100	400	25	75	75%
IP mismatch	300	50	250	20	30	60%
Velocity	200	100	100	80	20	20%

Analysis questions:

1. Which rules have highest FP rate? → Candidates for loosening
2. Which rules catch the most fraud? → Keep tight
3. Which rules have low trigger rates? → Maybe unnecessary
4. What fraud gets through? → Need new rules

Rule ROI Calculation

For each rule, calculate:

Rule Value = (Fraud Blocked × Avg Fraud Loss) - (False Positives × Avg LTV Lost)

Example: High-amount block rule

• Fraud blocked: 25 transactions × $200 avg = $5,000 saved
• False positives: 75 transactions × $500 LTV = $37,500 lost
• Rule ROI: -$32,500 → This rule is losing money

Optimization Priorities

FP Rate	Fraud Catch Rate	Action
High	High	Convert to review, investigate each
High	Low	Remove or significantly loosen
Low	High	Keep as-is, maybe tighten
Low	Low	Remove, not adding value

A/B Testing Rules

For rule changes:

1. Split traffic - 10% gets new rule, 90% keeps old
2. Run for 2 weeks - Need enough volume
3. Compare outcomes - Fraud rate, block rate, revenue
4. Validate significance - Is the difference real?
5. Roll out or revert - Based on data

---

Next Steps

Setting up processor rules?

1. Understand what processors offer - ML and rule options
2. Configure Stripe Radar - Block, allow, review, 3DS
3. Set 3DS strategy - When to require, when to skip

Tuning existing rules?

1. Follow monthly review process - Pull fraud, blocks, samples
2. Avoid common mistakes - Never touching defaults, blocking too aggressively
3. Calculate rule ROI - Fraud saved vs LTV lost

Advanced optimization?

1. Build rule performance dashboard - Track each rule
2. A/B test rule changes - Split traffic validation
3. Set optimization priorities - FP rate vs catch rate

---

Related Pages

• Fraud Prevention - Prevention strategies
• 3DS Optimization - Authentication tuning
• Auth Optimization - Approval rates
• Velocity Rules - Rate-based detection
• Fraud Vendors - Third-party tools
• Risk Scoring - Score thresholds
• Rules vs. ML - Detection approaches
• Device Fingerprinting - Digital identity
• Manual Review - Review queues
• Checkout Conversion - Friction balance
• Fraud Metrics - Measuring effectiveness
• Experimentation - Testing rules