Digital Fraud Prevention Overview: Capabilities, Operating Principles, and Use Cases

Digital Fraud Prevention (DFP) is a solution that creates persistent fingerprints of the client environment and analyzes additional request signals.

Put simply, DFP provides an ID for a unique combination of a specific browser and device that sent a request. This ID remains stable even if the user later tries to hide information about themselves: clears cookies, enables a VPN, opens an incognito tab, or changes computer settings. With these IDs, you can tell one user’s actions from another user’s actions more accurately.

DFP also provides additional context: whether a request was made by a person or a bot, whether a VPN was used, whether the source IP belongs to a hosting subnet, whether suspicious activity has been seen from that subnet, and other signals important for anti-fraud logic.

You can use this data in your business scenarios. For example, you can identify a user without cookies, detect multi-accounting, or detect stolen cookies or authentication tokens.

Try DFP

We have embedded the DFP widget directly on this page. Below, you can see the result of checking your environment. Feel free to test it: open the article in different browsers or on different devices, enable and disable a VPN, or switch to incognito mode. You will see how the result changes.

What You Learn About Every Request

For the full list of fields returned by DFP, see What DFP Response Fields Mean. For guidance on interpreting this data and using it in your business logic, see How to Interpret a DFP Response.

DFP provides three important types of data:

  • a persistent identifier of the client environment that sent the request: user_id;

  • an estimate of how likely the request was made by automation: bot_score;

  • additional data about the browser, device, network, and other request signals.

User ID

user_id is a persistent identifier of the client environment.

Put simply, it is an ID that describes a unique combination of a specific browser and device. The ID remains stable even when a user changes settings. For example, if the user:

  • enables a VPN;

  • opens an incognito window;

  • updates the operating system;

  • changes the time on their computer;

  • updates the browser version.

The ID stays the same because the main condition is met: the device and browser are still the same.

If the user opens another browser or sends a request from a new device, you will see a new ID. This is because every browser-device pair has its own unique ID.

Bot Score

bot_score is a number from 0 to 1. It shows how many signs of automation, browser parameter spoofing, and other anomalies typical of bot activity a request contains.

You can use the following guideline:

  • < 0.4: the request was made by a person;

  • from 0.4 to 0.5: there are suspicious signals; a bot may have made the request;

  • >= 0.5: the request was very likely made by a bot.

Additional Data

In addition to user_id and bot_score, DFP provides additional data about the client environment and request. This data helps you understand the context and configure your business logic more accurately.

DFP provides the following signals:

  • engine: the browser engine in use, for example Blink, WebKit, Gecko, or another engine;

  • hosting: whether the IP address belongs to a hosting subnet;

  • bot_hosting: whether the IP address belongs to a hosting subnet from which we have detected bot activity or other suspicious activity;

  • incognito: whether the browser is in incognito or private browsing mode;

  • isp_active_subnet: whether the IP belongs to an active Internet service provider subnet used to connect private or corporate customers to the Internet;

  • mobile: whether the request came from a mobile device;

  • os: the operating system in use, for example Windows, macOS, Linux, iOS, or Android;

  • vpn: whether there are signs that a VPN is being used;

  • new_user: whether this client environment is visiting your resource for the first time;

  • confidence_score: how confident DFP is that the user_id was identified correctly.

What DFP Helps You Address

DFP is useful when you need to understand the client environment and request signals. For example, its data can help you:

  • identify users without cookies;

  • detect multi-accounting;

  • detect stolen cookies or tokens;

  • spot suspicious registrations;

  • protect promotions and welcome bonuses from abuse;

  • distinguish regular client traffic from automated traffic;

  • use VPNs, hosting subnets, suspicious activity from a subnet, incognito mode, and other signals in your business logic;

  • find repeated actions from the same client environment, for example completing a survey more than once.

We have prepared ready-to-use instructions for common scenarios that explain how to use DFP data to solve business problems:

How It Works

  1. You add the DFP JavaScript script to the required page of your website.

    If you need to understand how it works, contact technical support and we will explain it in detail.

    The script is obfuscated using anti-LLM techniques, so answers from AI tools during reverse engineering may be inaccurate or misleading. In addition, uploading the script to ChatGPT, Claude, Grok, or another AI service may result in your account being blocked by that service.

  2. A user opens the page and performs an action that requires a check, for example signing in, submitting a form, registering, or confirming an operation.

  3. The script collects client environment parameters.

    We recommend configuring the integration so that client environment data collection begins as early as possible, for example when the page opens, and the data is sent to the DFP API at the moment of the target action, such as signing in, submitting a form, or confirming an operation. This gives you a faster DFP response and improves its accuracy.

    For details, see the integration guide.

  4. The script sends the collected data to the DFP API.

  5. In the Strictera infrastructure, DFP analyzes characteristics of the browser’s network interaction while sending the request: automation signals, TLS handshake characteristics, L3/L4 network-layer data, and others.

  6. DFP analyzes all the data and creates a result: user_id, bot_score, and signals of VPN use, hosting subnets, subnets with suspicious activity, incognito mode, and more.

  7. DFP encrypts the result and returns it to the browser.

  8. The browser sends the encrypted response to your backend.

  9. Your backend decrypts the response and applies your business logic.

For a detailed description of the process, see How DFP Works.

How to Get Started

Getting started with DFP is easy:

  1. Send us a request. We will discuss your needs and suggest the best way to add DFP to your scenario. If your tasks require custom settings, we will agree on them separately and prepare a configuration for your product.

  2. We will provide you with:

    • CUSTOMER-TOKEN: a token for loading the JavaScript library and calling the API;

    • SECRET-KEY: the key your backend uses to decrypt the payload.

  3. You add the DFP JavaScript script to the required pages of your website, configure sending the result to your backend, payload decryption, and your business logic. You can do this by following How to Integrate Digital Fraud Prevention.

Send a request