RiskMinder Web Services Developer's Guide › Understanding RiskMinder Workflows › Enrollment Workflows › Explicit Enrollment › Scenario 1

Scenario 1

If you call the createUserRequest message in the ArcotUserRegistrySvc Web service before the evaluateRisk operation, then the steps for the explicit enrollment workflow are:

1. User logs in to your online application.

   Your system validates if the user exists in the system. If the user name is not valid, then your application must take appropriate action.

2. Your application calls RiskMinder’s createUserRequest message.

   Your application must make an explicit call to the createUserRequest message in the ArcotUserRegistrySvc Web service. In this call, you must pass all relevant user details, such as the user’s first name, last name, organization, email, and their personal assurance message (PAM) to RiskMinder.

   Book: See "Managing Users and Accounts" in the CA RiskMinder Web Services Developer’s Guide for detailed information about the createUserRequest message.

3. RiskMinder creates the user in the database.

   If the createUserRequest call was successful, then RiskMinder creates the user record in the RiskMinder database. With this, user is enrolled with RiskMinder.

4. Your application collects information required by RiskMinder.

   Your application collects the following information from the user’s system that will be used by RiskMinder for analyzing the risk:

   • User system information that includes operating system, platform, browser information (such as browser language, HTTP header information), locale, and screen settings. Your application uses RiskMinder's Utility Script called riskminder-client.js to collect this information.
   • Device information that includes Device ID, which is stored on the end user's device.
   • Transaction information that includes the name of the channel being used by the user, a numeric identifier for the transaction, and some other information about the transaction.
   • Location information that includes the IP address and Internet Service Provider related information.
   • (Optionally, if you are using additional information) Additional Inputs that are specific to custom rules or the channel selected.
5. You application calls RiskMinder’s evaluateRisk for risk analysis.

   In this case, because you enrolled the user before performing risk analysis, the RiskMinder system "knows" the user and does not generate the ALERT advice. Refer to "Risk Evaluation Workflows" for more information.

6. RiskMinder performs risk analysis.

   RiskMinder generates a risk score and an advice.

7. Your application stores the Device ID on the end-user’s system.

   Your application must store the Device ID returned by evaluateRisk as a cookie on the device that the end user is using for the current transaction.

The following figure illustrates the explicit enrollment workflow when you call the createUserRequest message before the evaluateRisk call.