Branches the journey according to risk recommendation obtained from Fraud Prevention
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., risk_recommendation.recommendation) or as a part of an interpolated string (e.g., You're using ${risk_recommendation.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).
- To use this step, Fraud Prevention must be enabled as the risk engine for your tenant. Identity Threat Protection and Fraud Prevention are mutually exclusive—contact your Customer Success Manager to enable the appropriate engine.
- Make sure Fraud Prevention is configured to work in the same region as other Mosaic services.
- For details on how to set up and initialize the Fraud Prevention SDK for mobile apps, see Steps 2 & 3 of Android quickstart or iOS quickstart. If the Fraud Prevention SDK is not initialized, the step fails with an
sdk_not_initializederror.
| Field | Description |
|---|---|
| User auth state | Indicates if the user has authenticated in this journey. Select Authenticated user (default) if the user context is provided implicitly by the journey. Select Unauthenticated user if the user hasn't been authenticated yet. |
| Claimed User ID | Yields the user identifier of the not yet authenticated user, used to enhance risk and trust assessments. Only relevant when User auth state is set to Unauthenticated user. |
| Claimed User ID Type | Specifies the type of value provided in the Claimed User ID field. This is especially important when the Claimed User ID contains a hashed value, as it clarifies the original data type used. Only relevant when User auth state is set to Unauthenticated user. |
| Action Type | Specifies the action being evaluated for risk, such as login, transaction, or password_reset. A full list is available here. |
| Transaction Data | Transaction-related data to include with the risk assessment request. |
| Custom Attributes | Custom attributes to include with the risk assessment request. |
| 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 risk_recommendation. 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. |
| Custom Branches | Custom branches that can be configured for the step. |
| 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. |
This step can be configured to record step input and output data, or a custom payload, which is then surfaced in journey events in Journey Analytics for diagnostic purposes. For details, see Additional data reporting.
In our example, the user attempts to login with their credentials. This step performs a fraud level analysis for the login event and defines how to proceed with the journey. For example:
- Trust/Allow: Proceed to a simple login and if 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).
- Deny: The login attempt is rejected, and the journey moves to the Reject Access step.
When executed, this step sends a callback to the client with the IDO service response object. It will have the journeyStepId set to drsTriggerAction and the data will include the action_type set to login. The client uses the data received from the Orchestration SDK as an input for Fraud Prevention SDK and triggers an action with the Fraud Prevention SDK. Having received the action token from the Fraud Prevention SDK, the client submits it to the journey using the Orchestration SDK call in order for the journey to fetch a recommendation and proceed accordingly.
Once the user is fully-authenticated, it is recommended to report the action result and set the user for all subsequent events in the device session. This is done by adding "Client Actions: Report action result API" step after the "Fraud Level Analysis" and submitting the action_token and user_id.
async function handleRiskRecommendations(idoResponse) {
const correlationId = idoResponse.data.correlation_id;
const claimedUserId = idoResponse.data.claimed_user_id;
const claimedUserIdType = idoResponse.data.claimed_user_id_type;
const actionType = idoResponse.data.action_type;
// Triggers an action event using the SDK
// If SDK was loaded via script tag, invoke functions inside 'window.tsPlatform'
const { actionToken } = await drs.triggerActionEvent(actionType, {
correlationId,
claimedUserId,
claimedUserIdType,
});
const data = { action_token: actionToken };
// Submits an action token to the journey using the Orchestration SDK
// If SDK was loaded via script tag, invoke functions inside 'window.tsPlatform'
await ido.submitClientResponse(ClientResponseOptionType.ClientInput, data);
}The risk recommendation is stored in the output variable (default: risk_recommendation) and can be used in subsequent steps to determine security policies dynamically.