Building a Multi-Signal Fraud Detection Stack: An Architecture Guide

Most fraud controls were added one problem at a time: a CAPTCHA after a wave of automated form submissions, an email validator after a bounce spike, an IP blocklist after a burst of fake sign-ups. Each tool sees one signal, and attackers have learned to pass each check on its own. Multi-signal fraud detection takes a different approach. It evaluates the session, the identifiers, the content, and the submission pattern together, and turns them into one explainable risk score your team can act on. This guide walks through how to design that stack: which signals to collect, where each one comes from, how to combine them, and how to route the result.

Why Single-Signal Checks Keep Failing

Every individual signal has a known weakness, and attackers target it.

IP reputation is easy to rotate around. The FBI warned in 2026 that residential proxies let attackers "rapidly rotate between a large number of IPs, bypassing rate limits and lockout mechanisms." In a report covering 4 billion malicious sessions, GreyNoise found that 78% of residential IPs targeting edge devices were "invisible to reputation feeds," because each one appeared only a few times before rotating away. Bitsight, after observing 53 million residential proxy exit nodes, concluded that "relying purely on static IP reputation is no longer viable."

IP signals alone also create false positives. Cloudflare described how attackers increasingly use VPNs, proxies, and botnets, "further diminishing the reliability of IP addresses as a standalone indicator of malicious activity." After moving from IP-only logic to a system that combines IP signals with behavioral and threshold indicators, Cloudflare reported "a significant reduction in false positives."

Shared addresses punish real users. Research presented at the 2020 ACM Internet Measurement Conference (IMC) found that 53% to 60% of 151 public blocklists contained reused addresses that can affect as many as 78 legitimate users for as many as 44 days.

The same pattern applies to other single checks. A valid, deliverable email address says nothing about whether a script typed it. A human-looking session says nothing about whether the email is disposable. Each signal answers one question. Fraud decisions need several answers at once.

The Signal Layers of a Multi-Signal Fraud Detection Stack

A useful way to design the stack is to map signals to the moment they become available. Opportify's Identifier Trust Layers framework describes this sequence, from network filtering through to transaction monitoring. The pre-onboarding portion of a stack usually draws on six signal categories.

1. Network Filtering

Web application firewalls (WAFs), CDN rules, rate limiting, and IP blocklisting stop high-volume, known-bad traffic before it reaches your application. This layer is necessary, but it only sees the network envelope, not who is filling in the form. See Layer 0: Your Network Defense Catches What It Can See.

2. Session and Behavioral Signals

Collected in the browser while the user interacts with the page. Useful signals include automation tool detection (headless browsers, Puppeteer, Selenium, Playwright), honeypot fields, typing speed, pointer behavior, submit timing, and device fingerprint consistency. These answer "is a person interacting with this form, and is this device consistent?" See Layer 1: CAPTCHA Passed the Session.

3. Identifier Signals

Evaluated on what the user submits.

• Email: deliverability, disposable or free provider classification, domain age, DNS authentication records (SPF, DKIM and DMARC, the standards that tell receiving mail servers which senders a domain authorizes), and domain blocklist status.
• IP: connection type (VPN, Tor, open proxy, cloud, and others), geolocation, WHOIS registration and network (ASN) ownership, blocklist status, and active abuse reports.
• Phone: carrier, line type, and validity, where phone numbers are collected. Opportify doesn't score these phone checks today. Phone Insights, which will add carrier, line type and validation checks, is not yet available.

See Layer 2: Input and Signal Intelligence for how each identifier is assessed.

4. Content Signals

Free-text fields carry their own evidence. Gibberish detection on names and messages, and form spam pattern detection in message fields, catch low-effort automated submissions that pass other checks.

5. Velocity Signals

How often the same identifiers appear in a short window. Submission counts over one minute, five minutes, one hour, and 24 hours, compared against adaptive thresholds, surface scripted bursts and repeated attempts. Velocity is especially useful against the multi-account patterns described in Multi-Account Fraud: How Abusers Clone Identities at Scale.

6. Geographic Consistency

Cross-checking location data from several sources: IP country against the declared country, the email domain's country, the phone country code, and the session context. A single mismatch can be innocent, such as a traveler or a remote employee. Several mismatches together are more telling.

How to Combine Signals Into One Decision

Collecting signals is the easy part. The design decisions are in how you combine them.

Score the submission, not the signal. A VPN connection, a free email provider, and a fast submit time are each weak on their own. A model that evaluates them together can tell a privacy-conscious customer on a VPN from a scripted sign-up behind a rotating proxy. Correlation between signals is where most of the useful evidence lives.

Make every score explainable. A score your team cannot interpret is hard to trust and hard to tune. Each result should carry the top contributing reasons, so an analyst can see why a submission was flagged and whether the policy fits.

Handle missing signals gracefully. Not every submission includes every input. A server-side API call may not have browser telemetry, and a contact form may not collect a phone number. The stack should score what is available rather than fail.

Keep the data fresh. IP reputation decays quickly. In research presented at the 2020 ACM Internet Measurement Conference (IMC), blocklisted addresses were removed within nine days on average, and about 77% of dynamically allocated reused addresses were removed within two days. Threat data should be continuously updated, and dynamic results should not be cached for long.

Separate scoring from decisions. The scoring layer should describe risk. Your business rules, set by your team, decide what happens at each risk level. This keeps policy changes fast and auditable, and avoids hard-coding judgments into the detection layer.

Routing by Risk: Turning Scores Into Workflows

Once each submission has a score and reasons, you can design responses that match your risk tolerance. A typical starting point:

Risk level	Example response
Lowest or low	Continue the normal flow
Medium	Add a verification step, or send to a review queue
High	Hold for manual review before granting access or passing to sales
Highest	Hold, and alert the team that owns the form or sign-up flow

Route results into the systems your team already uses: the CRM, a review queue, a messaging channel, or a data warehouse. Track outcomes, including confirmed fraud and false positives, and revisit thresholds regularly. A business-facing product with many remote employees will see more VPN and corporate proxy traffic than a consumer app, and its thresholds should reflect that.

Multi-signal detection before onboarding can also reduce the load on later controls. Identity verification and transaction monitoring can work more efficiently when fewer low-quality submissions reach them, as covered in Layer 4: The Transaction Layer Catches Fraud Too Late.

How Fraud Protection Helps

Building and maintaining every layer in-house means running a browser telemetry script, sourcing and refreshing threat feeds, and keeping a scoring model current. Fraud Protection combines Interaction & Session Intelligence and Input & Signal Intelligence into one service. It scores each submission across 100+ signals and returns a risk score from 200 to 1000 with one of five risk levels and the top contributing risk factors, delivered as an Explainable Risk Report.

The scoring draws on six intelligence sources: email, IP, content, session (behavioral), velocity, and geographic consistency. Email and IP signals come from the same intelligence that powers Email Insights and IP Insights, including 30+ continuously updated threat intelligence sources.

Fraud Protection is available as a client-side integration or a server-to-server API:

• Form Fraud Protection adds a JavaScript snippet to your pages. It collects behavioral and device signals in the browser, and Opportify's backend performs the full analysis. No backend changes are required.
• The Fraud Protection API (POST https://api.opportify.ai/intel/v1/fraud/analyze) returns a synchronous risk assessment from your server, for sign-up handlers, checkout services, or any server-side flow. Email, IP, content, session, and velocity sources are evaluated in parallel, and at least one of email or userIp is required.
• Hybrid mode deploys both. The frontend script issues an opportifyToken, which your backend passes in the API request body to add session and behavioral signals to the analysis.

A minimal API request looks like this. Authenticate with the x-opportify-token header, which is separate from the opportifyToken body field:

curl -X POST "https://api.opportify.ai/intel/v1/fraud/analyze" \
  -H "Content-Type: application/json" \
  -H "x-opportify-token: YOUR_API_KEY" \
  -d '{
    "email": "jane.doe@example.com",
    "userIp": "203.0.113.42",
    "submissionType": "registration",
    "opportifyToken": "TOKEN_FROM_FRONTEND_SCRIPT"
  }'

The response includes a composite score (200 to 1000), a level, a factors array of the top weighted risk factor codes prefixed by source (for example email: or ip:), and a sources object with the per-source breakdown for email, IP, content, session, velocity, and geographic consistency.

Fraud Protection scores and flags each submission. Your team decides how to respond, and results can be pushed to your CRM, Slack, or any HTTP endpoint through webhooks.

Getting Started

1. Map your entry points. List every form, sign-up, trial, and lead capture flow, and note which signals each one already collects.
2. Find the gaps. Compare your current controls against the six signal categories above. A common pattern is network filtering and email validation in place, with behavioral, velocity, and geographic consistency signals missing.
3. Choose an integration method. Use Form Fraud Protection for marketing sites and forms, the Fraud Protection API for server-side flows, or both.
4. Start in observation mode. Score traffic for a week or two before acting on it, and compare flagged submissions with what your team already knows.
5. Set and tune your policy. Define responses for each risk level, route results into your existing tools, and review false positives regularly.

See the Fraud Protection documentation and the assessed signals reference for implementation details, and pricing for current plans.

Key Takeaways

• Single-signal checks each have known blind spots, and attackers rotate around them, especially at the IP level.
• A multi-signal fraud detection stack combines session, identifier, content, velocity, and geographic signals so they are evaluated together.
• Explainable scores, graceful handling of missing signals, and fresh threat data matter as much as the signals themselves.
• Keep scoring and decisions separate: the stack describes risk, and your team sets the policy for each risk level.
• Flagging low-quality submissions before onboarding can reduce the load on identity verification and transaction controls downstream.