Device intelligence and device fingerprinting
Naiza device intelligence gives every browser and phone that reaches your product a stable fingerprint, then connects it to the customers, sessions, and events it has been part of. Your rules can then ask the questions that matter at login, signup, and payment: have we seen this device before, how many accounts has it touched, and has it been tied to fraud?
How it works
The SDK runs in your web app or mobile app and produces a device fingerprint. You send that fingerprint with the events you already send to Naiza. The rules engine reads it alongside the customer, IP, session, and velocity data, and returns ALLOW, REVIEW, or BLOCK.
- Collect: the Web, iOS, or Android SDK gathers device and environment signals.
- Identify: Naiza turns them into a fingerprint that stays the same when cookies are cleared or the app is reinstalled.
- Link: each fingerprint is tied to the customers, sessions, and events it appears in.
- Decide: rules use device history, account links, and risk score to return a decision.
What a fingerprint tells you
A single attribute such as IP address or user agent changes too often to be useful on its own. Combined, they give a device identity that holds up across sessions.
| Signal group | Examples | What it helps catch |
|---|---|---|
| Device and environment | Operating system and version, browser, screen, language, timezone, hardware traits. | Returning devices, a known account on an unknown device, inconsistent setups. |
| Network | IP address, ISP and ASN, geolocation, VPN, proxy, and hosting detection. | Location mismatches, traffic routed through data centers, attempts to hide origin. |
| Automation | Headless browsers and scripted sessions. | Bots running credential stuffing, card testing, and fake signups. |
| History and links | Accounts, sessions, and events seen on the same device, plus its risk score and status. | Multi-accounting, mule networks, and devices tied to confirmed fraud. |
What you can catch with it
Use device signals with account, session, network, and transaction history to identify risky logins, signups, and payments.
- Account takeover: a long-standing customer suddenly logs in from a device and network you have never seen, then changes the phone number.
- Multi-accounting and promo abuse: one phone opens ten accounts to claim ten welcome bonuses.
- Mule networks: several unrelated customers receive and forward funds from the same handful of devices.
- Signup fraud: scripted registrations from emulated or automated browsers.
- Payment fraud: a card or wallet used from a device already linked to chargebacks.
Rules teams write with device data
These are starting points. Each one names its identifier, condition, and outcome, so an analyst can explain the decision to a customer or an auditor.
| Rule | Condition | Typical outcome |
|---|---|---|
| New device on a sensitive action | Password reset, phone change, or new beneficiary from a device not seen on this account. | REVIEW or step-up verification |
| Shared device | Device linked to three or more customer accounts. | REVIEW the cluster before blocking |
| Blocked device | Fingerprint is on your blocklist. | BLOCK |
| Impossible travel | New device and new country within an hour of the last login. | REVIEW |
| Anonymized high-value payment | VPN or proxy on a transfer above your threshold. | REVIEW |
| Fraud history | Device previously linked to confirmed fraud. | BLOCK |
Example event with device context
Send the fingerprint with the event. If you already have your own device ID, send it as externalId and Naiza tracks it the same way.
curl -X POST https://api.naiza.ai/api/v1/events \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "eventName": "user.login", "eventCategory": "AUTHENTICATION", "customer": { "externalId": "user_123456" }, "device": { "externalId": "device_abc123", "fingerprint": "fp_abcdef12345" }, "ip": "203.0.113.42" }'
SDKs and integration
The Web SDK loads from the Naiza CDN or from your own hosting. The iOS and Android SDKs ship as native libraries. All three return the fingerprint your server attaches to events, so the decision always happens server-side where it cannot be tampered with.
In the dashboard, each device has a page with its linked customers, activity history, risk score, and status. Analysts can block or unblock a device and record the reason.
Hosted in Saudi Arabia
Device data is stored and processed in the Kingdom with the rest of your Naiza data. The same platform handles fraud decisions, AML screening, and transaction monitoring, so a device linked to a fraud case is visible when the same customer later appears in an AML review.
Frequently asked questions
Answers about screening, risk signals, and Naiza integration.
What is device fingerprinting?
Device fingerprinting combines attributes of a browser or phone, such as operating system, screen, language, timezone, and network details, into an identifier that stays stable across sessions. Fraud teams use it to recognize returning devices and spot accounts that share one.
How is device intelligence different from IP checks?
IP addresses change constantly and many customers share them on mobile networks. A device fingerprint follows the device itself, so it still works when the customer switches between Wi-Fi and mobile data or uses a VPN.
Can device fingerprinting stop account takeover?
It is one of the strongest signals for it. A login from an unknown device, followed by a password or phone number change, is the classic takeover pattern. Naiza lets you route that sequence to REVIEW or step-up verification.
Does Naiza support mobile apps?
Yes. Naiza provides Web, iOS, and Android SDKs. All three produce a fingerprint your server sends with fraud events.
Will shared family devices get blocked?
Not if you write the rule well. Send shared-device clusters to REVIEW instead of BLOCK, and look at what the accounts are doing before acting. Several relatives on one tablet look very different from ten new accounts claiming the same bonus.
Where is device data stored?
In Saudi Arabia. Naiza stores and processes device data in the Kingdom.