Risk detection & mitigation flow

This article outlines the process the system follows from the moment a user initiates an action, through data collection and risk scoring, to the final recommendation. This flow demonstrates how telemetry data is used to calculate risk scores, apply rules, and generate actionable recommendations (such as allow, challenge, or deny). The system can optionally adjust these outcomes based on rules and labels to further refine risk evaluations and improve decision-making in real time.

Flow steps overview

No
Yes
Yes
No
1. Page Load
2. Telemetry Data Collection
3. User Action Initiation
4. Risk Score Calculation
5. Generate Reasons
6. Apply Rules?
Final Recommendation
Adjust Recommendation
7. Execute Recommendation
8. Apply Labels?
Apply Labels
9. Instruct Risk Engine
End

➊ Page load

The system starts collecting telemetry as soon as the page loads and the SDK is initialized.

➋ Telemetry data collection

The system continuously gathers telemetry data such as device information, network data, and user behavior. This happens before any user action is performed.

➌ User action initiation

The user performs an action, such as logging in or making a transaction.

➍ Risk score calculation

The system evaluates the collected telemetry to derive risk signals and calculates a risk score based on these signals.

➎ Generate reasons

The system generates reasons explaining the assigned risk score.

➏ Apply rules (optional)

If you have defined rules, the system evaluates them to potentially override or adjust the recommendation.

➐ Final recommendation

The system provides a recommendation (Allow, Challenge, Deny) based on the risk score, reasons, and any applied rules.
When the recommended action is executed, the system may proceeds as follows, based on your configurations:

  • Allow : Proceed without additional challenges.
  • Challenge : Require additional authentication steps.
  • Deny : Block the action.

➑ Apply labels (optional)

After the action is completed, administrators can apply labels to entities involved in the action based on the outcome.

➒ Instruct risk engine

The labels instruct the risk engine to influence future risk assessments involving the labeled entities.

Real-life use case

This section retraces the steps of the flow as applied to a real-life use case scenario.

1.Page load and telemetry data streaming
2. Customer initiates $10,000 transfer
to a new beneficiary
using a new smartphone
3. System collects device info, network data,
behavioral patterns, historical data
4. System evaluates signals:

- DEVICE\_NEW
- BENEFICIARY\_NEW
- TRANSACTION\_AMOUNT\_HIGH
- GEOLOCATION\_UNUSUAL
- NETWORK\_WIFI\_PUBLIC

Result: high-risk score
5. System generates reasons
6. Rule 3 applies:
Deny transactions from public Wi-Fi
with new devices
7. System recommends `Deny`
Transaction is blocked;
user receives notification
8. Security team labels:

- `Device ID` as `Known Legit`
- `Public Wi-Fi` as `Known Risky`
9. Labels are sent to the risk engine

Scenario

A customer attempts to transfer $10,000 to a new beneficiary using the bank’s mobile app on a new smartphone.

➊ Page load and telemetry data collection

Before the customer takes any action, the system collects telemetry data, including:

  • Device Information : Details about the new smartphone.
  • Network Data : Information about the public Wi-Fi network.
  • Behavioral Patterns : User’s interaction with the app.
  • Historical Data : Customer’s previous transaction history.

➋ User action initiation

The customer initiates a $10,000 transfer to a new beneficiary using the bank’s mobile app.

➌ Risk score calculation

From the collected telemetry, the system derives the following signals:

  • DEVICE_NEW : The smartphone is not recognized.
  • BENEFICIARY_NEW : First-time transfer to this beneficiary.
  • TRANSACTION_AMOUNT_HIGH : The amount is higher than the customer’s typical transactions.
  • GEOLOCATION_UNUSUAL : The login is from a location different from usual (e.g., another city).
  • NETWORK_WIFI_PUBLIC : The connection is over a public Wi-Fi network.

The system evaluates these signals and calculates a high-risk score due to multiple high-risk indicators.

➍ Generate reasons

The system generates the following reasons for the high-risk score:

  • DEVICE_NEW
  • BENEFICIARY_NEW
  • TRANSACTION_AMOUNT_HIGH
  • GEOLOCATION_UNUSUAL
  • NETWORK_WIFI_PUBLIC

➎ Apply rules

The bank has set up rules to enhance security:

  • Rule 1 : If the risk score is above 80, deny the transaction.
  • Rule 2 : If the risk score is between 50 and 80, require MFA.
  • Rule 3 : Always deny transactions from public Wi-Fi networks when combined with new devices.

In this case, Rule 3 applies, leading to an adjusted recommendation.

➏ Final recommendation

Based on the high-risk score and the applied rule, the system recommends Deny. The transaction is blocked, and the user receives a notification that the transaction could not be processed.

➐ Apply labels

The security team reviews the incident and determines:

  • The customer confirms they were attempting the transaction.
  • The team decides to:
    • Label the Device ID as Known Legit .
    • Label the Public Wi-Fi Network as Known Risky .

➑ Influence future assessments

  • Future transactions from the customer’s smartphone will have a lower risk score due to the Known Legit label.
  • Any transactions attempted over the labeled Known Risky public Wi-Fi network will have higher risk scores.

Outcome

  • Security Maintained : The system effectively identified a high-risk transaction and blocked it according to predefined rules.
  • User Experience : While the legitimate transaction was initially blocked, the follow-up labels help reduce friction in future transactions from the customer’s device.
  • Improved System Intelligence : Labeling the public Wi-Fi network as risky enhances the system’s ability to detect and prevent potential fraud from that network in the future.