Understand risk detection & mitigation components

To use DRS effectively, it's crucial to understand the core concepts that underpin the risk engine’s functioning. This document will first guide you through the built-in components that explain how the risk engine works. These concepts are grounded in machine learning and define how the system automatically evaluates threats and mitigates them. The key components that drive DRS risk assessment are:

• Recommendations : The system’s final suggestions regarding what actions should be taken to address potential risks.
• Telemetry : The raw data collected about user actions, devices, networks, and other relevant signals, which is evaluated by the system to determine the level of risk.
• Risk Score : A numerical representation of the likelihood that an action is malicious or fraudulent.
• Reasons : Explanations provided by the system for the assigned risk score, helping users understand why a certain risk score was given.

Building on these, this guide will then show how you can leverage DRS's customizable features to tailor the system’s responses to risks based on your organization's unique needs. The customizable features that influence how the system reacts to risk are:

• Rules : User-defined conditions that override or refine the system’s default recommendations.
• Labels : Categorizations applied by users that offer feedback to the system, improving its future assessments.
• Fine-Tuning Detection Sensitivity : Adjusting the weight of specific risk factors to ensure the system’s sensitivity aligns with your organization's risk tolerance.

Built-in components

Recommendations

Recommendations are the system’s final suggestions for mitigating the risk associated with a user action. These are generated by our machine learning-based risk engine, which evaluates the calculated risk score based on various signals tied to the user action. The calculation may also take into account any fine-tuning adjustments you have configured, such as risk detection sensitivity and custom rules. By providing these recommendations, the system ensures that the appropriate security measures are implemented in response to the assessed risk. The recommendation types are:

• Allow : The action is considered safe; proceed without additional challenges.
• Challenge : Additional verification is required (e.g., multi-factor authentication).
• Deny : The action is deemed too risky; block it entirely.
• Trust : Enhance user experience for highly trusted actions (e.g., extend session duration).

Recommendations help balance security and user experience by applying stricter measures only when necessary.

Example

Scenario: A customer of a bank attempts to transfer a large sum of money to a new beneficiary using the bank's online portal.

The system detects the New Device and New Beneficiary risk signals, checks if any rules impact these signals, adjusts the risk score based on the sensitivity settings for these signals, and, after assessing the overall risk, generates a Challenge recommendation. The user is prompted to complete a step-up authentication. If additional high-risk signals were present, such as unusual login time or known malicious IP address, the system might escalate the recommendation to Deny.

For the complete documentation about recommendations, see our dedicated page.

Telemetry

Telemetry refers to the raw data collected by the system before a user performs an action. As soon as the page loads and the SDK initializes, telemetry data begins streaming. This data includes various contextual attributes such as user behavior, device characteristics, location, and network information. Telemetry data can be summarized into:

• Device Information : Type, operating system, browser version.
• Network Data : IP address, geolocation, VPN or proxy usage.
• Behavioral Patterns : Mouse movements, click velocity, interaction timing.
• Historical Data : Previous login times, transaction history.

To learn more about telemetry and factors, see our Data Collection page.

Example

Continuing with the banking scenario, the customer is using a new laptop to access their account and is initiating a transfer to a beneficiary they've never transacted with before. From the collected telemetry, the system identifies the following signals:

• DEVICE_NEW : Unrecognized device.
• BENEFICIARY_NEW : First-time transfer to this beneficiary.
• TRANSACTION_AMOUNT_HIGH : Transfer amount is higher than typical for this user.
• NETWORK_VPN : Connection is through a VPN, possibly masking the true location.

Risk score

Risk represents the probability that a specific action is malicious or fraudulent. The risk score is calculated based on the evaluated risk signals derived from the telemetry data and the severity of the threats they pose. A higher risk score indicates a greater likelihood of fraudulent activity.

The risk score helps the system determine whether additional security measures are needed.

Example

In our scenario, the combination of New Device, New Beneficiary, High Transaction Amount, and Use of VPN results in a high-risk score. Individually, each factor might not trigger significant concern, but together they raise the risk level substantially.

For a breakdown of the risk evaluation, see our Risk Detection page.

Reasons

Reasons are automatically generated explanations that justify the assigned recommendation. Administrators can view these reasons for each recommendation to understand the factors that led to a specific outcome. This information is accessible within the recommendation details.

Reasons provide transparency into the system’s decision-making process, helping security teams trust and understand the assessments. The system evaluates reasons in a predefined priority order, with each relevant reason contributing to the final recommendation. This ensures that the most critical factors are considered. Examples of reasons include:

• DEVICE_NEW : The device used is not recognized by the system.
• BENEFICIARY_NEW : Transfer to a new beneficiary.
• TRANSACTION_AMOUNT_HIGH : Unusually high transaction amount.
• NETWORK_VPN : Use of VPN detected, possibly masking true location.

Example

The bank's security team reviews the recommendation details and sees the following reasons:

• DEVICE_NEW
• BENEFICIARY_NEW
• TRANSACTION_AMOUNT_HIGH
• NETWORK_VPN

Understanding these reasons helps the team validate why the system prompted the user for additional verification.

Customizable components

Rules

Rules are user-defined conditions that determine actions based on various risk signals, such as IP address or device fingerprint, etc. They allow you to customize system behavior by defining fixed recommendation outcomes when certain criteria are met.

Creating rules involves setting conditions based on risk indicators like IP addresses, device fingerprints, and other relevant signals. The system then evaluates these rules and applies the appropriate action.

Example

A bank might configure the following rules:

• Require step-up authentication for high-risk transactions : If an unrecognized device or a flagged IP is detected, the user must complete additional authentication.
• Deny transactions from restricted countries : Automatically block any transactions from IPs associated with high-risk countries.
• Allow low-risk transactions : If the device is recognized and no suspicious behavior is detected, allow the transaction without extra challenges.

Rules are evaluated based on priority; the system applies the action of the first matching rule and ignores subsequent ones.

For more details on rules, see our dedicated page.

Labels

Labels are tags or categorizations that you can apply to actions, or entities within the system after an action has been processed. They provide feedback to the system, helping refine future risk assessments by influencing the machine learning engine's understanding of risk patterns. Labels do not affect the current recommendation but influence future assessments.

The labels available are:

• Known Malicious : For entities confirmed to be involved in fraudulent activities.
• Suspected Malicious : For entities suspected of fraudulent behavior that has not yet been confirmed.
• Known Legit : For entities confirmed to be legitimate and not involved in fraud.
• Unknown : For entities whose fraud status is undetermined.

Example

After investigating, the bank confirms that the transaction was legitimate. The security team applies the Known Legit label to the customer's new device and beneficiary. This helps reduce friction in future transactions involving these entities.

For more about labels, see our dedicated page.

Fine-Tune Detection Sensitivity

Fine-tuning detection sensitivity allows you to adjust the importance assigned to specific factors, aligning the system's sensitivity with your organization's risk tolerance.

Factors are specific attributes derived from the telemetry data that the system evaluates to calculate the risk score. If multiple factors are detected, the system evaluates them in combination. Factors include various indicators of risk, such as anomalies or deviations from normal patterns.

By customizing the detection sensitivity, you can influence how the system prioritizes specific risk factors in its recommendations. By fine-tuning sensitivity, you can:

• Adjust the weight of each risk factor (e.g., Low, Default, High).
• Ignore certain factors if they are not relevant to your organization.
• Set factors to "Deny" to automatically block any activity associated with them.

Example

If the bank notices an increase in fraud involving VPN usage, they can set the NETWORK_VPN factor sensitivity to High or Deny to automatically challenge or block transactions originating from VPNs.

For more, refer to the Fine-Tune Detection Sensitivity guide.

Next steps

Now that you have a clear understanding of how the DRS components work together to assess risk and generate recommendations, you can explore the full process by visiting our Risk Detection & Mitigation Flow page.