CA RiskMinder UNIX Installation Guide › Upgrading RiskMinder › Upgrading to Release 3.1 › Reviewing Configuration Changes After Upgrade

Reviewing Configuration Changes After Upgrade

This section lists the changes that you can expect to see after you upgrade to RiskMinder 3.1.

Silent Execution of Rules

A rule whose score is 0 is considered to be a silent rule. Such a rule is not used for scoring. This feature allows you to observe how a rule would execute during transactions, without the risk of unintended effects on end users. In earlier releases, a rule whose score is 0 always generates the ALLOW advice.

Deleted Rules Listed in the Active Set

When you delete a rule, it continues to be displayed in the active set. In addition, a message stating the rule is deleted is displayed in the proposed set.

Deleting Rulesets

You can delete rulesets that are not currently assigned to any organization.

Custom Actions

You can add custom actions and then use these actions to build rules. For more information, see Adding Custom Actions.

Instance and Protocol Configuration

Logging parameters, such as log directory, log file size, log backup directory, log level, and log timestamps, which existed in the riskfortserver.ini file can now be edited from the Instance Management page in Administration Console.

Server parameters, such as maximum threads and minimum threads, which existed in the riskfortserver.ini file can now be edited from the Protocol Configuration page in Administration Console.

Model Configuration

Model Configuration is performed at the global level and is no longer specific to rulesets. Only the Master Administrator can edit the model configuration parameters. The Global Administrator can enable or disable the model at the global level and at the organization level.

User Creation Mode

The User Creation Mode configuration that was available at the ruleset level in previous releases is now available as User Enrollment Mode at the organization level.

Machine FingerPrint (MFP) Threshold

MFP Threshold configuration parameter in previous releases is now part of the Device MFP Not Match rule.

Reverse Lookup Configuration

After upgrade, reverse lookup configuration for Device MFP and IP address are available at the channel level. You can configure these parameters, Enable Reverse Lookup for Device Identification and Use IP Address for Reverse Lookup, on the Miscellaneous Configurations page.

Annotation in Risk Evaluation API Response

The Risk Evaluation API response contains all rule results in a field called annotation. In RiskMinder 1.7.0.3, the annotation field contained the rule results, USERDIDMATCH=Y or USERDIDMATCH=N, though USERDIDMATCH was not a rule available on Administration Console. This issue was resolved in RiskMinder 3.0 and now the annotation field contains only the results of rules that are configured through Administration Console. If your calling application used this annotation in RiskMinder 1.7.0.3 and you require this feature after upgrade, you can use the USERDEVICEIDASSOCIATED rule, which is equivalent to the USERDIDMATCH rule.

Rules Based on User Device Association and DeviceID-MFP Match

RiskMinder 1.x had Base Combination rules. From RiskMinder 1.7, you could configure these rules in Administration Console. These rules were based on User-DeviceID match and Machine FingerPrint match rules and were separate from Standalone rules in Administration Console. After upgrading to RiskMinder 3.1, you can use the User Associated with DeviceID (USERDEVICEASSOCIATED) and Device MFP Match (SIGMATCH) rules to re-create these combination rules with appropriate rule mnemonics.

The default score for the combination rules in RiskMinder releases 1.5.1.6 and earlier was as follows:

• USERDEVICEASSOCIATED AND SIGMATCH: 10
• NOT (USERDEVICEASSOCIATED) AND SIGMATCH: 65
• USERDEVICEASSOCIATED AND NOT (SIGMATCH): 65
• NOT (USERDEVICEASSOCIATED) AND NOT (SIGMATCH): 85

The default score for the combination rules in RiskMinder releases 1.5.1.7 and later till 2.0 was as follows:

• USERDEVICEASSOCIATED AND SIGMATCH: 10
• NOT (USERDEVICEASSOCIATED) AND SIGMATCH: 65
• USERDEVICEASSOCIATED AND NOT (SIGMATCH): 65
• NOT (USERDEVICEASSOCIATED) AND NOT (SIGMATCH): 65

Ruleset Configuration

The following ruleset configurations are not available after the upgrade:

• Creating a new ruleset by referring to another ruleset
• Editing rule configurations to refer to another ruleset
• Edit a rule to copy from another ruleset

Amount Check Rule

If you had an Amount Check rule for an organization associated with a channel that does not have the AMOUNT element, then you must manually re-create this rule after the upgrade. If your rule needs to set different thresholds for different currencies, then you must add AMOUNT as a channel element. If you expect transactions based on only a single currency, then you can create a simple numeric comparison rule using the CUSTOM element in Rule Builder.

Note: The DEFAULT channel does not have the AMOUNT element. Note the configuration of the Amount Check rule before upgrade and re-create after upgrade, if required.

New Rules and Deprecated Rules

Four of the predefined rules have been deprecated in this release. Alternative rules have been introduced for these deprecated rules. The following table lists the deprecated and new rules and rule mnemonics:

Important! Although these rules have been deprecated, they are still available and can be used after you upgrade to release 3.1. However, it is recommended that you replace each deprecated rule with the corresponding new rule by making the required changes in the rule expression.

For any of the four deprecated rules, if the rule evaluates to No, then the rule is considered to have matched. It is then used for scoring. In contrast, each of the other predefined rules are considered to have matched when they evaluate to Yes.

In each of the four new rules introduced in release 3.1, if the rule evaluates to Yes, then the rule is considered to have matched. In this way, the four new rules are consistent with the other predefined rules.

Rule Migration

All rules are migrated to the DEFAULT channel for all Actions supported by default in the system.

Rule Execution Priority

After you upgrade from RiskMinder 2.x, you do not have to enable or disable the rules for execution. The execution priority is automatically determined by the system.

Secondary Authentication Result

Transactions in RiskMinder 2.2.5.11 that had the Secondary Authentication Result status Not Available now appear with the status Abandoned after the upgrade.

Untrusted IP Type Configuration After Upgrade

RiskMinder releases prior to 1.7 allowed you to configure Negative IP Types as Active, Suspect, or Private from the Administration Console. From RiskMinder 1.7, the Active, Suspect, Private, Inactive, and Unknown negative type categories are derived from the data provided by our Intelligence Partner. So, if you had configured any Negative IP Type as Active, Suspect, or Private in your RiskMinder 1.6.0.x or earlier deployments, then after upgrading to 3.1, these IP types are migrated to the "Negative" category of the Untrusted IP Type.

Cache Refresh

After you upgrade from RiskMinder release 2.x or later, you can refresh the cache of all server instances from Administration Console. If you choose to use the command-line option, you must now refresh the server instances using the arrfclient tool instead of the arrfadmin tool.

Case Assignment After Upgrade

After you upgrade from RiskMinder release 2.x or later, all cases that were generated in the previous release continue to remain assigned to the Default Queue for the organization.

Note: In RiskMinder 2.0, cases were assigned to each Customer Support Representative (CSR), but from RiskMinder 2.2 onwards, cases are not assigned to individual CSRs. For more information, see the CA RiskMinder Administration Guide.

All new cases that are generated after you upgrade to RiskMinder 3.1 are assigned to the relevant Queue according to the Queue criteria defined by the Queue Manager in RiskMinder 3.1.

Calling Application Code Changes

The following list describes the changes to the calling application code after upgrade:

• The older Java SDK client will continue to work with the new installation of RiskMinder Server. The client code will not require any modification if you continue to use the old SDK. However, the new SDK provides additional functionality and it is recommended that you integrate the calling application code with the latest release of SDK.
• Applications integrated using old Risk Evaluation WSDL will continue to work without modification in the code.

Note: For RiskMinder 1.x releases, Web services were built as a WAR implementation. The client must continue to point to the old Web service even after upgrading to RiskMinder 3.1.
In RiskMinder releases 2.0 and later including RiskMinder 3.1, Web services are implemented as part of RiskMinder Service and not as a WAR. It is recommended that you integrate your applications using the new WSDL and configure your application to RiskMinder Service according to the new architecture.

• In previous releases, the Issuance Java API provided a programmable interface, which could be used by Java clients (such as Java Servlets and JSP pages) to send Issuance-related requests to RiskMinder Server. In RiskMinder 3.0, the Issuance API (Issuance) has been deprecated. Now, you must use the User Management Web service (ArcotUserRegistrySvc) for this purpose.
• If you were using the Exception User Web service shipped earlier, you must now use the new RiskMinder Administration Web service WSDL implemented in RiskMinder Service that provides the Exception User API.
• It is recommended that you use the enhanced RiskMinder 3.1 risk evaluation APIs that now return response codes and reason codes.

Role Privileges

After you upgrade from RiskMinder 2.x, you must review the privileges associated with the various roles. The following table lists the privileges that have been deleted after upgrade for the Master Administrator, Global Administrator, and Organization Administrator roles.

The following table lists the privileges that have been added after upgrade for the Master Administrator, Global Administrator, Organization Administrator, and User Administrator roles.