High-Risk Events

ShieldLabs detects Multi-accounting, Account sharing, Impossible travel and Account takeover using more than 47 rules and heuristics. They compare device, browser and network characteristics with account history. Each event has Medium or High confidence, assessed separately from an identification’s Risk Score. Pass a stable pseudonymous User HID on authenticated checks so ShieldLabs can associate observations with the account.

​

The four events

​

Multi-accounting

Identifies groups of accounts linked by shared device, cookie or network evidence. Review the cluster’s members and the evidence connecting them. A shared public IP alone is not enough to conclude that the accounts belong to one person. ShieldLabs uses more than seven rules and heuristics developed by our data analytics team. The system completely reassesses connections between all authenticated accounts on one site at least once every 10 minutes. Its Hardware ID technology uses hardware characteristics to match activity from one device across browser changes; browser and operating system provide additional context. Group changes use the separate hre.multi_account.changed webhook, not a multi_accounting flag inside each scored identification. The event reports detected, updated or resolved, with the complete available membership and a revision. In Analytics, select the minimum number of related accounts to display, starting at three. This is a display filter. The account card’s graph shows the related accounts and the data connecting them. See Multi-accounting.

​

Account sharing

Identifies account activity associated with multiple detector-defined devices. Review the device observations and evidence in the account’s cluster. ShieldLabs uses more than 10 rules and heuristics to detect sharing and reduce false positives. It counts devices observed on the authenticated account in the last 90 days. Multiple browsers on one physical device count as one device; its Hardware ID technology supports that matching. A new device is evaluated on the check where it appears, and the result is delivered in that check’s identification.scored webhook. There is no separate Account sharing webhook. The scored webhook can return devices, min_devices and devices_at_least with the evaluation. Read those fields instead of hard-coding a threshold or interpreting a lower-bound count as an exact membership size. In Analytics, select the minimum number of different devices to display, starting at four. The account card’s graph shows the devices and their supporting evidence. See Account sharing.

​

Impossible travel

Detects an account appearing in locations it could not have reached in the time between observations. ShieldLabs uses more than 10 rules and heuristics to reduce false positives. The cluster contains the previous and current checks of one authenticated account, no more than 48 hours apart. Each qualifying pair forms a separate cluster and is reported in the new check’s identification.scored webhook. There is no separate webhook. No event is created when VPN, Proxy, Tor or Private Relay is detected. The comparison uses address coordinates, timing, Cookie, Device ID, browser and operating system. A recognized same-device result is not shown as travel merely because the mapped country changed. Two different cookies that had already appeared on the account by the time of their respective checks count as two devices. Medium or High requires at least 300 km and a speed above 800 km/h. High requires different devices plus one of: a speed above 1,000 km/h over at least 500 km, both checks within 30 minutes, or a country change. If devices cannot be compared, confidence is no higher than Medium. The account card shows the two checks behind the event. See Impossible travel.

​

Account takeover

Detects changes in an account’s environment that indicate possible unauthorized use. Review the previous and triggering observations before choosing a recovery or verification step. ShieldLabs uses more than 20 rules and heuristics to compare device, Cookie, browser context, operating-system history, countries, IPs and masking indicators with the account’s history. A country or network change alone does not trigger the event when the device is recognized as familiar. Changing browsers on the same recognized device also does not, by itself, trigger Account takeover. A qualifying new-device visit creates an event card and reports the result in that check’s identification.scored webhook. Subsequent visits from an already familiar device do not, by themselves, create another event. There is no separate webhook or group of other accounts. The account card’s graph shows the current check and the historical observations used in the evaluation. See Account takeover.

​

Confidence

Medium and High describe the evidence for an event. They are not numeric Risk Scores and do not add points to a check. The level depends on the combination and consistency of supporting evidence. More accounts or devices alone do not explain High confidence. Read the level in the context of the event type and its returned level field. See Medium / High confidence. An account can have low-scoring identifications and still have a High-Risk Event. Read the event and its confidence separately from the account’s current risk category. See Identity risk.

​

Cluster lifecycles

Multi-account groups, account-sharing device sets, impossible-travel pairs and account-takeover observations have different cluster lifecycles. A null cluster_id in a per-check result means no cluster reference was supplied; interpret the detection through status and level. The Cluster ID reference explains when identifiers persist or change, how group splits and merges are delivered, what happens after 90 days, and which events do not send a separate resolution notification.

​

Where you see High-Risk Events

• Overview: recorded event counts for the selected period, with coverage information.
• Analytics: filters for the accounts and activity associated with an event.
• User card: event tags and clusters, with evidence you can inspect.
• Scored webhook: per-check hre evaluations for sharing, travel and takeover.
• Group-change webhook: separately enabled multi-account lifecycle updates.

A result marked not_evaluated, not_applicable, or unavailable does not mean that the detector evaluated the account and found no event. A partial graph or recorded-history warning also limits what the screen can establish.

​

Acting on an event

Use the account token to find your application account. For sensitive actions, require verification, hold a reward or payout for review, or apply your account-sharing policy. Check the evidence and legitimate shared-device cases before taking an irreversible action. For group updates, process revisions in order per group and make repeated delivery idempotent. A resolved group is a lifecycle update, not an instruction to reverse every earlier business decision. Next: Investigate a user, Webhook setup, Acting on results.