A new signup at 21:41. Before the form is submitted, the SDK has read the device, the browser and the network and resolved one identifier that survives a cleared cookie.
The same device had opened forty-one accounts in thirty-six hours, across three IPs, claiming the welcome bonus on every one. Each account cleared KYC on its own.
Your rule holds the account, opens a case, and attaches the fingerprint and every account linked to it. Elena V. sees which signal fired and what it was scored against, then decides. The reasoning stays on the file.
Forty-one accounts share one device fingerprint and one proxy range. Bonus claimed on thirty-nine. Recommend hold on all linked accounts and a single STR if funds moved out.
Trusted by top financial institutions and fintech leaders across the EMEA region
These are the signals your session revealed when this page loaded read live, not pre-recorded. Your IP address and network type come from a lookup; blocklist checks resolve server-side.
Reading
Device and browser signals are read by the Youverify Behavioral SDK when this page loads. Your IP address, network operator and approximate location come from the same session, resolved server-side.
One unusual signal may mean nothing. Several signals moving together tell a story.
Device and browser signals resolve into a persistent profile identifier, so related sessions and accounts surface together.
See when one device begins creating or accessing accounts faster than expected.
Detect private browsing, Tor, anti-detect browsers and attempts to obscure the environment.
Compare navigation, interaction and behavioural patterns against previous activity.
Surface mismatches between network location, time zone, locale and claimed geography.
Detect virtual devices, emulators and remote-control environments before they become trusted sessions.
Signals become decisions in a rule engine your fraud team edits, not a model you have to take on faith. Every rule carries a version, an author and a dry run against the last thirty days of traffic before it goes live.
A rule can hold the activity, open the case and bring every linked account with it. Your workflow determines which of those happens, and an analyst can open a case by hand from any session. However it starts, it is the same case object an onboarding review uses.
See the onboarding side of the same caseVyra AI groups the linked activity, explains the shared signals, reconstructs the sequence and drafts the investigation narrative. The evidence stays attached to the case, and the decision stays with a named officer under your workflow.
What else has this device touched in the last week?
Six more sessions, all on the same proxy range: two failed card top-ups, three abandoned signups, one password reset on an account opened in March. That account has withdrawn $840,000 since Tuesday.
A corporate login arrives with the correct password and a device the profile has never used, from a proxy claiming Panama, minutes after a password reset. Step-up is triggered before the transfer screen loads.
We used to find the ring in the monthly reconciliation. Now the fourth account on a device never opens.
The part our examiner cared about was the audit trail: which signal fired, what it scored, who decided. It was all on the case.
The SDK reads device, browser and behavioural signals on the session itself and resolves them into a persistent profile identifier. Your rules score that profile as it moves rapid account creation, a shared fingerprint, a spoofed location, an emulator and fire before the money leaves.
Device and browser attributes, rendering characteristics, time zone and locale, network posture, and interaction patterns. No document contents and no biometric data. The profile identifier survives cleared cookies and reinstalled apps because it is derived from the device, not stored on it.
Signals are scored, not stacked. A shared device in a household is not the same as one fingerprint on forty accounts in thirty-six hours, and your rules can say so. Every rule can be dry-run against the last thirty days of traffic before you turn it on.
Yes a web SDK and native iOS and Android SDKs return the same profile identifier and the same signal set, so a rule written once applies across every channel a customer reaches you on.
It runs on the same entity record. A device signal raised at signup sits beside the identity and screening evidence, and the case a fraud rule opens is the same case an analyst works in Cowork.
Signals are collected under legitimate interest for fraud prevention, retained for the period you configure, and processed in regions with adequate data protection regulation. Youverify holds SOC 2 Type II and ISO 27001 and is registered with the data protection authorities in the markets it serves.
One script tag or one SDK install, then rules. Most teams see signals in a sandbox the same day and run their first production rule inside a week.
The fraud signal does not become another silo. It stays on the same entity record used across onboarding, monitoring, investigation and reporting.
Bring us a sample of your traffic. We will show you the devices already connected, the patterns already forming, and the rules that could have caught them.
Youverify holds SOC 2 Type II, ISO 27001, ISO 27018 and ISO 42001 certifications, and is registered with the data protection authorities in Nigeria, Kenya, South Africa, Côte d’Ivoire and the United Kingdom.
