Understanding the Types of Operators Used by the Rule Builder

To build a new rule by using the RA Rule Bulder, you need Data Elements (see ) and different types of Operators. This article quickly lists the different types of Operators that you can use to build your custom rules. It also briefly touches on the different types of Data Elements with which these operators are used.
cara
To build a new rule by using the RA Rule Bulder, you need
Data Elements
(see Quick Overview of Data Elements) and different types of
Operators
. This article quickly lists the different types of Operators that you can use to build your custom rules. It also briefly touches on the different types of Data Elements with which these operators are used.
For detailed information on Data Elements that can be used in each channel and the the operators that are allowed with them, see Understanding Data Elements.
Based on their usage, operators in RA can be divided in the following categories:
Generic Operators
Operators that you will use to manipulate these Data Elements to create rules can be grouped into the following major categories:
  • Expression Operators
    These operators are used to combine rule fragments to build a rule. Possible operators include:
    • AND
    • OR
    • NOT
  • Match Type Operators
    These operators specify what type of match will be performed for the
    IN_CATEGORY
    and
    IN_LIST
    operators. Possible operators include:
    • EXACT
      If the list value matches the input value exactly, then the rule is triggered. This match is case-sensitive.
    • PARTIAL
      If any of the values in the list is a partial substring of the input value, then the rule is triggered. This match is case-sensitive.
    For example, a list with values 40001, 50001, and 60001 triggers the rule for PARTIAL match with an input value of 40001000100010001. Similarly, a list with values Alice, Cathy, and Karen trigger the rule for PARTIAL match with an input value of "Karenina" and for EXACT match with an input value of "Karen".
  • LookUp Type Operators
    These operators match specified values in a list. Possible operators include:
    • IN_LIST
    • IN_TRUSTED_LIST
    • IN_NEGATIVE_LIST
  • Relational Operators
    These operators are used for numeric comparison of data elements.
    Possible operators include:
    • RANGE,
    • EQUAL_TO (=)
    • NOT_EQUAL_TO (!=)
    • GREATER_OR_EQUAL (>=)
    • LESS_OR_EQUAL (<=)
    • GREATER_THAN (>)
    • LESS_THAN (<)
Operators Specific to ATM and POS Channels
These operators include:
  • EQUAL_TO_CB
  • NOT_EQUAL_TO_CB
  • GREATER_OR_EQUAL_CB
  • LESS_OR_EQUAL_CB
  • GREATER_THAN_CB
  • LESS_THAN_CB
In the preceding list,
CB
indicates
Card BIN
.
History-Based Operators
Transaction History
is defined as the list of transactions for the same account (
Card Number
or
PAN
) over ATM and POS channels in reverse chronological sequence. Operators that leverage this Transaction History are referred to as
History-Based Operators
.
The available transaction history is restricted to the maximum history duration (
Duration to Look Back
), set at the global level.
Restrictions While Using History-Based Operators
Note the following restrictions when you use history-based operators:
  • History-based rule fragments can be combined with other rule fragments using AND and OR operators, along with the NOT operator. However, the use of parenthesis is
    not
    permitted.
  • History-based rules can be used as Saved Rules to create other rules.
  • History-based rule fragments
    cannot
    be combined with Saved Rules.
  • Multiple history-based rule fragments
    cannot
    be combined into a single rule.
  • History-based rule fragments
    cannot
    be combined with operators that maintain their own private history. These operators include ZONE_HOP, VELOCITY (USERNAME), and VELOCITY (ACTION).
The following table describes the history-based operators supported by the current release of RA.
Operator
Description
CUMULATIVE_AMOUNT
Fetches the transaction history and provides a cumulative total of the amount (in the organization’s base currency) for transactions within the specified Duration to Look Back restricted to Maximum Transactions to Look Back. The rule is triggered if the calculated cumulative amount is greater than the configured Threshold Cumulative Amount.
The fields that you can configure for the CUMULATIVE_ACCOUNT operator are:
  • Threshold Cumulative Amount: Threshold amount (in the organization's base currency) that would trigger the rule. If you set this value to -1, it would be ignored.
  • Threshold Transaction Count: The number of transactions, exceeding which the rule will be triggered.
  • Duration to Look Back: Maximum time period (in minutes) to consider for transaction history.
  • Maximum Transactions to Look Back: Maximum number of transactions to consider for transaction history.
  • Transactions to Consider: The type of transactions that you want to consider. Possible values are All, Approved, or Denied.
  • Additional Filter: An optional custom history filter allows for additional filtering of the history data with the specified filter. The filter options available are: Reversed Transactions (REVERSAL_STATUS EQ 1), Issuer Approved Transactions (TXN_ACTION_CODE EQ 00), and Issuer Declined Transactions (TXN_ACTION_CODE NEQ 00). This additional history filter is not applicable to the current transaction and is applied to the history data fetched based on the normal history criteria prior to the actual data tabulation for rule triggering.
For an example of how this operator works, see “Transactions Exceeding Thresholds” in Examples of Using New Rules.
GROUPED_CUMULATIVE_AMOUNT
Fetches the transaction history and provides a cumulative total of the amount (in the organization's base currency), for the transactions whose transaction time is within the specified time frame (Time Frame Start Time and Time Frame End Time), grouped in time units of the specified duration (Amount Grouping Duration) and within the specified Duration to Look Back restricted to Maximum Transactions to Look Back. The rule is triggered if the calculated amount is greater than the configured Threshold Cumulative Amount for at least the configured Minimum Threshold Breach Count.
The fields that you can configure for the GROUPED_CUMULATIVE_ACCOUNT operator are:
  • Threshold Cumulative Amount: Threshold amount (in the organization's base currency) that would trigger the rule. If you set this value to -1, it would be ignored.
  • Grouping Period Count: The number of periods to group to perform the amount totaling.
  • Minimum Threshold Breach Count: Number of grouping periods when the amount total exceeds the configured Threshold Cumulative Amount for triggering the rule. This threshold must not be greater than Grouping Period Count.
  • Duration to Look Back: Maximum time period (in minutes) to consider for transaction history.
  • Maximum Transactions to Look Back: Maximum number of transactions to consider for transaction history.
  • Time Frame Start Time (HHMM): Start time of the day for the grouping period.
  • Time Frame End Time (HHMM): End time of the day for the grouping period.
  • Transactions to Consider: The type of transactions that you want to consider. Possible values are All, Approved, or Denied.
  • Additional Filter: An optional custom history filter allows for additional filtering of the history data with the specified filter. The filter options available are: Reversed Transactions (REVERSAL_STATUS EQ 1), Issuer Approved Transactions (TXN_ACTION_CODE EQ 00), and Issuer Declined Transactions (TXN_ACTION_CODE NEQ 00). This additional history filter is not applicable to the current transaction and is applied to the history data fetched based on the normal history criteria prior to the actual data tabulation for rule triggering.
For an example of how this operator works, see “Daily Maximum Amount Check” in Examples of Using New Rules.
 ACTION_CUMULATIVE_AMOUNT
Fetches the transaction history after the last occurrence of the specified action and provides a cumulative total of the amount (in the organization’s base currency) for transactions within the specified Duration to Look Back restricted to Maximum Transactions to Look Back. The rule is triggered if the calculated cumulative amount is greater than the configured Threshold Cumulative Amount or the number of transactions is greater than the Threshold Transaction Count. However, if the specified action did not occur within the duration, history is deemed to be zero.
The fields that you can configure for the ACTION_CUMULATIVE_ACCOUNT operator are:
  • Threshold Cumulative Amount: Threshold amount (in the organization's base currency) that would trigger the rule. If you set this value to -1, it would be ignored.
  • Threshold Transaction Count: The number of transactions, exceeding which the rule will be triggered. If you set this value to -1, it would be ignored
  • Duration to Look Back: Maximum time period (in minutes) to consider for transaction history.
  • Maximum Transactions to Look Back: Maximum number of transactions to consider for transaction history.
  • Transactions to consider: The type of transactions that you want to consider. Possible values are All, Approved, or Denied.
  • Threshold Action: The action, after the last occurrence of which the transaction history is fetched. Possible values are PINCHANGE and FINANCIALINQUIRY.
  • Additional Filter: An optional custom history filter allows for additional filtering of the history data with the specified filter. The filter options available are: Reversed Transactions (REVERSAL_STATUS EQ 1), Issuer Approved Transactions (TXN_ACTION_CODE EQ 00), and Issuer Declined Transactions (TXN_ACTION_CODE NEQ 00). This additional history filter is not applicable to the current transaction and is applied to the history data fetched based on the normal history criteria prior to the actual data tabulation for rule triggering.
For an example of how this operator works, see "Transactions Exceeding Thresholds for a Specified Action" in Examples of Using New Rules.