SaaS signup fraud prevention

Four problems that look like one

"Signup fraud" covers four distinct behaviours. They need different responses, and a defence tuned for one will miss the others.

Why one signal is never enough

Every individual check has a population it cannot see, and each one has a false positive problem that only shows up at scale.

The useful move is not finding a better single signal. It is combining weak signals into one score, so a corporate VPN on its own is unremarkable but a corporate VPN plus a disposable address plus a country mismatch is not. Residential proxies are the clearest example of why any single check eventually fails.

Where the check belongs

After the form is submitted, before the account is created. Earlier and you are scoring an incomplete picture. Later and you have already provisioned something you are about to delete.

POST /register
   |
   ├── validate the form
   ├── score the signup   ← here
   |     allow      → create the account
   |     challenge  → create it, require email verification first
   |     block      → refuse, log, do not provision
   └── create the account

The three-way outcome is the part that protects conversion. A binary allow or block forces a choice between letting abuse through and refusing real users, and real users do sit behind corporate VPNs. The middle band is where you put friction instead of a wall.

One call, one decision

Fidro combines the email and IP signals into a single score and returns the decision, so your signup handler branches on one field rather than implementing the scoring itself.

curl -X POST https://fidro.io/api/validate \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email": "user@example.com", "ip": "203.0.113.42"}'

{
  "risk_score": 82,
  "recommendation": "block",
  "checks": {
    "disposable_email": true,
    "vpn": true,
    "datacenter": true,
    "proxy": false,
    "tor": false,
    "bad_isp": false,
    "bad_ip": false,
    "invalid_email": false,
    "location_match": false
  }
}

allow below 50, challenge from 50 to 79, block at 80 and above. The checks object is the reasoning, so you can override the thresholds where your risk appetite differs. What a score of 73 actually means walks through a real borderline case.

Setting thresholds without guessing

Start by blocking nothing. Run the scoring in log-only mode for a fortnight, look at what your known-good signups score, and set the block threshold above that. You will usually find real users cluster well below 50 and abuse sits above 80, which leaves a middle band worth challenging rather than refusing.

The failure mode to avoid is tuning on fraud caught rather than customers lost. Both numbers matter and only one of them is easy to see. Tuning fraud thresholds covers the arithmetic, and preventing fake signups without killing conversion covers what it costs when you get it wrong.

Going deeper

Questions