Decisioning with Device Fingerprinting

In the Stytch fraud prevention framework, decisioning is a key phase of prevention. Given a particular set of signals, do we think this is a good user or a bad actor? Is it benign activity, or fraudulent or abusive behavior?

Stytch Device Fingerprinting (DFP) provides useful decisioning as a starting point through Verdicts. You can use the recommended verdict action directly. Or, you can extend the verdict with your own custom decisioning logic.

Device Fingerprinting supports decisioning with the following features:

1. Verdicts
2. Setting rules
3. Overriding verdict reasons
4. Intelligent Rate Limiting
5. Custom decisioning logic

Every response from the Lookup API contains a verdict. A verdict consists of:

1. A recommended action: ALLOW, BLOCK, or CHALLENGE
2. The reasons or warning flags that explain the recommended action, e.g. HEADLESS_BROWSER_AUTOMATION, JAILBROKEN_DEVICE, or RULE_MATCH
3. Additional metadata, like the detected device type

Device Fingerprinting Verdicts are designed to be highly precise and explainable, with the goal of ensuring real human traffic for your application. There are no opaque floating-point "risk scores" where you must guess an appropriate threshold.

You can use the recommended verdict action directly, or use it as an input into your own decisioning logic.

To learn more, see Verdicts overview.

As you learn from your fraud prevention analysis and feedback loop, you may find that you want to explicitly increase or reduce friction for specific fingerprints.

Setting rules enables you to customize verdicts. For example, you can set a rule to always ALLOW a known-good user, or manually BLOCK a fingerprint that is associated with a repeat abuser's sockpuppet accounts.

To learn more, see Setting rules with DFP.

You can also customize verdicts in a broader way by adding a verdict reason override, which changes the default action associated with a verdict reason (warning flag).

For example, you can configure VIRTUAL_MACHINE to ALLOW if you expect many legitimate virtual machine users, or you can configure KNOWN_DATACENTER_IP to CHALLENGE if you prefer to add more friction for datacenter traffic.

To learn more, see Overriding verdict reasons.

Intelligent Rate Limiting is a feature of Device Fingerprinting that uses fingerprints for highly-precise rate-limiting. When Stytch detects high-velocity traffic from a single origin and set of fingerprints, Intelligent Rate Limiting automatically updates the verdict with escalating friction from CHALLENGE to BLOCK.

Unlike traditional IP-based rate limiting, the fingerprint-based approach ensures that you don't accidentally block good users who happen to share the same enterprise or university network as an attacker.

For suspicious fingerprints that are not associated with any known hardware and software configuration, Intelligent Rate Limiting also sets lower rate limits, which caps the impact of novel attacks without penalizing real users with unusual devices.

To learn more, see Intelligent Rate Limiting.

While Stytch Device Fingerprinting provides recommended actions through the verdict, you may be able to make better decisions after factoring in your own proprietary data, application workflows, and business needs.

Here are a few representative examples of how Stytch customers have added custom decisioning logic:

• One of your enterprise customers always uses an enterprise VPN that triggers a CHALLENGE due to POSSIBLE_TLS_MITM. You write custom code that ALLOWs all users from that enterprise (based on their organization and IP address), as long as POSSIBLE_TLS_MITM is the only warning flag present.

• Your business is highly-sensitive to false positives, so you never want to BLOCK a user automatically. Instead, you write custom code that permits all BLOCK verdicts to proceed, but logs each verdict to an internal auditing system for manual review.

• Your fraud team already has a sophisticated ML-based "risk engine" that integrates data from across the whole system. You can treat Device Fingerprinting verdicts like any other data, and feed them to your ML models. In this scenario, you will continue using the output of the risk engine for decisioning.

  • Note: The standard Device Fingerprinting Lookup API does not expose many of the raw signals collected, which may be useful in this scenario. If you are interested in additional raw signal data, contact support@stytch.com or your account team.

Once you've made a decision, you'll need to take action. Learn about your options for Enforcement with Device Fingerprinting.