---
title: Checks
description: Checks are the boolean and numeric facts Rupt derives from signals plus a user's history: is this fingerprint new, is this IP a VPN, has this user moved impossibly far. They're the building blocks of risks and policies.
---

# Checks

Checks are the boolean and numeric facts Rupt derives from [signals](/docs/v3/concepts/signals) plus a user's history. They turn raw measurements into the language Rupt reasons about: _is this fingerprint new for this user, is this IP a VPN, has this user moved impossibly far since we last saw them_.

A check is deliberately narrow. Each one captures a single fact at a single moment, and on its own each is weak. A new IP isn't suspicious by itself, and neither is a webmail address. The power comes from how they combine into [risks](/docs/v3/concepts/risks) and how your [policies](/docs/v3/concepts/policies) match conditions across them.

Here's most of what we check. We keep this in sync with the app as best we can, but it isn't a guarantee. The dashboard policy editor always has the live, complete list.

## Identity newness

How established the user, IP, or [fingerprint](/docs/v3/concepts/fingerprints) is for this account.

- `is_new_user`
- `is_new_ip`: see [New IP](/docs/v3/concepts/ip).
- `is_new_fingerprint`
- `user_age_days`
- `fingerprint_user_count`: how many users share this [fingerprint](/docs/v3/concepts/fingerprints).

## Network reputation

What kind of network the connection is coming from. See [Anonymizing network](/docs/v3/concepts/anonymizing-network).

- `ip_is_vpn`
- `ip_is_proxy`
- `ip_is_tor`
- `ip_is_hosting`
- `ip_country`

## Velocity and geography

How the user moves through space and time.

- `impossible_travel`: see [Impossible travel](/docs/v3/concepts/impossible-travel).
- `concurrent_sessions`: see [Concurrency](/docs/v3/concepts/concurrency).
- `has_high_velocity`: an unusual rate of actions in a short window. See [Velocity](/docs/v3/concepts/velocity).

## Device counts

How many devices a user has piled up. Some of the strongest [account-sharing](/docs/v3/concepts/account-sharing) signals there are. See [Devices](/docs/v3/concepts/devices).

- `device_count`
- `computer_device_count`
- `tablet_device_count`
- `mobile_device_count`

## Email quality

What kind of email address was provided. See [Email quality](/docs/v3/concepts/email).

- `email_is_disposable`
- `email_is_webmail`
- `email_is_invalid`
- `email_is_accept_all`

## Account state

Verification and status flags on the user.

- `is_email_verified`
- `is_phone_verified`
- `is_suspended`
- `origin_is_new`: first time this request origin has been seen for your project in the last 90 days.

## Device integrity

Only populated when you ship the iOS or Android SDK. Web flows leave these unset, and each platform reports only its own flags.

- `jailbroken_ios`
- `rooted_android`
- `is_simulator`
- `is_emulator`
- `debugger_attached`
- `ui_testing`

## Fingerprint observations

A separate family of checks derived from the deeper [signals](/docs/v3/concepts/signals) we collect during fingerprinting. Unlike the checks above, these aren't conditions you match in policies directly. They roll up into the observation-only risks ([bots](/docs/v3/concepts/bots), tampering, anti-fingerprinting, incognito, and replay attacks) so you can watch them without them forcing a verdict.

### Bot

- `bot_framework_globals`
- `navigator_webdriver_true`
- `event_istrusted_synthetic`
- `window_process_present`
- `mediadevices_absent_modern_ua`
- `devtools_open_during_flow`
- `widevine_missing_on_chrome`
- `webgl_swiftshader_renderer`
- `uach_missing_on_chrome`
- `speech_voices_empty_on_desktop_chrome`
- `screen_frame_all_zero_desktop`
- `fonts_empty_on_desktop`

### Tampering

- `prototype_integrity_fail`
- `plugin_prototype_mismatch`
- `engine_probe_mismatch`
- `math_random_patched`
- `uach_vs_ua_mismatch`
- `notifications_permission_spoof`
- `deviceorientation_permission_non_ios`

### Anti-fingerprinting

- `tor_browser_signature`
- `safari_itp_lockdown`
- `firefox_etp_timer`
- `brave_farbling_detected`
- `firefox_rfp_detected`

### Incognito

- `languages_dedup_incognito`
- `storage_quota_incognito`
- `permissions_stuck_prompt`
- `indexeddb_failures`
- `notifications_private_spoof`

### Replay attack

- `consumed_nonce`
- `nonce_session_mismatch`
- `unknown_nonce`
- `missing_nonce`
- `missing_cookie`
- `session_expired`

## How checks are used

Checks feed two systems:

1. **Risks**: Rupt aggregates the relevant checks into a weighted score per category: [account takeover](/docs/v3/concepts/account-takeover), [fake account](/docs/v3/concepts/fake-account), [account sharing](/docs/v3/concepts/account-sharing), [scraping](/docs/v3/concepts/scraping), and [linked accounts](/docs/v3/concepts/linked-accounts).
2. **[Policies](/docs/v3/concepts/policies)**: your rules can match conditions over checks directly. A policy can say "if `impossible_travel` and `ip_is_vpn`, challenge" without ever going through a risk score.

The complete, current list of checks and their conditions lives in the policy editor in the dashboard.