Verification & Triage Guide

When a fraud report enters the system: whether submitted by a user, auto-generated by the domain engine, or ingested from an external feed: it starts in Pending status and must move through a verification pipeline before it affects risk scores or the public threat feed.

This guide explains the full verification workflow, what to look for at each stage, and how to use the domain rule engine to configure detection logic.

The Verification Pipeline

Submitted
    │
    ▼
Pending ──── No action yet ────── visible to all analysts
    │
    ▼
In Review ── Analyst assigned ─── risk score not yet updated
    │
    ├──► Verified ─── risk score updated, enters threat feed
    │
    ├──► Rejected ─── false positive, no further action
    │
    └──► Disputed ─── conflicting signals, escalate

State Definitions

State	Who Sets It	What It Means
Pending	Auto	Newly submitted, no analyst has touched it yet
In Review	Analyst	You've claimed it and are actively investigating
Verified	Analyst / Admin	Confirmed threat: wallet score updated, domain monitored
Rejected	Analyst / Admin	False positive or insufficient evidence
Disputed	Analyst / Admin	Conflicting signals; needs a second opinion

Accessing Fraud Reports

1. Navigate to Fraud Intelligence in the left sidebar
2. Use the filter controls to find reports in Pending status
3. Sort by submission date or risk score to prioritize the queue

Admins can also manage the full queue from Admin → Fraud which provides bulk-action controls.

Triage Workflow (Step by Step)

Step 1: Initial Assessment

When you open a report, first check:

Check	What to Look For
Wallet address format	Valid XRP r-address starting with r
Scam type	Does it match the description provided?
Submission source	User-submitted vs auto-generated vs Intel feed
Evidence quality	Are there screenshots, transaction IDs, or domain links?

For auto-generated reports (source: "domain engine" or "intel feed"), the evidence is machine-generated and typically reliable but should still be reviewed.

Step 2: Verify the Wallet

1. Click the wallet address link to open Wallet Analysis in a new pane
2. Check the risk score and existing signals: is this a new report on an already-known wallet, or a first report?
3. Review the Signals tab:
   • reported_fraud signal already present? Multiple reports confirm the pattern
   • linked_to_phishing_domain? Cross-reference the domain in the report
   • rapid_tx or round_amount? Consistent with scam patterns
4. Review the Fund Flow tab: does the XRP movement match the described fraud type?
5. Check the Network Graph: is this wallet connected to other known-bad wallets?

Step 3: Verify the Domain (if applicable)

If the report includes a domain:

1. Navigate to Domains and search for it
2. Check which detection rules triggered
3. Review enrichment data: domain age, registrar, SSL certificate
4. If the domain is not yet in the system, an admin can add it via Admin → Domains → Add Domain

Step 4: Make a Decision

Finding	Action
Clear evidence, wallet behaving like the described fraud type	→ Verified
Evidence is thin but signals point to fraud	→ In Review, investigate further
Submitted wallet is known-benign (e.g. exchange hot wallet)	→ Rejected
One signal says fraud, another says benign	→ Disputed

Step 5: Apply the Verdict

• Click Verify to confirm the report
  • The wallet's risk score is recalculated immediately with the new report weight
  • If the score crosses the threshold, the wallet is added to Flagged Wallets
  • Webhook subscribers receive an indicator_updated event
• Click Reject to dismiss: score is not affected
• Click Dispute to flag for escalation: assign to senior analyst if available

What Happens After Verification

Once a report is Verified:

1. Risk score update: the reported_fraud signal is applied, typically adding 20–30 points to the wallet's sub-score
2. Threat feed: the wallet appears (or is updated) in GET /threat-feed/wallets
3. Domain monitoring: any associated domain is added to the monitored domains list
4. Webhook event: indicator_added or indicator_updated fires to all subscribers
5. Admin audit log: the verification action is recorded with analyst name and timestamp

Domain Rule Engine: Configuration Guide

The Domain Rule Engine runs automatically but is configurable. Rules define what patterns trigger detection. Mis-configured rules lead to either missed threats (too permissive) or false positives (too strict).

Accessing the Rule Editor

Admin → Domain Rules (or navigate via the sidebar).

Recommended Starting Configuration

For teams new to the platform, enable these rule sets first:

Priority	Rules to Enable First
High	brand_abuse_tld_squatting, financial_fraud_action_keywords, tld_abuse_high_risk
Medium	typosquatting_hyphenated, xaman_wallet_phishing, compound_keywords
Low	executive_impersonation_garlinghouse

Start conservative. Enable additional rules after reviewing any false positives from the initial batch.

Tuning a Rule

When a rule generates too many false positives:

1. Open the rule in the editor
2. Lower its risk contribution: the rule still fires, but contributes less to the total score
3. Narrow the pattern: make the regex or keyword more specific
4. Disable auto-flag: the rule matches but doesn't immediately flag the domain; requires it to also pass other score thresholds

When a known-bad pattern keeps slipping through:

1. Check which rules are enabled: the pattern might not be covered
2. Add a new rule targeting the specific pattern (keyword, regex, TLD combination)
3. Test it with the Test button against a known-good domain to confirm no false positives
4. Enable it and monitor the Domains feed for new matches

Testing a Rule Before Enabling

1. Click Test next to any rule
2. Enter a domain name (try both a known-scam domain and a known-legitimate domain)
3. The test shows whether the condition matches and what contribution it would add
4. Only enable the rule if it matches scam domains and misses legitimate ones

Adding a Custom Rule

1. Click Add Rule
2. Choose a Condition Type (see Domain Detection Rules for all 15 types)
3. Set the Pattern appropriate for that condition type:
   • domain_contains: enter the substring (e.g. giveaway)
   • domain_regex: enter a valid regex (e.g. xrp[-_]?(claim|free|double))
   • tld_match: enter a comma-separated list (e.g. .top,.xyz,.click)
4. Set the Risk Contribution (0–100): be conservative with new rules, start at 20–30
5. Leave Auto-flag off for new rules until you've confirmed accuracy
6. Click Save and monitor results

Rule Interaction

Rules are additive: a domain that matches 3 rules gets all three contributions added to its Rule Matches sub-score. A domain matching rules worth 30 + 20 + 15 gets a sub-score of 65 (out of 100) for the rules component, which then feeds into the final weighted score.

There is no AND logic between rules: each rule fires independently. Complex AND conditions should be implemented as a single domain_regex rule with multiple lookaheads.

Common Investigation Patterns

Pattern: Multiple reports, same wallet

If you see 3+ reports on the same wallet from different users:

• This is a strong signal of an active scam campaign
• Verify all reports as a batch
• Use Network Graph to find connected wallets that may also need reporting
• Consider submitting wallets in the network to the Blacklist via Admin → Blacklist

Pattern: Fresh domain, no direct reports yet

A domain scored HIGH by the engine but no user reports yet:

• Check if any wallets are linked to it (Domains → detail view → Associated Wallets)
• If linked wallets have suspicious patterns, submit a fraud report linking wallet + domain
• This creates a cross-validated signal: domain engine + human report

Pattern: Disputed report

When a report is disputed:

• Assign to a second analyst
• Use the API to pull full wallet transaction history: GET /wallets/{blockchain_id}/{address}
• Check for the wallet on ChainAbuse or other external feeds
• If still unclear after 72 hours, default to monitoring (watchlist) rather than verification or rejection

Audit Trail

Every action in the verification pipeline is logged in Admin → Logs:

• Who changed the status
• What the previous status was
• Timestamp
• Any attached notes

This provides a full audit trail for compliance and dispute resolution.

Related topics

• Fraud Intelligence
• Domain Detection Rules
• Wallet Analysis
• Admin Panel