Hierdie vertaling is masjiengegenereer en wag op hersiening. Skakel oor na Engels
Kontroleskerm

Use Cases

What success looks like, in three slices of real production traffic.

The numbers in our outcomes section — a roughly 47% median drop in chargebacks, a false-positive rate under half a percent, verification answering in a few milliseconds — come from integrations like the ones below. The cases here are anonymized composites; the patterns are real.

Marketplaces

The problem: fake-account rings creating dozens of accounts to review-bomb, manipulate seller rankings, or abuse welcome-bonus promotions.

The signal: twelve accounts created within two hours, all from different connections — but with browser and tampering signs pointing to a single automated cluster.

How the signal compounds

A single signup from a home connection on a real browser is unremarkable. Twelve signups from twelve different home connections, on what looks like the same automated browser with the same tampering signature, is a fake-account ring.

The categories that fire together here:

  • Automation and bots (01) — headless-browser signatures on every account.
  • Fingerprint tampering (02) — drawing tests that don’t match the browser version claimed.
  • Infrastructure abuse (03) — residential proxies sold by a known fraud operator.
  • Behavioral anomalies (06) — signup forms filled in identical patterns, with the same timing.

No single category would flag the ring. The combined risk score does.

The policy

The marketplace blocks at the top tier — the ring, not the customers — and steps up to phone verification when the risk is high and the confidence is solid. Everything else flows through untouched. In practice the whole policy is a few lines of code reading the risk level Noxtica returns.

The outcome

Fake signups drop by roughly 70% within a month of integration. Real-customer signup conversion is unchanged.

Financial services

The problem: card-not-present fraud, especially account-takeover attacks where the attacker has the card details but not the cardholder’s known devices.

The signal: a session whose profile doesn’t match the cardholder’s known devices. The response is step-up verification, not an outright block. Real customers see no friction; fraud rings see an extra check on every transaction.

How the signal compounds

Card-not-present fraud increasingly uses real, stolen card details on attacker-controlled devices. The device is the differentiator. We keep a profile per customer; when a transaction arrives from a profile we haven’t seen for that customer, we flag it.

The categories that fire together here:

  • Hardware checks (05) — the new device may have a different graphics, audio, or memory signature.
  • Infrastructure abuse (03) — fraud rings often sit behind datacenter routes even when fronted by residential proxies.
  • Behavioral anomalies (06) — checkout timing that doesn’t match the cardholder’s history.

The new-device signal alone isn’t malicious — customers buy phones, replace laptops, reinstall operating systems. We weight it against the other categories to separate “customer on a new device” from “attacker with stolen card details.”

The policy

A returning customer on a known device, below the top tier, flows straight through with no friction. When the risk is high — or a new device shows up on an unusually large transaction — the session gets step-up verification rather than an outright block. The bias is always toward letting real customers complete the purchase.

The outcome

Chargeback losses drop by roughly 45 to 50% within three months. Step-up verification is seen by only a small fraction of transactions, and the vast majority of those complete successfully — real customers passing the check.

Identity-sensitive platforms

The problem: passwordless and single-sign-on platforms need to confirm that the entity clicking a login link is the same one that requested it. Phishing kits and link-relay services break that assumption.

The signal: a link clicked from a different profile than the one that requested it triggers an extra verification step. Phishing kits and link-relay services are caught at this gate.

How the signal compounds

When a login link is requested, we record the requesting profile. When the link is clicked, we re-check the profile and compare. If they match — same browser, same device — the link authenticates automatically. If they don’t, we treat the click as a different session and require an extra verification step.

The categories that fire together here:

  • Fingerprint tampering (02) — phishing kits often run headless browsers whose profiles don’t match the user’s real device.
  • Behavioral anomalies (06) — the time between request and click, the source of the traffic, and how the session changes all matter.
  • Infrastructure abuse (03) — link-relay services typically run from cloud infrastructure.

The policy

If the clicking device matches the device that requested the link, the login link works automatically. If it doesn’t, the platform requires a second factor before letting the session through. The match check is a simple comparison against the profile recorded when the link was issued.

The outcome

Phishing success against login-link campaigns drops dramatically — typically a 90%-plus reduction in successful credential-relay attacks. Real users who legitimately switch devices see one extra verification step, then join the trusted-device list for future links.

Pattern: when to block, when to challenge

Across all three use cases, the policy structure is the same:

  1. Critical risk — block with logging. These sessions aren’t worth the cost of a challenge.
  2. High risk — challenge: step-up verification, a second factor, or manual review. Real customers pass; bots don’t.
  3. Medium risk — observe. Log the session and surface it in the dashboard, but add no friction.
  4. Low or minimal risk — allow. The vast majority of traffic.

These four actions map onto the five-tier risk model: the two lowest tiers both collapse to “allow” for almost everyone, but keeping them separate is useful in the dashboard for understanding where your population sits.