Rules in Verisoul
Rules enable real-time, automated decision-making by defining conditions that trigger list actions. They form the dynamic component of your fraud prevention strategy, allowing you to automatically respond to fraud patterns as they emerge.Understanding Rules
Rules consist of three main components that work together to automate fraud prevention decisions:1. Triggers
Triggers define when a rule should be evaluated:| Trigger Type | Description | Use Case |
|---|---|---|
| First Session for Account | Evaluates only on the first session associated with an account | Account creation, initial signup screening |
| All Sessions | Evaluates on every session for an account | Ongoing monitoring, behavioral changes |
2. Conditions
Conditions define the filtering logic that determines when a rule should fire. Available Fields: You can use any field available in the Authenticate API response to create complex conditional logic. All fields on the account and session table in the dashboard are available to use in rules. Example fields include:- Account Data:
decision,account_score,bot,multiple_accounts - Session Data:
session.location.country_code,session.network.service_provider,session.proxy - Email Intelligence:
email.disposable,email.domain_type,email.email_score - Network Signals:
risk_signal_scores.proxy,risk_signal_scores.vpn, etc.
- AND: Fields from both account and session can be used
- OR: Currently OR cannot be nested inside an AND condition
- Numeric Operations: Scores are normalized to 0-100%
- String Operations: All string operations are case-insensitive
- List Operations:
is in,is not inCan also be used on string fields
3. Actions
Actions define what happens when a rule’s conditions are met:| Action Type | Description | Effect |
|---|---|---|
| Add to List | Adds the account to a specified list | Moves account according to list hierarchy |
| Remove from List | Removes the account from a specified list | Removes account from specified list only |
Rule Management and Versioning
Rule Versioning
- Immutable History: Every rule update creates a new version
- Audit Trail: Complete history of rule changes is maintained
- No Deletion: Rules can be archived but never permanently deleted
- Ledger System: Once a rule triggers for an account/session, it remains in the history forever
Rule States
| State | Description | Behavior |
|---|---|---|
| Enabled | Rule is active and evaluating | Processes all matching triggers |
| Disabled | Rule is inactive | No evaluation occurs, but history is preserved |
| Archived | Rule is retired | No longer visible in active rules, but history remains |
Rule Execution
Processing Characteristics:- Parallel Execution: Multiple rules can trigger simultaneously on the same API request
- Real-time Processing: Rules are evaluated synchronously with API requests
- Order Independence: Rules execute in parallel, not sequentially
- Conflict Resolution: When multiple rules affect the same account, all actions are processed together
List Movement Logic
Standard List Hierarchy
Rules respect the standard list hierarchy when adding accounts to lists:- Block → Main Account: ✅ Allowed
- Block → Allow: ✅ Allowed
- Main Account → Allow: ✅ Allowed
- Allow → Block: ❌ Not allowed via “add to list”
- Allow → Main Account: ❌ Not allowed via “add to list”
Simultaneous Add/Remove Operations
When both add and remove actions occur in the same API request:- All remove actions are processed first
- All add actions are processed second
- Final list membership reflects the net result
- Account is on Allow List
- Rule A: Remove from Allow List
- Rule B: Add to Block List
- Result: Account ends up on Block List
Common Use Cases
Email-Based Rules
- Block disposable email providers
- Allow trusted corporate domains
- Allow test accounts in development environments
Geographic Rules
- Block high-risk countries
- Allow specific regions
- Handle VPN/proxy detection
ISP and Network Rules
- Block risky internet service providers
- Allow certain corporate vpn IP’s