Fraud Investigation - Roe AI Documentation

Fraud Investigation Engine Overview

The Fraud Investigation Engine is an agentic workflow that investigates fraud alerts by analyzing transaction data, alert signals, and external intelligence. It evaluates evidence against your Standard Operating Procedures (SOPs), performs web research to verify external entities, and queries data warehouses to produce a comprehensive investigation with a clear verdict and recommended action.

Key Capabilities

Policy-Driven Analysis: Investigates alerts against your fraud investigation SOP guidelines
Fraud Classification: Categorizes fraud by scenario (what happened), actor (who did it), vector (how), and payment rail
Automated Evidence Collection: Uses web research and SQL queries to gather and cite evidence
Risk Signal Detection: Identifies high-risk signals and verification checks that passed from your SOP
Structured Verdicts: Produces investigation results with clear verdicts from your policy dispositions

Prerequisites

Before using the Fraud Investigation Engine, ensure you have:

A Fraud Investigation Policy: Create a policy containing your fraud investigation SOP with guidelines, red flag criteria, and disposition options. See Policies for setup instructions.
Context Sources (Recommended): Configure data connectors (Snowflake, ClickHouse, or Zendesk) to allow the agent to query transaction history and customer data. See Data Connectors.

Fraud Investigation Engine Inputs

The Fraud Investigation Engine Configuration has four parameters:

Parameter	Required	Description
policy_version_id	Yes	The Policy version ID containing your fraud investigation guidelines (SOP)
context_sources	No	Data sources (e.g., Snowflake, Zendesk) for the agent to query transaction and customer data during investigation
alert_data	Yes	Alert data that triggered this investigation (JSON string with alert details)
transaction_data	No	Pre-loaded transaction data (JSON string). If empty, the agent will fetch from context sources

See Template Strings for dynamic parameter configuration.

Fraud Investigation Output

The output is a structured JSON object containing:

Policy Applied

Information about the policy used for investigation:

name: Name of the policy applied
version: Version ID of the policy applied

Customer Profile

Customer information gathered during the investigation:

Field	Description
`account_id`	Customer’s account identifier
`email`	Customer’s email address
`name`	Customer’s full name
`phone`	Customer’s phone number
`location`	Customer’s location (city, state, country or IP-based geolocation)
`devices`	Devices associated with the customer (e.g., “iPhone 14”, “Android”)
`product`	Product or service the customer is using
`accounts`	List of account types or linked accounts
`kyc_status`	KYC verification status including provider and verification method

Fraud Analysis

Complete investigation result including:

Field	Description
`verdict`	Final verdict from policy dispositions (e.g., “False Positive”, “Needs Review”)
`summary`	Markdown executive summary with inline evidence references using $REF_X$ markers
`summary_evidences`	Array of evidence objects corresponding to $REF_X$ markers in the summary
`rail`	Payment method used (wire, ach, check, card_present, card_not_present, zelle_rtp)
`scenario`	Fraud typology if fraud is suspected (e.g., account_takeover, scam_investment)
`actor`	Who committed the fraud (third_party, first_party, second_party, internal_employee)
`vectors`	Attack vectors used (e.g., phishing_link, credential_stuffing, sim_swap)
`high_risk_signals`	Array of detected risk signals with evidence
`checks_passed`	Array of verification checks that passed with evidence
`action_recommendation`	Recommended action with reasoning

Risk Signal Structure

Each risk signal includes:

signal_name: Clear, concise name of the risk signal
reasoning: One sentence explanation of the key finding
evidences: Array of evidence supporting this finding

Checks Passed Structure

Each check passed includes:

check_name: Clear, concise name of the check passed
reasoning: One sentence explanation of the key finding
evidences: Array of evidence supporting this finding

Evidence Structure

Each piece of evidence includes:

evidence_type: “web_link”, “screenshot”, or “artifact”
evidence_data: URL or artifact reference
evidence_name: Short descriptive name
evidence_description: Why this evidence is relevant

Action Recommendation Structure

Field	Description
`suggested_action`	One of: `clear_alert`, `escalate`, or `lock_account`
`reasoning`	Explanation for why this action is suggested over others

Fraud Classification Taxonomy

The Fraud Investigation Engine uses a structured taxonomy to classify fraud:

Fraud Scenarios (The “What”)

Scenario	Description
account_takeover	Unauthorized access to an existing account
new_account_fraud	Synthetic or stolen identity used at onboarding
card_testing	High velocity small authorizations
scam_impersonation	Bank/government impostor scams
scam_investment	Crypto/pig butchering investment scams
scam_romance	Romance-based fraud schemes
first_party_abuse	”Friendly fraud” / refund abuse
mule_activity	Receiving stolen funds
structuring	Smurfing to avoid reporting limits

Fraud Actors (The “Who”)

Actor	Description	Liability
third_party	External criminal	Bank Liability
first_party	Customer themselves	Customer Liability
second_party	Mule/Collusion	Shared Liability
internal_employee	Insider threat	Bank Liability

Attack Vectors (The “How”)

Vector	Type	Description
credential_stuffing	Technical	Reusing passwords from breaches
malware_bot	Technical	Automated malicious software
sim_swap	Technical	Phone number hijacking
man_in_the_middle	Technical	Intercepting communications
phishing_link	Social	Clicked malicious link
vishing_call	Social	Fraudulent phone call
document_forgery	Social	Fake ID or documents
check_washing	Social	Chemically altering checks

Payment Rails (The “Vehicle”)

Rail	Description
wire	Wire transfer
ach	ACH transfer
check	Check payment
card_present	In-person card transaction
card_not_present	Online/remote card transaction
zelle_rtp	Zelle or real-time payments

Policy (SOP) Structure

Your fraud policy should contain:

Instructions: High-level investigation guidance for fraud detection
Guidelines: Organized as Categories > Rules
- Each Category contains multiple Rules
- Each Rule has a flag type (GREEN_FLAG or RED_FLAG), title, and description
Dispositions: Classification options for final verdicts

Supported Context Sources

The Fraud Investigation Engine supports the following data source connectors:

Connector	Type	Description
Snowflake	SQL	Query your Snowflake data warehouse for transaction history, customer data, device logs, etc.
ClickHouse	SQL	Query ClickHouse for high-performance analytics on transaction data
Roe Tables	SQL	Query tables stored in VolansDB for internal data analysis
Zendesk	API	Fetch support tickets and customer communication history

Configure context sources to allow the agent to automatically fetch transaction and customer data during investigation. The agent uses an iterative SQL querying strategy—first discovering the schema, then verifying entity columns, before running aggregated queries.

Creating a Fraud Policy

Fraud investigation requires a policy containing your Standard Operating Procedures (SOP). You can create policies using the Policies feature.

A pre-built Fraud Investigation Workflow policy template is available in the platform. This template provides a comprehensive framework for alert review, typology assessment, evidence synthesis, and decision labels.

Example Alert Data

{
  "alert_id": "FRD-2024-005678",
  "account_id": "ACC-123456",
  "customer_name": "John Smith",
  "customer_email": "[email protected]",
  "alert_type": "ACCOUNT_TAKEOVER_SUSPECTED",
  "alert_date": "2024-01-20",
  "triggered_by": "Multiple failed login attempts followed by password reset from new device",
  "risk_score": 85,
  "device_info": {
    "device_id": "DEV-789",
    "device_type": "Android",
    "ip_address": "203.0.113.45",
    "geolocation": "Lagos, Nigeria"
  },
  "transaction_summary": {
    "attempted_transfer": 5000.00,
    "recipient": "Unknown Wallet",
    "payment_method": "wire"
  }
}

Example Output

{
  "policy_applied": {
    "name": "Fraud Investigation SOP v3",
    "version": "pol_ver_xyz789"
  },
  "customer_profile": {
    "account_id": "ACC-123456",
    "email": "[email protected]",
    "name": "John Smith",
    "phone": "+1-555-0123",
    "location": "New York, NY",
    "devices": ["iPhone 14 Pro", "MacBook Pro"],
    "product": "Premium Checking",
    "accounts": ["checking", "savings"],
    "kyc_status": {
      "verified": true,
      "last_verified": "2023-06-15",
      "provider": "Persona",
      "verification_method": "Selfie, ID Upload"
    }
  },
  "fraud_analysis": {
    "verdict": "highly_suspected",
    "summary": "Investigation of account takeover alert for customer ACC-123456. The alert flagged suspicious login activity from an unrecognized device.\n\n**Red Flags:**\n- **New device from Nigeria** detected, inconsistent with customer's US-based transaction history $REF_1$\n- **5 failed login attempts** before successful authentication via password reset $REF_2$\n- **Attempted $5,000 wire transfer** to unknown wallet immediately after access $REF_3$\n\n**Green Flags:**\n- Customer has **verified KYC status** with Persona $REF_4$\n\nStrong evidence of third-party account takeover via credential compromise. Immediate account protection recommended.",
    "summary_evidences": [
      {
        "id": "REF_1",
        "evidence_type": "artifact",
        "evidence_data": "FraudInvestigationEngine-456/sql_query_device_history.json",
        "evidence_name": "Device geolocation analysis",
        "evidence_description": "Customer's previous 50 logins were all from New York; this login originated from Nigeria"
      },
      {
        "id": "REF_2",
        "evidence_type": "artifact",
        "evidence_data": "FraudInvestigationEngine-456/sql_query_login_attempts.json",
        "evidence_name": "Login attempt logs",
        "evidence_description": "5 failed password attempts within 3 minutes before password reset request"
      },
      {
        "id": "REF_3",
        "evidence_type": "input",
        "evidence_data": "alert_data",
        "evidence_name": "Wire transfer attempt",
        "evidence_description": "Attempted wire of $5,000 to unregistered recipient within 10 minutes of account access"
      },
      {
        "id": "REF_4",
        "evidence_type": "artifact",
        "evidence_data": "FraudInvestigationEngine-456/sql_query_kyc_status.json",
        "evidence_name": "KYC verification record",
        "evidence_description": "Customer completed identity verification in June 2023"
      }
    ],
    "rail": "wire",
    "scenario": "account_takeover",
    "actor": "third_party",
    "vectors": ["credential_stuffing"],
    "high_risk_signals": [
      {
        "signal_name": "Geolocation Anomaly",
        "reasoning": "Login from Nigeria when customer history shows exclusively US-based activity.",
        "evidences": [
          {
            "evidence_type": "artifact",
            "evidence_data": "FraudInvestigationEngine-456/sql_query_device_history.json",
            "evidence_name": "Device location history",
            "evidence_description": "All 50 previous logins from New York area"
          }
        ]
      },
      {
        "signal_name": "Password Reset After Failed Attempts",
        "reasoning": "Classic account takeover pattern—multiple failed attempts followed by password reset.",
        "evidences": [
          {
            "evidence_type": "artifact",
            "evidence_data": "FraudInvestigationEngine-456/sql_query_login_attempts.json",
            "evidence_name": "Authentication logs",
            "evidence_description": "5 failed attempts then password reset in 3-minute window"
          }
        ]
      }
    ],
    "checks_passed": [
      {
        "check_name": "KYC Verification Valid",
        "reasoning": "Customer completed identity verification through Persona with selfie and ID upload.",
        "evidences": [
          {
            "evidence_type": "artifact",
            "evidence_data": "FraudInvestigationEngine-456/sql_query_kyc_status.json",
            "evidence_name": "KYC record",
            "evidence_description": "Verified June 2023 via Persona"
          }
        ]
      }
    ],
    "action_recommendation": {
      "suggested_action": "lock_account",
      "reasoning": "Strong evidence of third-party account takeover with attempted fund transfer. Immediate account lock prevents further unauthorized access and protects customer funds."
    }
  }
}

Action Recommendations

Based on the verdict, the engine recommends one of three actions:

Action	When to Use
clear_alert	Verdict is `false_positive`—no further action needed
escalate	Verdict is `needs_review`—requires human analyst review or additional context
lock_account	Verdict is `highly_suspected`—immediate protective action to prevent losses

Use Cases

The Fraud Investigation Engine is designed for:

Account Takeover Alerts: Investigate suspicious login patterns, device changes, or credential compromise
Transaction Fraud Alerts: Analyze unusual transaction patterns, velocity anomalies, or suspicious recipients
New Account Fraud: Investigate synthetic identity or application fraud signals
Scam Detection: Identify investment scams, romance scams, or impersonation attempts
Chargeback Investigation: Investigate disputes and determine first-party vs. third-party fraud
Mule Account Detection: Identify accounts receiving or laundering stolen funds

Best Practices

Define Clear SOPs

Create comprehensive fraud investigation policies with specific criteria for each verdict level

Connect Multiple Data Sources

Configure SQL and Zendesk context sources to give the agent access to transaction history, device logs, and customer communications

Structure Alert Data

Include all relevant identifiers (account ID, device info, IP, transaction details) in your alert data for thorough investigation

Review Dispositions

Define clear disposition classifications in your policy for consistent verdict assignment

Get Started

Agents

VolansDB

Data Resources

Policies

Webhooks

Enterprise

Use Cases

​Fraud Investigation Engine Overview

​Key Capabilities

​Prerequisites

​Fraud Investigation Engine Inputs

​Fraud Investigation Output

​Policy Applied

​Customer Profile

​Fraud Analysis

​Risk Signal Structure

​Checks Passed Structure

​Evidence Structure

​Action Recommendation Structure

​Fraud Classification Taxonomy

​Fraud Scenarios (The “What”)

​Fraud Actors (The “Who”)

​Attack Vectors (The “How”)

​Payment Rails (The “Vehicle”)

​Policy (SOP) Structure

​Supported Context Sources

​Creating a Fraud Policy

​Example Alert Data

​Example Output

​Action Recommendations

​Use Cases

​Best Practices

Define Clear SOPs

Connect Multiple Data Sources

Structure Alert Data

Review Dispositions

​Related Resources

Policies

Data Connectors

AML Investigation

Fraud Investigation Engine Overview

Key Capabilities

Prerequisites

Fraud Investigation Engine Inputs

Fraud Investigation Output

Policy Applied

Customer Profile

Fraud Analysis

Risk Signal Structure

Checks Passed Structure

Evidence Structure

Action Recommendation Structure

Fraud Classification Taxonomy

Fraud Scenarios (The “What”)

Fraud Actors (The “Who”)

Attack Vectors (The “How”)

Payment Rails (The “Vehicle”)

Policy (SOP) Structure

Supported Context Sources

Creating a Fraud Policy

Example Alert Data

Example Output

Action Recommendations

Use Cases

Best Practices

Related Resources