Guardian Engine
The fraud detection engine that powers your protection
Guardian Stack's server API transforms raw browser signals into actionable fraud intelligence. When your client calls guardian.get(), our processing engine analyzes hundreds of signals to detect bots, VPNs, browser tampering, and sophisticated fraud attempts.
How Server Processing Works
The magic happens server-side where we can safely perform intensive analysis without impacting user experience or exposing detection logic to potential attackers.

👉 See Guardian in action, Get started for free: Sign up and get your API keys
Complete Event Response Structure
Core Identification
Fraud Detection Usage:
id- Reference this in your fraud logs and dispute resolutionip- Cross-reference with your existing IP reputation listslocation- Flag geographic anomalies (user in US, IP in Russia)browser- Detect impossible browser configurations
Bot Detection Analysis
What This Means for Fraud:
detected: true→ Almost certainly automated traffic. Recommended action: BLOCKscore > 80→ Very high bot probability. Consider challenging or blockingscore 40-80→ Suspicious but inconclusive. Add friction or monitorautomationSignalsPresent: true→ Definitive automation tools detected
Common Bot Indicators You'll See:
webdriver→ Selenium automation (credential stuffing, account creation bots)headless_chrome→ Headless browser (scraping, automated purchases)puppeteer→ Advanced automation (sophisticated fraud attempts)
IP Intelligence Deep Dive
Critical Fraud Signals:
is_datacenter: true→ Traffic from hosting providers (bots, farms)is_tor: true→ Maximum anonymity seeking (high fraud correlation)is_abuser: true→ IP has fraud history across the internetcompany.type: "hosting"→ Not residential internet (suspicious for consumers)
Risk Assessment Guide:
VPN Detection Engine
Fraud Detection Intelligence:
detected: true→ User hiding real location (why?)timezoneDifference > 6→ Major geographic inconsistencyconfidence: "high"→ Very likely VPN usage
Fraud Context Matters:
Browser Tampering Detection
What Tampering Means:
detected: true→ Browser has been modified to avoid detectionantiDetectBrowser: true→ Professional fraud tools detectedanomalyScore > 0.7→ Major inconsistencies in browser environment
Tampering = Fraud Intent:
Users don't accidentally modify browsers
Tampering tools are expensive and specialized
High correlation with fraud attempts
Key Indicators:
vendor_mismatch→ Browser claims to be Chrome but acts like Firefoxcanvas_spoofing→ Artificial fingerprint to avoid trackingwebgl_anomalies→ Graphics inconsistencies (virtual environments)
Privacy Settings vs. Fraud
The Privacy Dilemma:
Legitimate privacy users → Ad blockers, privacy browsers, VPNs for safety
Fraud actors → Same tools to avoid detection
Smart Fraud Detection:
Virtualization Red Flags
Why VMs Matter for Fraud:
Scalability → Easy to spin up hundreds of fraud instances
Isolation → No risk to fraudster's real machine
Throwaway → Delete evidence after attack
VM Detection = High Fraud Risk:
Consumer users rarely run VMs for browsing
Professional fraud operations always use VMs
Combined with other signals = almost certain fraud
Incognito Detection Intelligence
Incognito Fraud Context:
By itself → Normal privacy behavior
With VPN + new account → Avoiding identification
With bot signals → Automated incognito sessions
Request IP Velocity Intelligence
What it is: Number of requests from the same IP (scoped to your
siteKeywhen provided) within rolling 5-minute, 1-hour, and 24-hour windows.How it's computed:
Server-side counts within [now − window, now].
Includes the current event (+1), so first-ever event yields at least 1.
Uses server time; not affected by client timezones.
Why it matters: Sudden spikes strongly correlate with automation, credential stuffing, scraping, and abuse.
Default High-Risk Thresholds
5m ≥ 25 OR 1h ≥ 150 OR 24h ≥ 1000 → high velocity
Fraud Detection Usage
High burst traffic: Treat as a strong indicator of automation.
Per-site scope: When
siteKeyis present, velocity is computed per site; otherwise global per IP.Noise considerations:
Popular endpoints can have legitimate spikes; combine with bot, datacenter, or tampering signals for confidence.
Logged-in returning users with high velocity may be power users; tune responses accordingly.
Recommended Actions
Block when high velocity co-occurs with any of:
Datacenter IP, TOR, known abuser IP
Bot indicators or browser tampering
Challenge when high velocity is isolated but the user is new/anonymous
Allow but monitor for high velocity from known, low-risk customers
Here are the docs for Visitor Velocity Intelligence that you can copy:
Visitor Velocity Intelligence
What it is: Number of requests from the same visitorId (scoped to your siteKey when provided) within rolling 5-minute, 1-hour, 24-hour, and 7-day windows.
How it's computed:
Server-side counts within [now − window, now].
Includes the current event (+1), so first-ever event yields at least 1.
Uses server time; not affected by client timezones.
Only computed when a
visitorIdis available.
Why it matters: Tracks request patterns per stable visitor identity, catching automation, credential stuffing, and abuse even when the attacker rotates IPs. Complements IP-based velocity to detect account-level or device-level spikes.
Compared to Request Velocity:
velocity: Counts by IP address (may aggregate many visitors behind NAT/proxies).visitorVelocity: Counts by stablevisitorId(resilient to IP rotation for the same visitor).
Suggested High-Risk Thresholds
5m ≥ 10 OR 1h ≥ 60 OR 24h ≥ 500 OR 7d ≥ 2000 → high visitor velocity
Fraud Decision Framework
Immediate Block Scenarios
Challenge/Additional Verification
We also offer our server-side SDK which includes many helper functions to save time in destructuring the event data.
👉 Stop fraud before it costs you, Get started for free: Sign up and get your API keys
Last updated
Was this helpful?
