Risk Recommendation
Gets recommendations for handling user requests to perform sensitive actions (like login) based on real-time risk.
Description
This step is used to obtain risk recommendations so you can detect and respond to real-time risk. For example, this allows you to request additional verification when bots are detected during account opening or to step up authentication when a user is trying to login from a suspicious device or location.
Use this step before the user performs a sensitive action in order to detect risk and help you decide how to respond. The journey automatically evaluates the risk and proceeds to the appropriate branch based on the recommendation (either trust, allow, challenge, or deny). If defined, an output variable will store the risk recommendation result. In addition to a recommendation itself (allow, trust, deny, or challenge), the result includes more details such as risk score, reasons, and device details. This data can be used in subsequent journey steps in the expression fields (e.g., account_protection_result.recommendation) or as a part of an interpolated string (e.g., You're using ${account_protection_result.context.browser_name}).
Risk recommendations are provided by Mosaic's Fraud Prevention based on telemetry streamed by the client. It includes device, network, and other context data used to continuously assess risk. For Web, Fraud Prevention functionality is bundled with Journeys in the same SDK. For mobile apps, use a dedicated SDK: Fraud Prevention SDK (iOS) or Fraud Prevention SDK (Android).
Note
- Make sure Detection and Response services are configured to work in the same region as other Mosaic services.
-
For details on how to set up and initialize the Detection and Response SDK for mobile apps, see Steps 2 & 3 of
Android quickstart
or
iOS quickstart
. If the Detection and Response SDK is not initialized, the step fails with an
sdk_not_initializederror.
Configuration
| Field | Description |
|---|---|
| Action Type | Specifies the action being evaluated for risk, such as login, transaction, or password_reset. A full list is available here. |
| User Auth State | Indicates if the user has authenticated in this journey. - If set to The user is authenticated (default), the user context is provided implicitly by the journey. - If set to The user is not authenticated, a user identifier must be provided (see raw below). |
| User Identifier | The internal User ID used when the user is not authenticated. This identifier must match the claimed user ID in the recommendation actions table and is specified as an expression. Only configured if the journey doesn't authenticate the user before invoking this step. |
| Output Variable | Name of the variable used to store the result data from the completed step, which can be used in subsequent journey steps. Default is account_protection_result. The object has the structure that's described here. In addition to a recommendation itself (allow, trust, deny, or challenge), it includes more details such as risk score, reasons, and device details. |
| Error Behavior | Determines the behavior in case an unexpected error occurs during the process. You can choose to either abort the journey (default) or handle errors using a dedicated error branch. |
Example
In our example, the user attempts to login with their credentials. This step obtains a risk recommendation for the login event and defines how to proceed with the journey. For example:
- Trust / Allow : The login is successful, and the journey proceeds to the Complete Journey step.
- Challenge : The user must complete an additional authentication step (e.g., an Email OTP Authentication) before proceeding.
- Deny : The login attempt is rejected, and the journey moves to the Reject Access step.
The risk recommendation is stored in the output variable (default: account_protection_result) and can be used in subsequent steps to determine security policies dynamically.