Skip to main content

Overview

Decisioning is a key phase of prevention in our fraud prevention framework.
Stytch fraud prevention framework
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? Device Fingerprinting’s verdicts provide a useful starting point for decisioning. 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. Set rules
  3. Override verdict reasons
  4. Intelligent Rate Limiting
  5. Custom decisioning logic

Verdicts

Every response from the Lookup API contains a verdict, consisting of:
  • A recommended action.
  • Reasons or warning flags that explain the recommended action.
  • 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.

Set rules

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.

Override verdict reasons

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.

Intelligent Rate Limiting

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.

Custom decisioning logic

While 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. Examples of how current 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.
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.

Next steps