.ws file with an explanation of why it works and how to customize it for your needs.
How to Use This Cookbook
- Find a recipe that matches the fraud pattern you want to detect.
- Copy the
.wsfile into yourwatch_scripts/directory. - Customize the thresholds — adjust amounts, time windows, and scores to match your risk appetite.
- Test with sample transactions — inject transactions that should and should not trigger the rule.
- Deploy — commit to your Git repository and let FinWatch pick it up.
- The complete rule — copy-paste ready.
- Why this works — the fraud pattern this rule targets.
- How to customize — which values to tune for your business.
Threshold Checks
High-Value Transaction Check
- Threshold: Adjust
10000based on your typical transaction sizes. A consumer payments platform might use5000; a B2B platform might use100000. - Score: At
0.5, this is moderate confidence. Increase to0.7+if high-value transactions are rare in your system. - Verdict:
reviewis appropriate for most cases. Useblockonly if your business requires pre-authorization holds on large amounts.
Micro-Transaction Detection (Card Testing)
- Amount threshold: Lower to
< 10or even< 1for stricter card testing detection. - Count threshold:
>= 5in 30 minutes is aggressive. Relax to>= 10if your users legitimately make many small purchases (e.g., vending machines, transit systems). - Time window:
"PT30M"catches rapid bursts. Extend to"PT1H"for slower-paced testing.
Cross-Border Transaction Flag
- Amount:
1000is a conservative threshold. Increase for high-volume cross-border businesses. - Metadata fields: Ensure your application sends
source_countryanddestination_countryin themeta_dataobject. - Score: Increase to
0.7+if your business rarely processes international transactions.
Velocity and Volume
High-Frequency Transactions to Same Destination
- Count:
> 10is moderate. Lower to> 5for stricter monitoring; raise to> 20for high-volume merchant accounts. - Amount gate: The
amount > 100condition filters out micro-transactions, reducing false positives from legitimate high-frequency, low-value payments.
Source Account High Outflow
- Sum threshold:
5000is conservative. Set based on your typical user’s daily spending. A fintech serving gig workers might use2000; a corporate treasury platform might use500000. - Time window:
"PT24H"is standard for daily limits. Use"PT1H"for near-real-time draining detection.
High-Value Velocity from Single Source
Repeated Identical Amounts
- Count:
> 2means 3+ identical amounts in an hour triggers the rule. Adjust based on your business — some retail scenarios legitimately have repeated amounts. - Time window:
"PT1H"is tight. Extend to"PT24H"to catch slower structuring patterns.
Behavioral Anomalies
Dormant Account Reactivation
- Dormancy period:
90days is standard. Lower to30for more aggressive detection. - Amount:
1000filters out small reactivation transactions (e.g., checking if the account still works). - Metadata requirement: Your application must include
days_since_last_transactionin the transaction’smeta_data.
New Account First-Day Activity
- Account age:
< 1day catches same-day activity. Extend to< 7for the critical first-week period. - Amount: Lower to
500for consumer platforms; raise for B2B. - Combine with velocity: Add
and count(when source == $current.source, "PT1H") > 3to catch rapid activity from new accounts.
Unusual Transaction Time
- Time range: Adjust for your users’ time zones. See the Time-Based Rules Guide for UTC offset considerations.
- Amount: Lower the threshold for higher sensitivity.
Late Night Transactions
Weekend Transaction on Business Account
- Add
and metadata.account_type == "business"to target only business accounts. - Add
and amount > 5000to focus on significant transactions.
Identity and KYC
Low KYC Daily Limits
- KYC tier: Adjust for your tier system. Create separate rules for each tier with different thresholds.
- Daily limit:
5000is illustrative. Set based on your regulatory requirements.
Low KYC High-Risk Activity
- Categories: Adjust the list based on your risk assessment. Replace with MCC codes if you have them.
- Score:
0.8is high. This is appropriate because the combination of low KYC and high-risk category is a strong signal.
Self-Transfer Detection
Sanctions and Compliance
Sanctioned Country Check
$sanctioned_countries) means the list can be updated without modifying the rule.
How to customize:
- Variable: Maintain
$sanctioned_countriesexternally. Update it whenever OFAC, EU, or UN sanctions lists change. - Verdict:
blockis non-negotiable for sanctions compliance. - Score:
1.0— maximum confidence.
High-Risk Destination Country
- Consider using
reviewinstead ofblockfor high-risk (non-sanctioned) countries. - The
$high_risk_countriesvariable can include FATF-listed jurisdictions.
Suspicious Description Patterns
- Pattern: Extend with additional keywords relevant to your market. Be careful not to make the pattern too broad — you don’t want to flag legitimate crypto exchanges.
- Amount gate:
1000filters noise. Lower for higher sensitivity. - Score:
0.2is low because description matching alone has high false-positive rates. Layer with other conditions for higher confidence.
Known Fraud Entity Check
- Use a variable (
$known_fraud_entities) rather than an inline list. This list changes frequently as new fraud accounts are identified. - Consider also checking
source in $known_fraud_entitiesfor inbound fraud detection.
Cryptocurrency Category Check
Foreign Currency Transaction
Sequential Patterns
Block After Previous Failure
- Time window:
"PT1H"is tight. Extend to"PT2H"or"PT4H"for broader coverage. - Amount:
700000is very high. Lower based on your typical transaction sizes. - Failed status: Ensure your system records failed transactions with
status: "failed".
Merchant-Issuer Country Mismatch
- Add
and amount > 500to filter out small international purchases (common for online shopping). - Combine with
and metadata.is_card_present == falseto focus on card-not-present (CNP) fraud.
Combining Recipes
The most effective fraud detection comes from layering multiple rules. Here’s a recommended starter set for a typical fintech platform:
Start with this set, monitor the verdicts for a week, tune the thresholds based on your false-positive and false-negative rates, and then add more specialized rules.
Next Steps
- Writing Your First Rule — Learn the rule authoring workflow from scratch.
- Conditions Deep Dive — Master every operator and condition type.
- Aggregate Functions Guide — Deep dive into velocity and volume detection.
- GitOps Rule Management — Deploy these recipes through your Git workflow.
- DSL Reference — Complete language specification.
.png?fit=max&auto=format&n=0JF6z69u57hmqsWm&q=85&s=531373acedba0eb783b669f6d558dfd8)