Fine-tune detection sensitivity

Mosaic’s fraud engine monitors user interactions (e.g., telemetry and user actions) and applies ML detection models to generate risk reasons that justify recommendations. The risk score is calculated based on the combination of reasons contributing to the assessment. For more details on how risk is calculated after fine-tuning detection sensitivity, refer to the examples below.

You can customize the detection sensitivity to meet your specific risk requirements by fine-tuning the importance assigned to each type of risk factor. For each factor, define its impact on the score calculation using options like ignore, low, default, high, or deny (Admin Portal > Detection and Response > Configuration > Detection Sensitivity).

For example, in the event of detecting a sudden surge in bot attacks, an organization can quickly implement ad-hoc detection sensitivity settings, setting the Bot parameter to Deny. This will systematically block all bot activity until a proper strategy is defined.

fine-tune detection sensitivity
IMPORTANT

Before pushing your custom detection policy into production, we strongly recommend saving the preview policy configurations and testing their effectiveness using the Recommendations dashboard or our Conversational Analytics tool. Fine-tuned configurations will not affect production processes until actively deployed.

For more details on how risk is calculated after fine-tuning detection sensitivity, refer to the examples below.

How it works

Fine-tuning detection sensitivity allows you to adjust how the system prioritizes specific risk factors in its recommendations. While the core scoring mechanism—continuously refined by machine learning—remains intact, sensitivity settings let you amplify or reduce the weight of certain factors, ensuring that recommendations align with your organization's risk tolerance.

This method balances the rigor of the system’s scoring with the need for customization, enabling refined recommendations that support your business goals without sacrificing reliability.

Sensitivity metrics

The mapping function used in this feature is non-linear. Extreme values like Deny or Allow have a significant impact on recommendations due to their amplified preferences. Selecting different adjustment options affects risk recommendations in specific ways:

  • Ignore : Neutralizes the parameter's impact on the recommendation.
  • Low , Default , High : Adjusts the sensitivity incrementally.
  • Deny : Automatically blocks any activity associated with the parameter.

Adjusted recommendation calculation

The adjusted recommendation is calculated based on both the detected risk factors (dominant reasons) and the sensitivity settings you've configured for each parameter. When the system identifies certain risks during an event, it evaluates them according to your specified preferences. Here's a breakdown of the process:

  1. Calculate Risk Detection : The system detects dominant risk reasons based on the event's characteristics (e.g., Bot activity, Impossible Travel).
  2. Evaluate Sensitivity Settings : For each risk parameter, you've set an adjustment option— Ignore , Low , Default , High , or Deny —that determines how much weight that risk factor carries in the assessment.
  3. Adjust Recommendation : The system combines the detected risks with your sensitivity settings to produce a final recommendation ( Allow , Challenge , or Deny ).

This process allows you to fine-tune how sensitive the system is to specific risks without changing the underlying risk detection mechanisms. Your configurations influence the outcome by amplifying, reducing, or neutralizing the impact of certain risk factors.

Examples

These examples illustrate how the combination of detected risk factors and your configured sensitivity settings interact to determine the final recommendation. By carefully selecting sensitivity levels, you can ensure that the system's recommendations align with your organization's risk tolerance and security policies, while maintaining robust security measures.

Example 1: Neutralizing risk factors

Imagine you have set the risk sensitivity for Impossible Travel to Ignore and Suspicious Network to Default. If an event occurs where the system detects both risk factors, your configuration will neutralize the impact of Impossible Travel on the risk assessment, but Suspicious Network will still influence the outcome.

Example 1: Neutralizing risk factors

Although Impossible Travel is ignored, the presence of Suspicious Network at the default sensitivity poses a significant (but not critical) risk that cannot be overlooked. As a result, the system will generate a Challenge recommendation for this event. Under the hood, the system balanced the neutralization of Impossible Travel with the moderate risk from Suspicious Network and opted for a mitigated recommendation.

Example 2: Combining risk factors

Suppose you have configured New Device to Default and set Bot to High sensitivity. If an event occurs where the system detects both risk factors, both will be considered in the risk assessment, with Bot having a greater impact due to its higher sensitivity setting.

Example 2: Combining risk factors

The system will assess the high severity of both risk factors combined, resulting in a Deny recommendation. Under the hood, the system, detecting significant risks across both factors, resulted in a blocker recommendation.