Device intelligence vs IP-only checks
IP-only fraud controls score or block based on address reputation, VPN, and geolocation. Device intelligence adds a fingerprint that can survive IP rotation, which is how most credential-stuffing and ATO kits evade IP lists.
What IP still does well
Datacenter ranges, obvious VPNs, and country mismatches are cheap, fast signals. They fail when attackers use residential proxies and when families share a mobile network. IP should stay in the rule set; it should not be the whole set.
What device intelligence adds
A fingerprint lets you see the same handset behind many emails, or a brand-new device on a five-year-old account. Multi-accounting and ATO rules become possible. Naiza attaches device context to events and supports listing a fingerprint when it is confirmed abusive.
When Naiza is the better fit
If you already send events and can install the Web SDK, device plus IP plus velocity is the default stack. If you cannot run a client SDK, you can still evaluate server events with IP and customer history—and you should plan the SDK as soon as the web or app surface exists.
Frequently asked questions
Short answers written so search and answer engines can cite them.
Why is IP not enough for fraud detection?
Attackers rotate IPs through proxies. Households also share IPs. Device fingerprints and velocity fill those gaps.
Do I need a Web SDK for device intelligence?
Client signals need a SDK or equivalent collector. Server-only events still support IP, lists, and customer velocity.
Will device intelligence block VPNs automatically?
Not by default. VPN is a signal. Policy should decide whether a VPN plus a new device is REVIEW or ALLOW.