Fraud Score API: Combining IP, Email and Phone Signals
A fraud score API for IP, email and phone data combines several independent risk signals into a single number so you can make one decision instead of juggling four separate checks. ipto's fraud score takes an IP address, an email, a phone number and a User-Agent, and returns a 0 to 100 score with a breakdown of what contributed.
The reason to fuse signals is that each one is weak alone. A VPN address is normal for many honest users. A disposable email may just be someone protecting their inbox. A bot-like User-Agent could be a monitoring tool. Together, though, a Tor exit, a throwaway email domain and an automation User-Agent on one sign-up is an unusual combination, and a combined score surfaces it.
What goes into the score
Each input is scored by the matching ipto tool, and the results are blended with fixed weights. The IP counts for 40 percent and the email, phone and User-Agent each count for 20 percent. The component logic is deliberately simple and inspectable:
- IP. Based on the corroborated abuse score where one exists; otherwise a Tor exit scores high, a VPN address scores moderately, and an address with no flags scores low. You can explore these inputs with the VPN, Tor and proxy checker and the IP abuse checker.
- Email. Invalid syntax scores high, a disposable domain scores high, a domain with no working MX records scores in the middle, and a well-formed address on a normal domain scores low. This is the same logic as the email checker.
- Phone. A number that fails numbering-plan validation scores high, a valid one low. Because the phone checker uses a self-hosted parser with no live carrier lookup, this is a plausibility check, not proof that the number is live.
- User-Agent. A client that parses as a bot or crawler scores high; an ordinary browser scores low, using the same parsing as the User-Agent parser.
The response lists each signal with its own score and the raw fields behind it, such as is_vpn, is_tor, risk_tier, has_mx, disposable and is_bot. That makes the number explainable: when a user is flagged, you can say exactly why.
How missing inputs are handled
Real traffic is incomplete. A login attempt may have an IP and User-Agent but no email, and a signup form may skip the phone field. The fraud score does not treat an absent input as "clean". Missing signals are left out, and the weight of the signals you did provide is rescaled so they sum to the whole score.
Concretely, if you send only an IP, the IP carries the full weight, so a Tor exit produces a high score instead of being diluted toward safe by three empty fields. If you send an IP and an email, the weights become roughly two-thirds and one-third. Two limitations are worth knowing. If no inputs resolve at all, the score falls back to a low baseline. And the IP signal currently covers IPv4 only, since threat data for IPv6 is not available in the same form; an IPv6 address is skipped rather than scored as clean, so pair it with the other inputs.
From score to action
The score maps to a risk tier: below 20 is low, 20 to 44 is medium, 45 to 69 is high, and 70 or above is critical. Treat these as a prior that tells you where to apply friction. A reasonable pattern is to allow low scores, ask for a second factor or email confirmation on medium and high, and queue critical scores for review. The tool is not meant to be the sole basis for denying a customer, and it does not replace your own signals such as order history, device history or chargeback records, which ipto does not collect.
Trying it
The quickest way to see the behavior is the fraud score checker: fill in one field, note the score, then add the others and watch the breakdown change. The same capability is available through the API, documented in the API documentation, with all four inputs optional. Running it on a sample of your own recent sign-ups is a good way to learn which signal drives risk in your traffic, and the reasoning behind the IP component is covered further in IP reputation scoring explained.