Working with Out-of-the-Box Rules

Managing rule configurations is a key part of RA management and optimization, and a key responsibility of GAs and OAs. This article explains rules and the related concepts. It then guides you through the steps for configuring the out-of-the-box rules that are automatically available when you install and bootstrap RA. It covers the following topics:
cara
Managing rule configurations is a key part of RA management and optimization, and a key responsibility of GAs and OAs. This article explains rules and the related concepts. It then guides you through the steps for configuring the out-of-the-box rules that are automatically available when you install and bootstrap RA. It covers the following topics:
2
What are Out-of-the-Box Rules
After the required data is collected, it is forwarded to Rules Engine (a module of Transaction Server). The Rules Engine is a set of configured rules that evaluate this information based on incoming information and historical data, if available.
A rule, in turn, is a condition or a set of conditions that must be true for a rule to be invoked. By default, each rule is assigned a priority and is evaluated in the specific order of its priority level. However based on your business requirements, you can change this priority of rule scoring.
See Out-of-the-Box Rules for a quick overview of the out-of-the-box rules.
How to Create and Deploy Out-of-the-Box Rules
You will need to use the Rule Configuration page in the Administration Console for:
  • Enabling or disabling the out-of-the-box rules
  • Configuring the risk score and priority of the out-of-the-box rules
The generic steps to configure an out-of-the-box rule are:
  1. Ensure that you are logged in as a GA or an OA.
  2. Activate the
    Organizations
    tab.
  3. Click the
    Search
    button on the page to display the list of organizations.
  4. Under
    Select Organizations to Modify
    , click the link with the organization’s name for which you want to delete the rule.
  5. Click the
    Risk Engine
    tab.
  6. Under the
    Rules Management
    section on the side-bar menu, click the
    Rules and Scoring Management
    link.
    The Rules and Scoring Management page appears.
  7. From the
    Select the Ruleset
    list, select the ruleset for which this configuration is applicable.
    The configuration information for the specified ruleset appears.
  8. For each rule, in the
    PROPOSED
    column of the displayed table:
    1. Select (to enable the rule) or clear (to disable the rule) the
      Enable
      option.
    2. Specify the required
      Risk Score
      .
    3. Select a priority for the rule from the
      Priority
      list.
  9. In the
    PROPOSED
    column for
    Default Score
    (the second table on the page), specify the required Risk Score.
    RA uses this value to generate the final Risk Score and Advice if none of the rules in the preceding table match.
  10. Click
    Save
    to save the changes you made on this screen.
    The changes are not yet active and are not available to your end users.
  11. To make the changes active, you must migrate them to production.
    Refer to How to Activate a Rule (Migrate Rules to Production) for instructions to do so.
  12. Refresh all deployed Transaction Server instances.
    Refer to How to Refresh Server Cache for instructions to do so.
How to Create a Device-Based Rule
RA allows you to create the following rules based on Device-User associations:
The following subsections briefly explain what these rules are and walk you through the steps for creating these rules.
How to Configure the Out-of-Box Device User Velocity Rule
The
Device Velocity Check
rule checks if there are frequent transactions by one or more users from a particular device, exceeding a defined velocity. This can result in inaccurate results in cases where a single device is shared by many users. The
Device User Velocity
rule allows a device to be used by
n
distinct users in any configured duration. If the device is used by more than
n
distinct users in the configured duration, then it indicates fraudulent activity.
It is based on the following parameters:
  • Number of Distinct Users Allowed Per Device
    Denotes the number of distinct users performing transactions using a specified device, irrespective of whether the risk evaluation resulted in success or failure.
    The default value for this parameter is
    5
    .
  • Time Interval
    Denotes the time period in which the number of transactions are tracked.
    The default value for this parameter is
    60
    .
  • Unit for Time Interval
    Denotes the unit in which the time period is measured.
    The default value for this parameter is
    Minutes
    .
For example, consider a configuration of 5 transactions per device in 60 minutes. This rule is not triggered when User1 performs five transactions per hour from Device1. But if there are transactions from five different users using Device1 in one hour, then this rule is triggered.
 
Configuring Device User Velocity Rule
To configure the Device User Velocity rule:
  1. Ensure that you are logged in as a GA or an OA.
  2. Activate the
    Organizations
    tab.
  3. Click the
    Search
    button on the page to display the list of organizations.
  4. Under
    Select Organizations to Modify
    , click the link with the organization’s name for which you want to delete the rule.
  5. Click the
    Risk Engine
    tab.
  6. Under the
    Rules Management
    section on the side-bar menu, click the
    Rules and Scoring Management
    link.
    The Rules and Scoring Management page appears.
  7. From the
    Select the Ruleset
    list, select the ruleset for which this configuration is applicable.
    The configuration information for the specified ruleset appears.
  8. Click
    Add a New Rule
    .
    The Risk Analytics Rule Builder page appears.
  9. Enter the
    Name
    ,
    Mnemonic
    , and
    Description
    of the rule that you want to create.
  10. Select the
    Channels
    and
    Actions
    for which this rule is applicable.
  11. Build the rule fragment, as follows:
    1. From the
      Device Elements
      list, select
      DEVICEID
      .
    2. Select
      VELOCITY_DISTINCT_USER
      from the
      Select Operator
      list.
    3. Specify the number of distinct users performing transactions from the device in the
      Greater Than or Equal To
      field.
    4. Specify the time interval.
      This value denotes the maximum number of transactions (within the specified time interval) that is considered safe for a device for
      n-1
      distinct users. If the actual number of transactions within the specified time is equal to or greater than this number, then RA tracks the transaction as a risk, which results in the matching of the Device User Velocity rule.
    5. Select the unit for the time interval from the drop-down list.
    6. Click
      Add
      to build the rule fragment.
  12. Click
    Create
    at the bottom of the Rule Builder page to create the rule.
    The changes are not yet active and are not available to your end users.
  13. To make the changes active, you must migrate them to production.
    Refer to How to Activate a Rule (Migrate Rules to Production) for instructions to do so.
  14. Refresh
    all
    deployed Transaction Server instances.
    See How to Refresh Server Cache for instructions on how to do this.
How to Configur
e Organizations for Device Velocity
Rules with Scope
as Org Family
To create Device Velocity rules for organizations with Scope as Org Family, you must enable constraints by running the following database scripts:
INSERT INTO ARRFCONFIGURATION (SEQUENCEID,ORGNAME,CHANNELID,CATEGORY,NAME,VALUE,DESCRIPTION,DISPLAYNAME,TYPE,SHOWINUI,DISPLAYORDERID) VALUES (ARRFCONFIGSEQUENCE.NEXTVAL,'<ORGNAME>',-1,'GLOBAL','LOGDEVICEPINGS','Y','Log Device TimeStamps','Log Device TimeStamps',0,0,0);
Example
INSERT INTO ARRFCONFIGURATION (SEQUENCEID,ORGNAME,CHANNELID,CATEGORY,NAME,VALUE,DESCRIPTION,DISPLAYNAME,TYPE,SHOWINUI,DISPLAYORDERID) VALUES(ARRFCONFIGSEQUENCE.NEXTVAL, 'FAMILYORG1',-1,'GLOBAL','LOGDEVICEPINGS','Y','Log Device TimeStamps','Log Device TimeStamps',0,0,0); INSERT INTO ARRFCONFIGURATION (SEQUENCEID,ORGNAME,CHANNELID,CATEGORY,NAME,VALUE,DESCRIPTION,DISPLAYNAME,TYPE,SHOWINUI,DISPLAYORDERID) VALUES(ARRFCONFIGSEQUENCE.NEXTVAL, 'FAMILYORG2',-1,'GLOBAL','LOGDEVICEPINGS','Y','Log Device TimeStamps','Log Device TimeStamps',0,0,0); COMMIT;
After adding these database entries, organizations can create Device Velocity rules with Scope as Org Family.
How to Configure the Out-of-Box Device User Maturity Rule
The
User Associated with DeviceID
rule evaluates transactions by checking the association between the user and the device, irrespective of the time the association was created. If the user-device association exists, then the transactions receive a low risk score. There might be cases where fraudsters can reset a user's password and associate themselves with the device. In such cases, evaluating the transaction based only on the User-Device association might not be sufficient to rule out fraudulent activity.
The
Device User Maturity
rule enables setting a level of trust in the device. For example, a User-Device association that has existed for a month, assuming that there has been no fraudulent activity identified for that user or device, should be more trusted than a User-Device association that has been established recently.
It is based on the following parameters:
  • Number of Successful Transactions per User-Device Association
    Denotes the number of successful transactions identified by RA for a specified User-Device association.
  • First Successful Transaction
    Denotes the time (in days) before which the first successful transaction was identified.
These parameters determine the strength of the User-Device association. The Device User Maturity rule returns True if the user has used the device for at least the specified number of days and the number of successful transactions is greater than or equal to the configured value.
 
Configuring Device User Maturity Rule
To configure the Device User Maturity rule:
  1. Ensure that you are logged in as a GA or an OA.
  2. Activate the
    Organizations
    tab.
  3. Click the
    Search
    button on the page to display the list of organizations.
  4. Under
    Select Organizations to Modify
    , click the link with the organization’s name for which you want to delete the rule.
  5. Click the
    Risk Engine
    tab.
  6. Under the
    Rules Management
    section on the side-bar menu, click the
    Rules and Scoring Management
    link.
    The Rules and Scoring Management page appears.
  7. From the
    Select the Ruleset
    list, select the ruleset for which this configuration is applicable.
    The configuration information for the specified ruleset appears.
  8. Click
    Add a New Rule
    .
    The Risk Analytics Rule Builder page appears.
  9. Enter the
    Name
    ,
    Mnemonic
    , and
    Description
    of the rule that you want to create.
  10. Select the
    Channels
    and
    Actions
    for which this rule is applicable.
  11. Build the rule fragment, as follows:
    1. From the
      Transaction Elements
      list, select
      USERNAME
      .
    2. Hold the
      CTRL
      key, and select
      DEVICEID
      from the
      Device Elements
      list.
    3. Select
      MATURITY
      from the
      Select Operator
      list.
    4. Specify the number of successful transactions.
    5. Specify the number of days before which the first successful transaction took place.
    6. Click
      Add
      to build the rule fragment.
  12. Click
    Create
    at the bottom of the Rule Builder page to create the rule.
    The changes are not yet active and are not available to your end users.
  13. To make the changes active, you must migrate them to production.
    Refer to How to Activate a Rule (Migrate Rules to Production) for instructions to do so.
  14. Refresh
    all
    deployed Transaction Server instances.
    See How to Refresh Server Cache for instructions on how to do this.
I Have Configured My Rule, Now What
After you configure an out-of-the-box rule, you need to do the following tasks so that the rule is used during risk evaluation:
  1. Upload any data, if the rule uses a list.
  2. Enable the rule.
  3. Assign the ruleset (to which the rule belongs) to an organization.
  4. Migrate it to production.
  5. Refresh the server cache.
The following topics quickly explain these tasks.
 
Step 1: Upload Rule List Data, If Any
If your rule uses a list of values against which it assesses a condition, then you need to upload that data as a list.
To upload the data for a list, see, How to Upload Rule List Data for detailed instructions.
 
Step 2: Enable the Rule
The rule that you just configured must be enabled so that it can be a part of the parent ruleset. To enable the rule:
  1. In the Administration Console, access the Rules and Scoring Management page.
  2. From the
    Select a Ruleset
    list, select the ruleset for which this configuration is applicable.
    The configuration for the specified ruleset appears.
  3. Select the
    Enable
    option against the rule you just created.
  4. Click
    Save
    at the bottom of the rules table.
 
Step 3: Assign the Ruleset to Which the Rule Belongs
After you activated the new rule by enabling it (as discussed in the preceding section), then the next thing you will need to do is activate the parent ruleset to which your rule belongs. This process of activating a ruleset is known as assigning a ruleset.
To assign a ruleset, see, How to Assign a Ruleset to an Organization for detailed instructions.
 
Step 4: Migrate the Rule to Production
When the rule is configured, it is still in the Proposed Configuration area and is only still available in the
Proposed
column of rule configuration. When the rule is ready and all its data is configured according to your requirements, then you must convert it from its current the Proposed state to Active state (the
Active
column on respective configuration page). This can only be done by migrating it to production.
To make the changes active, see How to Activate a Rule (Migrate Rules to Production) for detailed instructions.
 
Step 5: Refresh the Server Cache
Migrating a major change (such as a new rule) to production does not affect the cache of the active server instances. Each instance's cache needs to be refreshed before the server can start serving it for risk evaluations. That is why, you now need to refresh the server cache.
To refresh the cache of all deployed Transaction Server instances, see How to Refresh Server Cache for detailed instructions.
How to Upload Rule List Data
All the configurations and tasks discussed in this section should primarily be performed by Organization Administrators. If required, these steps can also be performed by Global Administrators. However, they must be performed at the organization level (through the
Organizations
tab).
If any rule that you deployed requires additional data in the form of a list, then you must perform the tasks in this section. You can add, modify, or delete list data by using the Manage List Data and Category Mappings page in Administration Console. This topic describes how to manage data for the following lists:
  • Negative Country Lists
  • Untrusted IP Lists
  • Trusted IP Lists
  • Trusted Aggregator Lists
  • Data Lists
  • Category Mapping Lists
For Negative Country List
Negative Country list
comprises all countries from which fraudulent or malicious transactions are known to have originated in the past. Enterprises may also maintain this list in line with the regulations of their country.
RA derives the country information based on the input IP address. It, then, uses this data to score the potential for fraud for online transactions originating from such countries. For this purpose, RA also integrates with Neustar IP Intelligence (formerly, Quova), which enhances the analysis by providing detailed geographic information for each IP address by mapping it to a region.
To know more about Neustar IP Intelligence and their services, go to:
RA evaluates the incoming transactions and checks if these transactions originated from an IP address that belongs to a country marked as negative. Such transactions are typically denied.
Use the Manage List Data and Category Mappings page to add a country to the Negative Country list or remove a country from the list.
 
Configuring Negative Country List
To configure the Negative Country list:
  1. Ensure that you are logged in as a GA.
  2. Activate the
    Organizations
    tab.
  3. Under
    Manage Organizations
    , click the
    Search Organization
    link.
  4. Click the
    Search
    button on the Search Organization page to display the list of organizations.
  5. Under
    Select Organizations to Modify
    , click the link with the organization’s name to which you want to apply the rule.
  6. Click the
    Risk Engine
    tab.
  7. Under the
    Rules Management
    section on the side-bar menu, click the
    Manage List Data and Category Mappings
    link.
    The Manage List Data and Category Mappings page is displayed.
  8. From the
    Select Existing Ruleset
    list, select the ruleset that for which this configuration is applicable.
  9. Select the
    Manage List Data
    option.
  10. From the
    Select List Type
    list, select
    Negative Country Lists
    .
  11. From the
    Select List
    drop-down list, select the list identifier
    that you specified while creating the corresponding list.
  12. Select Negative Countries
    that you want to add to the list.
  13. Click the > or < button to move selected countries to the desired list.
    You can also click
    the
    >>
    or
    <<
    buttons to move all countries to the desired lists.
  14. Click
    Save
    to save the changes.
    The changes are not yet active and are not available to your end users.
  15. To make the changes active, you must migrate them to production.
    Refer to How to Activate a Rule (Migrate Rules to Production) for instructions to do so.
  16. Refresh
    all
    deployed Transaction Server instances.
    See How to Refresh Server Cache for instructions on how to do this.
For Untrusted IP Addresses
The
Untrusted IP Address List
is a collection of IP addresses that have been the origin of known anonymizer proxies or fraudulent and malicious transactions in the past. This list is the source of the Negative category discussed in the "Configuring Untrusted IP Types" section.
Use the Manage List Data and Category Mappings page to configure the untrusted IP address ranges for your organization.
Configuring Untrusted IP Addresses
To configure the untrusted IP address ranges:
  1. Ensure that you are logged in as a GA.
  2. Activate the
    Organizations
    tab.
  3. Under
    Manage Organizations
    , click the
    Search Organization
    link.
  4. Click the
    Search
    button on the Search Organization page to display the list of organizations.
  5. Under
    Select Organizations to Modify
    , click the link with the organization’s name to which you want to apply the rule.
  6. Click the
    Risk Engine
    tab.
  7. Under the
    Rules Management
    section on the side-bar menu, click the
    Manage List Data and Category Mappings
    link.
    The Manage List Data and Category Mappings page is displayed.
  8. From the
    Select Existing Ruleset
    list, select the ruleset that for which this configuration is applicable.
    The ruleset configuration information is displayed.
  9. Select the
    Manage List Data
    option.
  10. From the
    Select List Type
    list, select
    Untrusted IP Lists
    .
  11. From the
    Select List
    drop-down list, select the list identifier
    that you specified while creating the corresponding list.
  12. In the
    Upload Untrusted IP Ranges
    section, select the appropriate mode for writing data:
    • Append
      : This option appends the data that you are uploading to a list or dataset.
      You must select this option if the list does not exist.
    • Replace
      : This option overwrites the existing data in the specified list or dataset.
  13. Click
    Browse
    to navigate to the data file that contains the list of entries.
  14. Click
    Upload
    to complete the task.
  15. In the
    Add/Delete Untrusted IP Range
    section
    :
    1. Enter the starting IP address in the
      IP Address
      field.
    2. Select one of the following options:
      • Subnet Mask:
        If you want to specify a range of IP addresses based on the subnet mask to be added to the Untrusted IP Address List.
      • End IP Address:
        If you want to specify a simple range of IP addresses to be added to the Untrusted IP Address List.
    3. Specify the
      Information Source
      (or vendor) of the untrusted IP address range.
  16. Click one of the following buttons, as required:
    • Add Range:
      To add the specified IP address or range to the database.
    • Delete Range:
      To delete the specified IP address or range from the database.
    The appropriate message is displayed.
    The changes are not yet active and are not available to your end users.
  17. To make the changes active, you must migrate them to production.
    Refer to How to Activate a Rule (Migrate Rules to Production) for instructions to do so.
  18. Refresh
    all
    deployed Transaction Server instances.
    See How to Refresh Server Cache for instructions on how to do this.
For Trusted IP Addresses
In RA, transactions that either originate from or are routed through IP addresses and ranges that belong to the
Trusted IP Address List
are considered low risk. As a result, RA bypasses these transactions from risk evaluations and assigns them a low Score and the ALLOW Advice.
Use the Manage List Data and Category Mappings page to perform the following tasks related to trusted IP addresses and ranges:
  • Adding a Trusted IP Address Range
  • Updating a Trusted IP Address Range
  • Deleting a Trusted IP Address Range
 
Adding a Trusted IP Address Range
To add a Trusted IP Address Range:
  1. Ensure that you are logged in as a GA.
  2. Activate the
    Organizations
    tab.
  3. Under
    Manage Organizations
    , click the
    Search Organization
    link.
  4. Click the
    Search
    button on the Search Organization page to display the list of organizations.
  5. Under
    Select Organizations to Modify
    , click the link with the organization’s name to which you want to apply the rule.
  6. Click the
    Risk Engine
    tab.
  7. Under the
    Rules Management
    section on the side-bar menu, click the
    Manage List Data and Category Mappings
    link.
    The Manage List Data and Category Mappings page is displayed.
  8. From the
    Select Existing Ruleset
    list, select the ruleset that for which this configuration is applicable.
    The ruleset configuration information is displayed.
  9. Select the
    Manage List Data
    option.
  10. From the
    Select List Type
    list, select
    Trusted IP Lists
    .
  11. From the
    Select List
    drop-down list, select the list identifier
    that you specified while creating the corresponding list.
  12. Specify the required
    IP Address
    that will be added to the Trusted IP List.
  13. Specify one of the following:
    • Subnet Mask:
      If you want to specify a range of IP addresses based on the subnet mask to be added to the Trusted IP List.
    • End IP Address:
      If you want to specify a simple range of IP addresses to be added to the Trusted IP List.
  14. Click
    Add Range
    to add the IP addresses or ranges to the Trusted IP List.
    The Trusted IP List table with the range that you just added appears at the end of the page.
  15. Click
    Update
    to save the changes.
    The changes are not yet active and are not available to your end users.
  16. To make the changes active, you must migrate them to production.
    Refer to How to Activate a Rule (Migrate Rules to Production) for instructions to do so.
  17. Refresh
    all
    deployed Transaction Server instances.
    See How to Refresh Server Cache for instructions on how to do this.
 
Updating a Trusted IP Address Range
To update a Trusted IP Address Range:
  1. Perform the tasks listed from Step 1 through Step 11 in "Adding a Trusted IP Address Range" to display the
    Trusted IP List
    table.
  2. Make the required changes in the
    Trusted IP List
    table.
  3. Select all the affected IP address range(s) in the
    Trusted IP List
    table.
  4. Click
    Update
    to update the changes that you made.
    The changes are not yet active and are not available to your end users.
  5. To make the changes active, you must migrate them to production.
    Refer to How to Activate a Rule (Migrate Rules to Production) for instructions to do so.
  6. Refresh
    all
    deployed Transaction Server instances.
    See How to Refresh Server Cache for instructions on how to do this.
 
Deleting a Trusted IP Address Range
To delete a Trusted IP Address Range:
  1. Perform the tasks listed from Step 1 through Step 11in "Adding a Trusted IP Address Range" to display the
    Trusted IP List
    table.
  2. In the
    Trusted IP List t
    able, select the required IP address range(s) that you want to delete.
  3. Click
    Delete
    to delete the ranges that you selected.
  4. To make the changes active, you must migrate them to production.
    Refer to How to Activate a Rule (Migrate Rules to Production) for instructions to do so.
  5. Refresh
    all
    deployed Transaction Server instances.
    See How to Refresh Server Cache for instructions on how to do this.
For Trusted Aggregators
Aggregators
are third-party vendors who provide account aggregation services by collating login information of users across multiple enterprises. The originating IP addresses when users log in from a protected portal versus when they come in through such aggregators are different. Many enterprises use the services of these account and data aggregation service providers to expand their online reach.
Transactions originating from (or routed through) aggregators "trusted" to the organization are considered low-risk. For this purpose, RA provides the ability to configure a list of these aggregators so that all transactions originating from the aggregators’ IP addresses are assigned a low Score, and the ALLOW Advice.
RA uniquely identifies an aggregator by combining their IP address range and a unique Aggregator ID. This Aggregator ID must also be sent to RA along with the transaction.
RA also enables you to specify up to
three
unique IDs for each aggregator at any time. This allows for the periodical rotation of the ID for the purpose of enhanced security. During this rotation, RA continues to recognize the previous ID in addition to the new ID to allow updates to the aggregator at a later time.
Use the Manage List Data and Category Mappings page to perform the following tasks related to trusted aggregators:
  • Adding a Trusted Aggregator
  • Updating a Trusted Aggregator
  • Deleting a Trusted Aggregator
 
Adding a Trusted Aggregator
To add a Trusted Aggregator:
  1. Ensure that you are logged in as a GA.
  2. Activate the
    Organizations
    tab.
  3. Under
    Manage Organizations
    , click the
    Search Organization
    link.
  4. Click the
    Search
    button on the Search Organization page to display the list of organizations.
  5. Under
    Select Organizations to Modify
    , click the link with the organization’s name to which you want to apply the rule.
  6. Click the
    Risk Engine
    tab.
  7. Under the
    Rules Management
    section on the side-bar menu, click the
    Manage List Data and Category Mappings
    link.
    The Manage List Data and Category Mappings page is displayed.
  8. From the
    Select Existing Ruleset
    list, select the ruleset that for which this configuration is applicable.
    The ruleset configuration information is displayed.
  9. Select the
    Manage List Data
    option.
  10. From the
    Select List Type
    list, select
    Trusted Aggregator Lists
    .
  11. From the
    Select List
    drop-down list, select the list identifier
    that you specified while creating the corresponding list.
  12. Specify the name of the new aggregator in the
    Add
    New Aggregator
    field and click
    Create.
    The updated Trusted Aggregator Configuration page.
  13. Select the
    Aggregator
    that you want to configure from the drop-down list.
  14. Enter the starting IP Address in the
    IP Address
    field.
  15. Select one of the following options:
    • Subnet Mask:
      If you want to specify a range of IP addresses based on the subnet mask to be added to the Trusted Aggregator List.
    • End IP Address:
      If you want to specify a simple range of IP addresses to be added to the Trusted Aggregator List.
  16. Click
    Add Range
    to add this IP address or range to the database.
    The Trusted IP List table with the range that you just added for the aggregator appears at the end of the page.
    The changes are not yet active and are not available to your end users.
  17. To make the changes active, you must migrate them to production.
    Refer to How to Activate a Rule (Migrate Rules to Production) for instructions to do so.
  18. Refresh
    all
    deployed Transaction Server instances.
    See How to Refresh Server Cache for instructions on how to do this.
Updating a Trusted Aggregator
RA enables you to update the Aggregator IDs. The periodic update of these IDs is referred to as
rotation of Aggregator IDs
.
You must periodically rotate or change the Aggregator IDs for security purposes. You can decide this rotation duration according to your business rules.
After an ID is updated, you must ensure that the latest Aggregator ID is conveyed to the aggregator. There might be a delay in propagating the Aggregator IDs. In this duration, RA recognizes the old, as well as the new Aggregator ID associated with the IP address.
The transactions originating from the aggregator-end must contain this aggregator ID in the form specified by RA APIs.
To update a Trusted Aggregator information:
  1. Complete Step 1 through Step 11 in "Adding a Trusted Aggregator" to display the Trusted Aggregator Configuration information.
  2. Select an existing aggregator from the
    Aggregator
    list.
    The Trusted Aggregator Configuration information with the Aggregator ID(s) for the selected aggregator appears.
  3. Click
    Update Aggregator ID
    to generate a new Aggregator ID.
    The updated Aggregator ID(s) for the aggregator appears, and the next empty Aggregator ID is displayed.
  4. In the
    Trusted IP List
    table, select the aggregator IP addresses or ranges you want to update.
  5. Make the required changes and click
    Update
    .
    The changes are not yet active and are not available to your end users.
  6. To make the changes active, you must migrate them to production.
    Refer to How to Activate a Rule (Migrate Rules to Production) for instructions to do so.
  7. Refresh
    all
    deployed Transaction Server instances.
    See How to Refresh Server Cache for instructions on how to do this.
 
Deleting a Trusted Aggregator
To delete a Trusted Aggregator:
  1. Complete Step 1 through Step 11 in "Adding a Trusted Aggregator" to display the Trusted Aggregator Configuration information.
  2. Select an existing aggregator from the
    Aggregator
    list.
    The Trusted Aggregator Configuration information appears.
  3. In the
    Trusted IP List
    table, select the aggregator IP addresses or ranges you want to delete.
  4. Click
    Delete
    to delete the selected information.
    The changes are not yet active and are not available to your end users.
  5. To make the changes active, you must migrate them to production.
    Refer to How to Activate a Rule (Migrate Rules to Production) for instructions to do so.
  6. Refresh
    all
    deployed Transaction Server instances.
    See How to Refresh Server Cache for instructions on how to do this.
For Simple Lists
If your list contains 10 or fewer items, you can use the
Show List
link in the Rule Builder to add the list items in the Rule Builder itself.
To upload the data for a rule that uses the IN_LIST operator:
  1. Ensure that you are logged in as a GA.
  2. Activate the
    Organizations
    tab.
  3. Under
    Manage Organizations
    , click the
    Search Organization
    link.
  4. Click the
    Search
    button on the Search Organization page to display the list of organizations.
  5. Under the
    Select Organizations to Modify
    section, click the link with the organization’s name to which you want to apply the rule.
  6. Click the
    Risk Engine
    tab.
  7. Under the
    Rules Management
    section on the side-bar menu, click the
    Manage List Data and Category Mappings
    link
    .
    The Manage List Data and Category Mappings page appears.
  8. From the
    Select Existing Ruleset
    list, select the ruleset for which this configuration is applicable.
  9. Select the
    Manage List Data
    option.
  10. From the
    Select List Type
    list, select
    Other Lists
    .
  11. From the
    Select List
    drop-down list, select the list identifier that you specified while creating the corresponding list.
    The updated page appears.
  12. In the
    Upload File Or Enter Data
    section, select the appropriate mode for writing data:
    • Append
      : This option appends the data that you are uploading to a list or dataset.
      You must select this option if the list does not exist.
    • Replace
      : This option overwrites the existing data in the specified list or dataset.
  13. Do
    one
    of the following:
    • Click
      Browse
      to navigate to the data file that contains the list of entries (separated by a newline character.)
    • Type in the entries in the
      Enter Data
      field, if a data file does not exist.
      Ensure that the entries are separated by a newline character (ENTER).
  14. Click
    Upload
    to complete the task.
For Category Mapping Lists
To upload the data for a rule that uses the IN_CATEGORY operator:
  1. Ensure that you are logged in as a GA.
  2. Activate the
    Organizations
    tab.
  3. Click the
    Search
    button on the page to display the list of organizations.
  4. Under the
    Select Organizations to Modify
    section, click the link with the organization’s name to which you want to apply the rule.
  5. Click the
    Risk Engine
    tab.
  6. Under the
    Rules Management
    section on the side-bar menu, click the
    Manage List Data and Category Mappings
    link
    .
    The Manage List Data and Category Mappings page appears.
  7. From the
    Select Existing Ruleset
    list, select the ruleset for which this configuration is applicable.
    The configuration information for the specified ruleset appears.
  8. Select the
    Manage Category Mappings
    option.
  9. From the
    Select Category Mapping
    list, select the mapping set identifier that you specified while creating the corresponding list.
    The updated page appears.
  10. In the
    Upload File Or Enter Classification Data
    section, select the appropriate mode for writing data:
    • Append
      : This option appends the data that you are uploading to a list or dataset.
      You must select this option if the list does not exist.
    • Replace
      : This option overwrites the existing data in the specified list or dataset.
  11. Perform
    one
    of the following:
    • Click
      Browse
      to navigate to the data file that contains the list of entries (separated by a newline character.)
    • Type in the entries in the
      Enter Data
      field, if a data file does not exist.
      Ensure that the entries are separated by a newline character (ENTER).
  12. Click
    Upload
    to complete the task.
How to Create a List
If any rule that you deployed requires additional data in the form of a list, then you can create a list by using the Create List page in the Administration Console.
To create a list for an organization:
  1. Log in to the Administration Console with the required privileges and scope.
  2. Activate the
    Organizations
    tab.
  3. Enter the complete or partial information of the organization you want to search and click
    Search
    .
    A list of organizations matching the search criteria appears.
  4. Under the
    Organization
    column, click the
    <ORGANIZATION_NAME>
    link for the required organization.
    The Organization Information page appears.
  5. Activate the
    Risk Engine
    tab.
  6. Under the
    Ruleset Management
    section, click the
    Create List
    link.
    The Create List page appears.
  7. Specify the
    List Name
    .
  8. Specify who can access the list using
    Scope
    :
    • ORG:
      Whether the list is only accessible to the current organization for which you are configuring the list.
    • Ruleset:
      Whether the list is accessible to all organizations that share a ruleset.
  9. Specify the data element that the list is based on in the
    Element Name
    field.
    These are data elements for the IN_LIST-based rules. For example, you will choose the BROWSER element if a browser or a specific version of the browser has been found vulnerable to recent attacks. Similarly, you can select the CITY element if you find that a specific city has been a hotbed for fraudulent online transactions.
  10. Specify the
    List Usage
    as follows:
    • General Purpose:
      To use for any data that is neither blacklisted nor whitelisted.
    • Blacklist:
      To ensure any matched data is instantly marked as fraud.
    • Whitelist:
      To ensure any matched data is instantly marked as safe.
  11. Specify whether you want to
    HotList
    the list you are creating.
    Currently the HotList option is only enabled for Blacklists.
    If you specify
    Yes
    , then this list is reflected in the
    Manage Inbound Calls
    and
    Work On Cases
    pages of Case Management.
  12. Specify if this is a
    Preferred List
    .
    This option is only available if you selected
    Blacklist
    in the
    List Usage
    option. Also, Preferred Lists can only be set for an organization.
    This option is useful if you want to set a hotlist as preferred and to be used by Customer Service Representatives (CSRs) for easy blacklisting from the Case Management screens.
  13. Specify what other organizations this list can be shared with and using what privileges (Read Only or Read-Write) from the
    Sharing & Privileges
    option.
    This release only supports the Read Only option.
    create_list
  14. Click
    Create
    to make the specified list active for the current organization.
  15. To make the changes active, you must migrate them to production.
    Refer to How to Migrate to Production for instructions to do so.
  16. Refresh
    all
    deployed Transaction Server instances.
    See How to Refresh Server Cache for instructions to do so.
How to Edit a List
To edit a list:
  1. Log in to the Administration Console with the required privileges and scope.
  2. Activate the
    Organizations
    tab.
  3. Enter the complete or partial information of the organization you want to search and click
    Search
    .
    A list of organizations matching the search criteria appears.
  4. Under the
    Organization
    column, click the
    <ORGANIZATION_NAME>
    link for the required organization.
    The Organization Information page appears.
  5. Activate the
    Risk Engine
    tab.
  6. Under the
    Ruleset Management
    section, click the
    Edit List
    link.
    The Edit List page appears.
  7. Select the list that you want to edit.
  8. Select if you want to make this list a preferred list or not.
    If you choose to make this list a Preferred List, then it can be used by Customer Service Representatives (CSRs) for easy blacklisting from the Case Management screens.
  9. Click
    Save
    .
How to Activate a Rule (Migrate Rules to Production)
When a rule, ruleset, or data is configured in RA, it is still in the Proposed Configuration area and is only still available in the
Proposed
column of rule configuration. When the rule is ready and all its data is configured according to your requirements, then you must convert it from its current the Proposed state to Active state (the
Active
column on respective configuration page). This can only be done by migrating it to production.
 
Notes on Migrating to Production
  • At any point in time, Transaction Servers work with Active data configurations
    only
    .
  • Active data is versioned to keep track of the changes made to the RA configuration data. Every time the Proposed data is migrated to production, unique data versions are created for the new set of Active configuration data.
 
Migrating a Rule to Production
To migrate a rule to production
  1. Ensure that you are logged in as a GA or an OA.
  2. Activate the
    Organizations
    tab.
  3. Click the
    Search
    button on the page to display the list of organizations.
  4. Under
    Select Organizations to Modify
    , click the link with the organization’s name for which you want to delete the rule.
  5. Click the
    Risk Engine
    tab.
  6. Under the
    Migrate to Production
    section on the side-bar menu, click the
    Migrate to Production
    link.
    The Migrate to Production page appears.
  7. On the page, either:
    • Select the
      Select All Rulesets
      option, if you want to migrate all the changes that you made to all the configured rulesets.
    • Select a specific ruleset from the
      Select Ruleset(s)
      list to migrate the changes that you made to this ruleset.
  8. Click
    Migrate
    .
    The page to confirm the action is displayed.
  9. On the confirmation page, click
    Confirm
    to start the
    migration process
    .
    Based on the volume of data that you are migrating to production, the migration process might take a few minutes.
    After the migration is completed, the "The proposed data has been successfully migrated to Production." message is displayed.
  10. Refresh the Transaction Server cache.
    Refer to How to Refresh Server Cache for instructions to do so.
How to Refresh Server Cache
If you have made any configuration changes, you must refresh the cache of the affected server instances for the changes to take effect. RA now provides an Integrated Cache Refresh feature that enables administrators to refresh the cache of all server instances from Administration Console.
The RA Servers cache can be refreshed in two ways:
 
Privileges Required
The MA can refresh the cache of all organizations. The GA and OA can refresh the cache of all organizations within their scope.
How to Refresh Server Cache at System Level
To refresh cache for all RA servers:
  1. Ensure that you are logged in as a GA or as an OA.
  2. Activate the
    Services and Server Configurations
    tab.
  3. Activate the
    Administration Console
    sub-tab.
  4. Under the
    System Configuration
    section on the side-bar menu, click the
    Refresh Cache
    link.
    The Refresh Cache page is displayed.
  5. Select one or both of the following options:
    • Select the
      Refresh System Configuration
      option to refresh the cache configuration of Administration Console, User Data Service, and all RiskFort Server and Case Management Server instances.
    • Select the
      Refresh Organization Configuration
      option to refresh the cache configuration of all organizations in your purview.
  6. Click
    OK
    .
    A confirmation dialog box appears.
  7. Click
    OK
    again.
How to Refresh Server Cache at Organization Level
Note:
Refreshing the cache of one organization does not affect the response time of transactions going on at that time for other organizations.
Organization configurations that do not refer to the global configuration, such as attribute encryption set, localization configuration, and email and telephone types are cached at the organization level. When you make changes to these configurations at the organization level, you must refresh the organization cache for the changes to take effect.
To refresh the organization cache:
  1. Ensure that you are logged in with the required privileges and scope to refresh the organization cache.
  2. Activate the
    Organizations
    tab.
  3. Under the
    Manage Organizations
    section, click the
    Search Organization
    link to display the Search Organization page.
  4. Enter the complete or partial information of the organization you want to search and click
    Search
    .
    A list of organizations matching the search criteria appears.
  5. Select the organizations whose cache you want to refresh.
  6. Click
    Refresh Cache
    .
  7. Click
    OK
    in the dialog box to confirm your cache refresh request.
    A message with a Request ID for the current cache refresh request is displayed. You can check the status of your cache refresh request by clicking the
    Check Cache Refresh Status
    link and selecting this
    Request ID
    .
Refreshing the cache of one organization does not affect the response time of transactions going on at that time for other organizations.
How to Edit Rule Definitions
The out-of-the-box rules in RA are generic and are configured for evaluating risk based on the rules that are applicable to all. If you need custom or industry-specific rules that are significantly different from those that RA provides out-of-the-box, then you need to deploy your own rules by using the
Rule Builder
, which is available through the Administration Console.
This topic describes how you can use the Rule Builder to make changes to the following rule definitions:
  • Untrusted IP Check
  • User Velocity Check
  • Device Velocity Check
  • Zone Hopping Check
  • Device MFP Match
Editing Untrusted IP Types
RA uses the IP address of the user’s computer as one of the input parameters to assess the risk of each transaction. RA evaluates the incoming transaction and checks if it originated from an IP address marked as
untrusted
. Such transactions are typically denied. The different categories of untrusted IP types are:
  • Negative
    IP addresses with this designation have been sources of fraudulent transactions in the past.
    Use this option, if you manually configured an IP addresses as negative, as discussed in "Configuring Untrusted IP Addresses".
  • Active
    IP addresses with this designation allegedly are anonymizing proxies that have been sources of fraudulent transactions and have been active in the last six months.
  • Suspect
    IP addresses with this designation allegedly are anonymizing proxies that have been active over the last two years, but not for the last six months.
  • Private
    IP addresses with this designation allegedly are anonymizing proxies that are not publicly accessible. These addresses typically belong to commercial ventures that sell anonymity services to the public.
  • Inactive
    IP addresses with this designation allegedly have been sources of fraudulent transactions, but have been found inactive in the last two years.
  • Unknown
    IP addresses with this designation allegedly are anonymizing proxies for which no positive results are currently available.
    The Active, Suspect, Private, Inactive, and Unknown negative type categories are derived from the Neustar IP Intelligence (formerly Quova) data.
To edit Untrusted IP Types:
  1. Ensure that you are logged in as a GA or an OA.
  2. Activate the
    Organizations
    tab.
  3. Click the
    Search
    button on the page to display the list of organizations.
  4. Under
    Select Organizations to Modify
    , click the link with the organization’s name for which you want to delete the rule.
  5. Click the
    Risk Engine
    tab.
  6. Under the
    Rules Management
    section on the side-bar menu, click the
    Rules and Scoring Management
    link.
    The Rules and Scoring Management page appears.
  7. From the
    Select the Ruleset
    list, select the ruleset for which this configuration is applicable.
    The configuration information for the specified ruleset appears.
  8. In the
    RULENAME
    column, click the
    Untrusted IP Check
    link.
    The Risk Analytics Rule Builder page appears.
  9. In the
    Negative IP Types Configuration
    section, select the applicable types of negative IP address categories, and click
    Update
    .
  10. Click
    Update
    at the bottom of the Rule Builder page to save the changes.
    The changes are not yet active and are not available to your end users.
  11. To make the changes active, you must migrate them to production.
    Refer to How to Activate a Rule (Migrate Rules to Production) for instructions to do so.
  12. Refresh
    all
    deployed Transaction Server instances.
    See How to Refresh Server Cache for instructions on how to do this.
Editing User Velocity
The
User Velocity Check
rule keeps a check on the number of transactions from a user within a specified period of time. It is based on the following parameters:
  • Number of Risk Evaluations per User
    Denotes the number of transactions (
    N
    ) performed by RA for a specified user, irrespective of the Advice or Risk Score.
    The default value for this parameter is
    5
    .
  • Time Interval
    Denotes the time period (
    T
    ) in which the number of transactions are tracked.
    The default value for this parameter is
    60
    .
  • Unit for Time Interval
    Denotes the unit in which the time period (
    T
    ) is measured.
    The default value for this parameter is
    Minutes
    .
The User Velocity Check rule uses the RA system time rather than the transaction time received as part of the incoming message when comparing the transaction history to determine whether the rule should be triggered or not. This allows for cross-channel rule configuration
 
To configure the User Velocity rule:
  1. Ensure that you are logged in as a GA or an OA.
  2. Activate the
    Organizations
    tab.
  3. Click the
    Search
    button on the page to display the list of organizations.
  4. Under
    Select Organizations to Modify
    , click the link with the organization’s name for which you want to delete the rule.
  5. Click the
    Risk Engine
    tab.
  6. Under the
    Rules Management
    section on the side-bar menu, click the
    Rules and Scoring Management
    link.
    The Rules and Scoring Management page appears.
  7. From the
    Select the Ruleset
    list, select the ruleset for which this configuration is applicable.
    The configuration information for the specified ruleset appears.
  8. In the
    RULENAME
    column, click the
    User Velocity Check
    link.
    The Risk Analytics Rule Builder page appears.
  9. Specify a value for the number of risk evaluations per user in the
    Greater than
    field.
  10. Specify the time interval.
    This value denotes the maximum number of transactions (within the specified time interval) that is considered safe for a user. If the actual number of transactions within the specified time exceeds this number, then RA will track it as a risk, which will result in the matching of the User Velocity rule.
  11. Select the unit for the time interval from the drop-down list.
  12. Click
    Update
    to build the rule fragment.
  13. Click
    Update
    at the bottom of the Rule Builder page to save the changes.
    The changes are not yet active and are not available to your end users.
  14. To make the changes active, you must migrate them to production.
    Refer to How to Activate a Rule (Migrate Rules to Production) for instructions to do so.
  15. Refresh
    all
    deployed Transaction Server instances.
    See How to Refresh Server Cache for instructions on how to do this.
Editing Device Velocity
The
Device Velocity Check
rule keeps a check on the number of transactions from a device within a specified period of time. It is based on the following parameters:
  • Number of Risk Evaluations per Device
    Denotes the number of transaction (
    M
    ) performed by RA for a specified device, irrespective of whether the risk evaluation resulted in success or failure.
    The default value for this parameter is
    10
    .
  • Time Interval
    Denotes the time period (
    T
    ) in which the number of transactions are tracked.
    The default value for this parameter is
    60
    .
  • Unit for Time Interval
    Denotes the unit in which the time period (
    T
    ) is measured.
    The default value for this parameter is
    Minutes
    .
Editing Device Velocity Rule
To edit the configuration of the Device Velocity rule:
  1. Ensure that you are logged in as a GA or an OA.
  2. Activate the
    Organizations
    tab.
  3. Click the
    Search
    button on the page to display the list of organizations.
  4. Under
    Select Organizations to Modify
    , click the link with the organization’s name for which you want to delete the rule.
  5. Click the
    Risk Engine
    tab.
  6. Under the
    Rules Management
    section on the side-bar menu, click the
    Rules and Scoring Management
    link.
    The Rules and Scoring Management page appears.
  7. From the
    Select the Ruleset
    list, select the ruleset for which this configuration is applicable.
    The configuration information for the specified ruleset appears.
  8. In the
    RULENAME
    column, click the
    Device Velocity Check
    link.
    The Risk Analytics Rule Builder page appears.
  9. Specify the number of risk evaluations per device in the
    Greater than
    field.
  10. Specify the time interval.
    This value denotes the maximum number of transactions (within the specified time interval) that is considered safe for a device. If the actual number of transactions within the specified time exceeds this number, then RA tracks the transaction as a risk, which results in the matching of the Device Velocity rule.
  11. Select the unit for the time interval from the drop-down list.
  12. Click
    Update
    to build the rule fragment.
  13. Click
    Update
    at the bottom of the Rule Builder page to save the changes.
    The changes are not yet active and are not available to your end users.
  14. To make the changes active, you must migrate them to production.
    Refer to How to Activate a Rule (Migrate Rules to Production) for instructions to do so.
  15. Refresh
    all
    deployed Transaction Server instances.
    See How to Refresh Server Cache for instructions on how to do this.
Editing Zone Hopping
Zone hopping
tracks successive transactions from the same user that occur at distant locations (separated by large distances) at a speed beyond what is reasonably possible within a short time span. For example, if Bob logs in from New York at 9 AM (GMT) and again from London at 10 AM (GMT), then the Zone Hopping Check rule will track the latter transaction as risky.
Parameters Used by the Rule
The Zone Hopping Check rule is based on the following parameters:
  • Maximum Speed at which a User can Travel
    Denotes the maximum speed (
    S
    , in miles per hour) at which a user can physically travel using conventional transport, such as airplanes, cars, and trains.
    If the speed at which a user appears to have moved (in the time frame between two successive transactions) exceeds this pre-configured threshold speed (S), then RA considers it as a case of zone hopping.
    By default this value is 500 miles, but you can configure it by setting the value of the
    Maximum Speed at which a User can Travel
    field in the RA Rule Builder page.
  • Maximum Number of Users Sharing the Same User ID
    Sometimes, multiple users (for example, husband and wife) can use the same user name because they might be located in different zones. In such cases, RA must not consider this as a case of Zone hopping. For example, if husband logs in from New York at 10 AM (GMT) and wife from London at 11 AM (GMT), then RA will not mark these transactions as risky.
    By default this value is 1, but you can configure it to 2 by editing the
    Maximum Number of Users Sharing the Same Username
    field in the RA Rule Builder page.
  • Maximum Distance Tolerance for IP Address Locations
    Because of variation in location of the IP address provided by ISPs, a user's physical location (geographic latitude and longitude) cannot be determined to a high level of precision by using their public IP address. To address this, RA uses an uncertainty offset (
    U
    , in miles) to accommodate the variation in the physical location of the IP address from which the transaction originated.
    By default this variation is about 50 miles, but you can configure it by setting the value of
    Maximum Distance Tolerance for IP Address Location
    field in the Risk Analytics Rule Builder page.
The Zone Hopping Check rule uses the RA system time rather than the transaction time received as part of the incoming message when comparing the transaction history to determine whether the rule should be triggered or not. This allows for cross-channel rule configuration.
 
To edit the definition of the Zone Hopping rule in a ruleset:
  1. Ensure that you are logged in as a GA or an OA.
  2. Activate the
    Organizations
    tab.
  3. Click the
    Search
    button on the page to display the list of organizations.
  4. Under
    Select Organizations to Modify
    , click the link with the organization’s name for which you want to delete the rule.
  5. Click the
    Risk Engine
    tab.
  6. Under the
    Rules Management
    section on the side-bar menu, click the
    Rules and Scoring Management
    link.
    The Rules and Scoring Management page appears.
  7. From the
    Select the Ruleset
    list, select the ruleset for which this configuration is applicable.
    The configuration information for the specified ruleset appears.
  8. In the
    RULENAME
    column, click the
    Zone Hopping Check
    link.
    The Risk Analytics Rule Builder page appears.
  9. Specify a value for the
    Maximum Speed at Which the User Can Travel
    parameter.
  10. Specify a value for the
    Maximum Number of Users Sharing the Same User ID
    parameter.
  11. Specify a value for the
    Maximum Distance Tolerance for IP Address Location
    parameter.
  12. Click
    Update
    .
  13. Click
    Update
    at the bottom of the Rule Builder page to save the changes.
    The changes are not yet active and are not available to your end users.
  14. To make the changes active, you must migrate them to production.
    Refer to How to Activate a Rule (Migrate Rules to Production) for instructions to do so.
  15. Refresh
    all
    deployed Transaction Server instances.
    See How to Refresh Server Cache for instructions on how to do this.
Editing Machine FingerPrint (MFP) Match Percentage
The
Device MFP Match
rule checks if the match percentage between the input device signature and the corresponding stored device signature is greater than or equal to a specified Signature Pass Threshold.
To configure the MFP Match Percentage rule:
  1. Ensure that you are logged in as a GA or an OA.
  2. Activate the
    Organizations
    tab.
  3. Click the
    Search
    button on the page to display the list of organizations.
  4. Under
    Select Organizations to Modify
    , click the link with the organization’s name for which you want to delete the rule.
  5. Click the
    Risk Engine
    tab.
  6. Under the
    Rules Management
    section on the side-bar menu, click the
    Rules and Scoring Management
    link.
    The Rules and Scoring Management page appears.
  7. From the
    Select the Ruleset
    list, select the ruleset for which this configuration is applicable.
    The configuration information for the specified ruleset appears.
  8. In the
    RULENAME
    column, click the
    Device MFP Match
    link.
    The Risk Analytics Rule Builder page appears.
  9. Enter a value for the
    Signature Match Threshold
    and
    Reverse Lookup Threshold
    , and click
    Update
    .
  10. Click
    Update
    at the bottom of the Rule Builder page to save the changes.
    The changes are not yet active and are not available to your end users.
  11. To make the changes active, you must migrate them to production.
    Refer to How to Activate a Rule (Migrate Rules to Production) for instructions to do so.
  12. Refresh
    all
    deployed Transaction Server instances.
    See How to Refresh Server Cache for instructions on how to do this.
How to Delete a Rule
You can delete only the new rules that you have created and deployed. You cannot delete the out-of-the-box rules shipped with RA. Also, it is strongly recommended that you do not delete a rule that is still being used by another organization. That is why this task must be done at organization level.
To delete a rule:
  1. Ensure that you are logged in as a GA or an OA.
  2. Activate the
    Organizations
    tab.
  3. Click the
    Search
    button on the page to display the list of organizations.
  4. Under
    Select Organizations to Modify
    , click the link with the organization’s name for which you want to delete the rule.
  5. Click the
    Risk Engine
    tab.
  6. Under the
    Rules Management
    section on the side-bar menu, click the
    Rules and Scoring Management
    link.
    The Rules and Scoring Management page appears.
  7. From the
    Select the Ruleset
    list, select the ruleset for which this configuration is applicable.
    The Rules and Scoring Management page appears.
  8. Expand the rule that you want to delete by clicking the [+] sign.
  9. Click
    Delete this Rule
    .
    You get a message.
  10. Click
    OK
    to complete the task.
    You get the confirmation message.
  11. Click
    OK
    .
    The changes are not yet active and are not available to your end users.
  12. To make the changes active, you must migrate them to production.
    Refer to How to Activate a Rule (Migrate Rules to Production for instructions to do so.
  13. Refresh all deployed Transaction Server instances.
    Refer to How to Refresh Server Cache for instructions to do so.