Skip to main content

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
Characteristics:
  • Evaluated before response
  • Can change transaction state
  • Performance target: < 100ms
  • Limited to lightweight operations
Example:

Asynchronous Rules (ASYNC)

Execute in parallel without affecting transaction When to use:
  • Pattern monitoring
  • Behavioral analysis
  • Complex aggregations
  • Historical analysis
Characteristics:
  • Don’t block API response
  • Can perform heavy queries
  • Generate alerts only
  • Feed Intelligence Dashboard
Example:

Rule Structure

Configuration Fields

Basic Fields

Conditions

Rules use a flexible conditions system:

Condition Operators

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

  1. Use appropriate evaluation mode
    • SYNC for decisions that must block
    • ASYNC for monitoring and analysis
  2. Set correct priorities
    • Critical blocks: 900-1000
    • Standard checks: 500-899
    • Monitoring: 100-499
  3. Include meaningful messages
    • Use template variables: {{field}}
    • Provide context for analysts
    • Include relevant metrics
  4. Test thoroughly
    • Start with ASYNC mode
    • Monitor false positive rate
    • Adjust thresholds based on data
  5. Use metadata fields
    • Aggregate data for patterns
    • Track historical behavior
    • Calculate risk scores

❌ DON’T

  1. Don’t use heavy queries in SYNC rules
    • Keep SYNC rules fast (< 100ms)
    • Move complex logic to ASYNC
  2. Don’t over-block
    • Start with HOLD instead of REJECT
    • Allow for manual review
    • Monitor customer impact
  3. Don’t create overlapping rules
    • One rule should handle one pattern
    • Use priorities correctly
    • Avoid redundant checks
  4. 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

Next Steps

Fraud Detection

Production-ready fraud rules

AML Monitoring

AML compliance rules

Merchant Monitoring

Merchant risk rules

API Reference

Complete API documentation

Custom lists API

Create lists and items for in_custom_list and related operators