Overview
Decisioning is a key phase of prevention in our fraud prevention framework.
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.
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
ALLOWa known-good user, - Or manually
BLOCKa 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_MACHINEtoALLOWif you expect many legitimate virtual machine users, - Or you can configure
KNOWN_DATACENTER_IPtoCHALLENGEif 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 fromCHALLENGE 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
CHALLENGEdue toPOSSIBLE_TLS_MITM. You write custom code thatALLOWs all users from that enterprise (based on their organization and IP address), as long asPOSSIBLE_TLS_MITMis the only warning flag present. - Your business is highly-sensitive to false positives, so you never want to
BLOCKa user automatically. Instead, you write custom code that permits allBLOCKverdicts 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.