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.
The system starts collecting telemetry as soon as the page loads and the SDK is initialized.
The system continuously gathers telemetry data such as device information, network data, and user behavior. This happens before any user action is performed.
The user performs an action, such as logging in or making a transaction.
The system evaluates the collected telemetry to derive risk signals and calculates a risk score based on these signals. For details on how the risk score is calculated, see our Risk score calculation overview.
The system generates reasons explaining the assigned risk score.
If you have defined rules, the system evaluates them to potentially override or adjust the 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.
After the action is completed, administrators can apply labels to entities involved in the action based on the outcome.
The labels instruct the risk engine to influence future risk assessments involving the labeled entities.
This section retraces the steps of the flow as applied to a real-life use case scenario.
A customer attempts to transfer $10,000 to a new beneficiary using the bank’s mobile app on a new smartphone.
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.
The customer initiates a $10,000 transfer to a new beneficiary using the bank’s mobile app.
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.
The system generates the following reasons for the high-risk score:
- DEVICE_NEW
- BENEFICIARY_NEW
- TRANSACTION_AMOUNT_HIGH
- GEOLOCATION_UNUSUAL
- NETWORK_WIFI_PUBLIC
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.
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.
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.
- 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.
- 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.