When you call the /api/validate endpoint, Fidro runs a series of checks and returns the results in the data.checks array. This guide explains each check and how to act on the results.
Email checks
disposable_email
What: Checks the email domain against 50,000+ known disposable email providers. Why it matters: Disposable emails are the #1 tool for free tier abuse and multi-accounting. Recommended action: Block at signup for B2B products. For consumer products, consider requiring phone verification.
free_email
What: Detects free email providers (Gmail, Yahoo, Outlook, etc.). Why it matters: Not fraud on its own, but combined with other signals it increases risk. B2B products may want to flag free email signups. Recommended action: Use as a supporting signal, not a blocking signal.
email_syntax
What: Validates email format, checks for MX records, and verifies the domain can receive mail. Why it matters: Invalid emails waste your onboarding resources and hurt deliverability. Recommended action: Block signups with invalid emails, they can't verify anyway.
domain_age
What: Checks how recently the email's domain was registered. Why it matters: Fraudsters frequently register new domains for phishing and throwaway accounts. Domains under 30 days old are significantly more likely to be fraudulent. Recommended action: Flag for review if domain is under 30 days old.
IP checks
vpn_detection
What: Identifies commercial VPN services (NordVPN, ExpressVPN, Surfshark, etc.). Why it matters: VPNs mask the user's real location. While many legitimate users use VPNs for privacy, they're also heavily used to evade geo-restrictions and commit fraud. Recommended action: Flag for review, but don't block outright, many legitimate users use VPNs.
proxy_detection
What: Identifies open proxies and anonymous relay services. Why it matters: Unlike commercial VPNs, open proxies are more strongly associated with fraud and bot activity. Recommended action: Higher risk than VPNs. Consider blocking or requiring additional verification.
tor_detection
What: Checks if the IP is a known Tor exit node. Why it matters: Tor provides strong anonymity and is frequently used for fraud, multi-accounting, and abuse. Very few legitimate signups come from Tor. Recommended action: Block or require strong verification (phone, ID).
hosting_detection
What: Identifies IPs belonging to cloud providers and data centres (AWS, GCP, Azure, DigitalOcean, etc.). Why it matters: Real users don't browse from cloud servers. Datacenter IPs usually indicate bots, scrapers, or automated abuse. Recommended action: Block for user-facing products. Allow if you expect API-to-API traffic.
bad_ip
What: Checks the IP against known abuse/spam lists. Why it matters: IPs flagged on abuse lists have a documented history of malicious activity. Recommended action: Block.
geo_mismatch
What: Compares the IP's country with an expected country (if you provide country_code).
Why it matters: A user claiming to be in the US but connecting from Nigeria is a strong fraud signal, especially for financial products.
Recommended action: Flag for review or require additional verification.
Behavioural checks
country_risk
What: Scores based on the IP's country's fraud index. Why it matters: Some regions have statistically higher rates of online fraud. This is a weak signal on its own but strengthens other indicators. Recommended action: Use as a supporting signal only.
custom_blocklist
What: Checks the email, domain, or IP against your account's custom blocklist. Why it matters: Your blocklist entries represent known bad actors specific to your business. Recommended action: These are your rules, the block is automatic and immediate.
Anomaly checks
These appear only on calls that carry an event or a user_id. Each one that fires is added to data.checks as true (the key is the anomaly code) and explained in data.anomalies with a severity and a human-readable detail. The rules and thresholds are in Velocity and Anomalies.
ip_signup_burst
What: 3 or more signups from one IP in an hour, or 5 in 24 hours. Why it matters: The clearest signature of scripted account creation and free tier abuse. Recommended action: Challenge (email verification or a CAPTCHA). Shared offices and campuses trip this, so avoid a hard block unless it is combined with VPN, proxy or disposable signals.
subnet_signup_burst
What: 5 or more signups from one /24 (IPv4) or /64 (IPv6) in an hour. Why it matters: Attackers who rotate IPs often stay inside one range. Recommended action: Supporting signal. Challenge when it appears alongside anything else.
email_pattern_burst
What: 3 or more signups in 24 hours whose addresses reduce to the same pattern once plus-tags, dots and trailing digits are removed.
Why it matters: sam+1@, s.a.m@ and sam42@ all land in the same inbox. This is how one person claims many free accounts.
Recommended action: Challenge. Consider refusing the second account outright for products with a generous free tier.
ip_many_users
What: 5 or more different user_ids active from one IP in 24 hours, on a non-signup event.
Why it matters: One machine driving many accounts is a credential stuffing or account farming signal.
Recommended action: Supporting signal. Rate limit the IP and watch the accounts involved.
new_country_for_user
What: A user with at least 3 prior events, all from one country, appears from another. Why it matters: Travel is normal; a first login from a new country is where account takeovers show up. Recommended action: Send a login alert or ask for a second factor rather than blocking.
impossible_travel
What: The same user_id seen from two countries within 60 minutes.
Why it matters: The person cannot be in both places. Either a VPN switched on mid-session, or two people hold the credentials.
Recommended action: Challenge with a second factor; a VPN user will pass it, an attacker will not.
Combining checks for decisions
Don't make decisions based on a single check. The risk score already combines all signals with appropriate weights. Use individual check results for:
- Custom logging, Know exactly why a user was flagged
- Support context, When a user complains about being blocked, see the specific reasons
- Threshold overrides, Block on specific checks regardless of score (e.g., always block Tor)