Introduction
gu1’s rules engine allows you to create custom logic to analyze transactions in real-time. Rules can be synchronous (affect transaction decision) or asynchronous (monitoring only).Sync vs Async Rules
Synchronous Rules (SYNC)
Execute during API call and affect transaction decision When to use:- Block fraudulent transactions
- Enforce transaction limits
- Require additional authentication
- Regulatory requirements
- Evaluated before response
- Can change transaction state
- Performance target: < 100ms
- Limited to lightweight operations
Asynchronous Rules (ASYNC)
Execute in parallel without affecting transaction When to use:- Pattern monitoring
- Behavioral analysis
- Complex aggregations
- Historical analysis
- Don’t block API response
- Can perform heavy queries
- Generate alerts only
- Feed Intelligence Dashboard
Rule Structure
Configuration Fields
Basic Fields
| Field | Type | Description |
|---|---|---|
name | string | Rule name (unique) |
category | string | Category: fraud, aml, compliance, risk |
priority | number | Execution priority (1-1000, higher = first) |
enabled | boolean | Enable/disable rule |
evaluationMode | string | ”sync” or “async” |
targetEntityTypes | array | Entity types to evaluate ([“transaction”]) |
Conditions
Rules use a flexible conditions system:Condition Operators
| Operator | Description | Example |
|---|---|---|
EQUALS | Exact equality | "type" EQUALS "PAYMENT" |
NOT_EQUALS | Not equal | "status" NOT_EQUALS "blocked" |
GREATER_THAN | Greater than | "amount" > 1000 |
GREATER_THAN_OR_EQUAL | Greater or equal | "amount" >= 1000 |
LESS_THAN | Less than | "amount" < 100 |
LESS_THAN_OR_EQUAL | Less or equal | "amount" <= 100 |
IN | In list | "country" IN ["US", "CA"] |
NOT_IN | Not in list | "country" NOT_IN ["KP", "IR"] |
CONTAINS | String contains | "description" CONTAINS "test" |
NOT_CONTAINS | String doesn’t contain | "email" NOT_CONTAINS "@temp" |
STARTS_WITH | String starts with | "accountId" STARTS_WITH "4532" |
ENDS_WITH | String ends with | "domain" ENDS_WITH ".ru" |
REGEX | Regex match | "email" REGEX "^[a-z]+@" |
EXISTS | Field exists | "metadata.userId" EXISTS |
NOT_EXISTS | Field doesn’t exist | "referralCode" NOT_EXISTS |
Available Transaction Fields
Actions
Rules can trigger multiple actions:1. Generate Alert
2. Set Decision (SYNC only)
3. Create Investigation
Example Rules
1. Daily Transaction Limit (SYNC)
2. Transaction Velocity Alert (ASYNC)
3. High-Risk Country Block (SYNC)
4. Structuring Pattern Detection (ASYNC)
5. New Card High Amount (SYNC)
6. Unusual Time Pattern (ASYNC)
Advanced Conditions
Nested Conditions
Regex Patterns
Time-Based Aggregations
Best Practices
✅ DO
-
Use appropriate evaluation mode
- SYNC for decisions that must block
- ASYNC for monitoring and analysis
-
Set correct priorities
- Critical blocks: 900-1000
- Standard checks: 500-899
- Monitoring: 100-499
-
Include meaningful messages
- Use template variables:
{{field}} - Provide context for analysts
- Include relevant metrics
- Use template variables:
-
Test thoroughly
- Start with ASYNC mode
- Monitor false positive rate
- Adjust thresholds based on data
-
Use metadata fields
- Aggregate data for patterns
- Track historical behavior
- Calculate risk scores
❌ DON’T
-
Don’t use heavy queries in SYNC rules
- Keep SYNC rules fast (< 100ms)
- Move complex logic to ASYNC
-
Don’t over-block
- Start with HOLD instead of REJECT
- Allow for manual review
- Monitor customer impact
-
Don’t create overlapping rules
- One rule should handle one pattern
- Use priorities correctly
- Avoid redundant checks
-
Don’t ignore false positives
- Track and analyze
- Adjust thresholds
- Use machine learning when available
Testing Rules
Test Mode
Enable test mode to evaluate rules without affecting transactions:A/B Testing
Create variant rules to compare effectiveness:Monitoring Metrics
Track for each rule:- Execution count: How often rule runs
- Match rate: % of times conditions met
- False positive rate: Incorrectly flagged
- True positive rate: Correctly flagged
- Average execution time: Performance