Fraud Detection at the Edge: Cloudflare Workers + tracio.ai

Traditional fraud detection happens at the application layer: the request arrives at your server, you query your fraud detection API, wait for the response, and then decide whether to allow or block. This round-trip adds 50-200ms of latency to every request — acceptable for page loads, but painful for API endpoints, AJAX calls, and real-time interactions.

What if you could make the fraud decision before the request reaches your origin server? That is what edge computing enables, and Cloudflare Workers is the platform we use to demonstrate this pattern.

The Architecture

The setup has three components: the tracio.ai JS SDK (@tracio/sdk) running in the browser, a Cloudflare Worker sitting between the client and your origin, and signed tracio.ai webhooks delivering full signal analysis to your backend.

The flow works like this: The JS SDK collects device signals and sends them to tracio.ai during page load, returning a visitorId to the browser. Your backend receives the full identification result — bot classification, smart signals, confidence — via a signed webhook and writes the verdict into an edge cache. The browser includes the visitorId in subsequent API requests (via header or cookie). The Cloudflare Worker intercepts each request, looks up the cached verdict for that visitorId, and makes an allow/block decision in under 5ms.

Worker Implementation

The Worker maintains a lightweight cache of recent device verification results using Cloudflare's KV storage, populated by your backend as signed tracio.ai webhooks arrive. When a request arrives with a visitorId header, the Worker checks the cache. If the verdict is cached and the visitor is clean (low bot score, no VPN, confidence above threshold), the request passes through immediately. If no verdict is cached yet, the Worker applies your fallback policy — pass with a conservative rate limit, or challenge — until the webhook-driven cache catches up.

The critical insight is that the verification cache is populated proactively. The first page load triggers signal collection and caches the result. All subsequent API calls from that visitor hit the cache — no round-trip to tracio.ai needed. Cache TTL is configurable; we recommend 5 minutes for high-security endpoints and 30 minutes for general content.

Performance Numbers

We benchmarked this architecture with a customer processing 50,000 requests per minute through Cloudflare Workers. Results:

Cache hit rate: 94% (most requests are from visitors who already loaded a page). Edge decision latency (cache hit): 1.2ms median, 3.8ms p99. Edge decision latency (cache miss): 45ms median (includes API call to tracio.ai). Origin latency savings: 120ms median per request (eliminated server-side fraud check).

The 94% cache hit rate means that 94% of fraud decisions happen in under 4ms at the edge, with no origin involvement. The remaining 6% are first-visit requests that require a full API round-trip.

Blocking Strategies

The Worker supports three blocking strategies, configurable per route:

Hard block: Return 403 immediately for high-risk visitors (bot score > 90 on the 0..100 payload-v2 scale, known automation framework). Soft block: have the Worker attach its own header — X-Risk-Score, or whatever name your origin expects — and let the origin decide. The header is yours, not ours: the platform's own X-Tracio-* headers belong to webhook delivery and are not part of this path. This is useful when you want application-level context for the decision. Challenge: Redirect suspicious visitors (moderate bot score, VPN detected) to a challenge page that requires additional verification.

We recommend starting with soft blocking in production, monitoring the risk distribution for a week, and then enabling hard blocking for clear-cut cases (known bots, headless browsers, high-confidence automation).

Cost Analysis

Cloudflare Workers pricing is based on requests and compute time. At 50K requests/minute (2.16 billion/month), the Worker cost is approximately $500/month. Compare this to the latency savings: eliminating 120ms of origin-side fraud checking reduces server CPU usage by 15-20%, which typically saves more than the Worker cost in compute.

The real value is in fraud prevention: catching bots and fraudulent requests before they consume origin resources, database connections, and downstream API calls. One customer reduced their origin server count from 12 to 8 after implementing edge-based fraud detection — the bots that were consuming 30% of their compute never reached the origin.