Bot, Abuse, and ATO Scores: Reading Signup Risk Beyond One Number

A single risk number is easy to ship and hard to operate. When overall score is 72, is that a headless browser, a disposable-email farmer, or a returning customer on a new laptop in another country? Bot, abuse, and ATO (account takeover) scores separate those stories so engineering and support take different actions.

This guide explains what each score should capture at signup, how to use them with a primary decision (ALLOW / BLOCK / CHALLENGE / LIMIT), and how custom traits and lists fit in.

One decision, several scores

Production signup protection should still return one enforceable decision. Your app branches on that — grant the trial, deny it, require a passkey, or shrink credits.

Alongside the decision, return structured scores:

{
  "decision": "CHALLENGE",
  "scores": {
    "overall": 72,
    "bot": 55,
    "abuse": 40,
    "ato": 78
  }
}

• overall — policy input for the primary decision
• bot — automation, behavioral timing, fingerprint anomalies
• abuse — disposable email, velocity, clustering, phone risk
• ato — device reuse mismatch, impossible travel, new device + known identity

AntiTrial derives these from the same signal registry (weighted subsets), not separate opaque models — so reason codes stay explainable in the dashboard.

What each score is good for

Bot

High bot score → scripted registration, headless browsers, unnatural form timing.

Typical actions: CHALLENGE (passkey) or BLOCK if automation is clear and you do not sell to bots.

Abuse

High abuse score → trial farming patterns: burner mail, signup bursts, shared devices across many emails.

Typical actions: BLOCK for clear disposable + velocity stacks; LIMIT for medium abuse with otherwise clean identity.

ATO

High ATO score → “this identity looks known, but the device/geo story is wrong.”

Typical actions: CHALLENGE before changing password or starting a new trial on an existing email; REVIEW internally if you have an analyst workflow.

Mapping scores to product UX

Do not invent a second decision engine in your app that overrides overall with custom thresholds unless you have a clear product reason. Prefer dashboard rules + lists for exceptions.

Traits and lists sharpen the scores

Scores generalize. Custom traits (vip, plan_intent, referral) let rules say “if trait.vip == true, never LIMIT.” Allow/block lists short-circuit before scoring when you already know the answer.

Together:

1. Lists → memory of past decisions
2. Scores → what this attempt looks like now
3. Traits → your business context on the request
4. Decision → what the product does

Alerting without drowning Slack

Alert on decision outcomes and score spikes, not every evaluate:

• BLOCK with abuse ≥ 80
• CHALLENGE with ato ≥ 70 on returning emails
• Confirmed abuse from the analyst workflow

Slack Incoming Webhooks are enough for v1 — paste a channel webhook URL in the dashboard and filter by event type.

Implementation checklist

1. Enforce on decision in your BFF before provisioning
2. Log decisionId + all four scores for support
3. Show bot / abuse / ATO meters in internal tools (or use the AntiTrial decision detail view)
4. Add list short-circuits for known good/bad identities
5. Pass traits you already collect (plan tier intent, partner flags)

Docs and next steps

• Scores
• Decisions
• Custom traits
• Slack alerts

CTA: Try AntiTrial · Create a free account · Growth from $39/mo on Pricing