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.
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?
