Skip to main content

​
Introduction

Transaction monitoring is gu1’s core capability for analyzing financial transactions in real-time. Our system allows you to detect fraud, ensure AML compliance, apply transaction limits, and identify suspicious patterns before they become major problems.

​
Key Features

Real-Time Analysis

Analyze transactions in < 500ms with instant decisions

Flexible Rules Engine

Create custom rules with sync and async execution modes

Intelligent Alerts

Automatic alert consolidation into actionable investigations

Multi-Currency

Native support for 150+ currencies with automatic conversion

Entity Resolution

Automatic linking of entities (users, merchants, accounts)

Compliance

Built-in compliance with AML/CFT regulations

​
Use Cases

​
1. Real-Time Fraud Detection

Detect and block fraudulent transactions before they’re processed:
  • Card testing
  • Account takeover
  • Impossible travel
  • Transaction velocity patterns
  • High-risk geographies
Learn more about fraud detection →

​
2. AML Monitoring

Ensure compliance with anti-money laundering regulations:
  • Structuring (Smurfing)
  • Layering patterns
  • High-risk countries (FATF)
  • PEPs (Politically Exposed Persons)
  • Large transaction reporting
Learn more about AML monitoring →

​
3. Transaction Limits

Enforce daily, weekly, and monthly limits:
  • Per-user limits
  • Per-merchant limits
  • By transaction type
  • By geography
  • Dynamic limits based on risk

​
4. Suspicious Patterns

Detect complex behavioral patterns:
  • Unusual transaction frequency
  • Atypical amounts
  • Geographic anomalies
  • Changes in transaction behavior
  • Correlation between multiple entities

​
5. Merchant Monitoring

For acquirers and sub-acquirers:
  • Chargeback monitoring
  • Merchant fraud
  • Phishing detection
  • Compliance with terms
  • Transaction velocity spikes
Learn more about merchant monitoring →

​
System Architecture

​
Transaction Processing Flow

​
Step 1: Validation

The system validates the transaction payload against strict schemas ensuring all required fields are present and correctly formatted.

​
Step 2: Entity Resolution

Origin and destination entities are resolved or created. This allows tracking transaction history and behavioral patterns.

​
Step 3: Currency Conversion

If the transaction is in a different currency than your base currency, automatic conversion is performed using real-time rates.

​
Step 4: Transaction Entity Creation

A transaction entity is created in the system with all relevant information including metadata, device data, and entity relationships.

​
Step 5: Sync Rules Execution

Synchronous rules are executed that can affect the transaction decision in real-time. These rules can:
  • Approve the transaction
  • Reject it
  • Put it on hold for review
  • Require additional authentication

​
Step 6: Async Rules Execution

Asynchronous rules are executed in parallel. These rules:
  • Don’t affect the transaction decision
  • Generate alerts for monitoring
  • Are used for pattern analysis
  • Feed the Intelligence Dashboard

​
Step 7: Response

The system returns a complete response including:
  • Decision (APPROVE, REJECT, HOLD, etc.)
  • Risk score
  • Alerts generated
  • Recommended actions
  • Execution metadata

​
Sync vs Async Rules

​
Synchronous Rules

When to use:
  • Need to block transactions in real-time
  • Enforce hard limits (amounts, frequency)
  • Detect critical fraud patterns
  • Regulatory requirements that prohibit transaction
Characteristics:
  • Execute during API call
  • Affect transaction decision
  • Return in API response
  • Performance target: < 100ms per rule
Example use case: 
If transaction amount > $10,000 AND user is unverified
Then REJECT transaction

​
Asynchronous Rules

When to use:
  • Pattern monitoring and analysis
  • Alerts that don’t require immediate action
  • Complex aggregations over time
  • Suspicious behavior detection
Characteristics:
  • Execute in parallel
  • Don’t affect transaction
  • Only appear in dashboard
  • Can perform complex queries
Example use case: 
If user has > 10 transactions in last hour
Then generate MEDIUM severity alert

​
Alert Generation and Consolidation

​
How Alerts Are Generated

Alerts are generated when:
  1. A rule is configured with generate_alert action
  2. The rule conditions are met
  3. The alert is created with specified severity

​
Automatic Consolidation

gu1’s consolidation engine automatically:
  • Groups related alerts into investigations
  • Identifies patterns across multiple alerts
  • Prioritizes based on severity and frequency
  • Assigns to appropriate teams

​
Integration with Intelligence

All alerts flow directly into the Intelligence Dashboard where:
  • Teams can collaborate on investigations
  • Complete context is available (entity history, related transactions)
  • Actions can be taken (accept, escalate, mark false positive)
  • Audit trail is automatically maintained

​
Next Steps

API Reference

Complete endpoint documentation

Rules Configuration

Learn to create and configure rules

Fraud Detection

Protect against fraud in real-time

AML Monitoring

Regulatory compliance and money laundering detection