User manual

Rules

5min

The Rules Page in the Transaction Monitoring System is a critical feature that allows users to create, view, manage, and modify the rules used to evaluate transactions. These rules define the conditions under which transactions are flagged as suspicious, enabling the system to monitor compliance and detect potential fraud or other risks. Each rule is customizable, allowing organizations to adapt the system to their specific regulatory and operational requirements.



Rules Page
Rules Page

  1. List of Rules:
    • The Rules Page displays a complete list of all active and inactive rules within the system. Each rule in the list includes key details such as:
      • Rule ID: A unique identifier for the rule.
      • Rule Name: A descriptive name for the rule.
      • Risk Level: The default risk level (Low, Medium, High, Critical) associated with the rule.
      • Priority: The urgency level of the rule, indicating how important it is for flagged cases to be addressed.
      • Status: Indicates whether the rule is active or inactive.
      • Assigned User/Team: Displays who is responsible for managing cases triggered by this rule, if many users are assigned to a rule then user is taken in a Round Robin fashion.
  2. Creating New Rules: Users with the appropriate permissions can create new rules based on the organization’s specific monitoring needs. The rule creation process can be done in two ways: Basic or Advanced.
    • Basic Rule Creation:
      • In the basic mode, users can easily define rules through a form-based interface. This method simplifies the rule creation process by allowing users to:
        • Select Data Source: Choose whether the rule should be applied to historic data, uploaded data sources, or both.
        • Field, Operator, and Value Selection: Users select a field (e.g., amount, currency, transaction type), choose an operator (e.g., greater than, equals), and specify a value to evaluate the transaction data.
        • This approach is user-friendly and helps teams quickly create straightforward rules without complex logic.
      • Basic Rule Creation
        Basic Rule Creation
        
    • Advanced Rule Creation:
      • In advanced mode, users can define rules using SQL-like syntax, offering more flexibility for complex scenarios. This allows users to create highly specific rules by directly evaluating transaction data fields using conditions such as:
        • Example: SELECT transaction.amount >= 3*avg(amount), 3*avg(amount) > 100000 FROM transaction_table WHERE customer_id = transaction.customer_id AND txn_id != transaction.txn_id AND type IN ('inr_deposit','vda_deposit', 'inr_withdrawal') AND amount > 0 AND date_time >= toDateTime(transaction.date_time) - INTERVAL 60 DAY
      • Advanced rules give users the ability to tailor the system's monitoring to fit specific use cases, with more control over how data is filtered and flagged.
      • Advance Rule Creation
        Advance Rule Creation
        
    • Risk Level Assignment: For each rule, users can assign a risk level (Low, Medium, High, Critical) to help prioritize cases triggered by that rule.
    • Priority: Assign a priority level to determine how urgently cases triggered by the rule need to be handled.
    • Rule Explanation: Users can provide a description to explain the purpose of the rule and the behavior it monitors.
    • In most cases, the Transaction Monitoring (TM) Team creates the rules based on detailed rule descriptions provided by the organization’s teams. This process is designed to make it easier for clients by translating their monitoring needs into effective rules within the system.
  3. Rule Conditions and Logic:
    • Each rule is built using logical conditions that define which transactions should be flagged. These conditions are highly flexible and allow for a wide range of configurations, such as:
      • Transaction Amount: Flagging transactions that exceed a certain threshold (e.g., amount > 10,000).
      • Transaction Type: Monitoring specific types of transactions, such as credit card purchases, international transfers, or refunds.
      • Customer Behavior: Identifying suspicious patterns based on customer activity (e.g., multiple high-value transactions in a short period).
      • Geographical Limits: Detecting transactions from high-risk regions or countries (e.g., country = 'XYZ').
  4. Rule Modification:
    • Rules can be easily modified as business requirements or compliance regulations change. Users can update the rule conditions, change the assigned risk level, adjust priorities, or deactivate the rule entirely if it’s no longer relevant.
      • Deactivate or Activate Rules: Inactive rules are not applied to transaction monitoring, allowing users to temporarily disable rules without deleting them.
      • Modify Rule Logic: Users can adjust rule logic like in basic they can can field names, operators and values and for advance rules they can chage the static variables in the SQL as needed, ensuring that monitoring rules remain accurate and relevant.

Rule Approval Process

Every rule that is created requires system approval to ensure that it aligns with the description provided by the client and meets the system's requirements. This approval process ensures that:

  1. The rule is correctly defined according to the organization's monitoring needs.
  2. The rule syntax and conditions are valid and executable within the system.
  3. The rule does not conflict with other existing rules or cause system inefficiencies.

Once the system approval is granted, the rule is activated and can begin monitoring transactions as intended. This step guarantees the integrity and effectiveness of the rules created by clients.

Data Uploads for Rule Dependencies

In the Settings Page, the system allows users to upload external data sources that can be used as dependencies for specific rules. For example, if certain rules require additional data like a list of blacklisted IPs, these can be uploaded through the Data Uploads feature. This functionality enhances the flexibility of the rules engine by enabling dynamic rule evaluation based on external data sets.

  • Blacklisted IPs: A list of IP addresses known to be associated with fraudulent activities or other security risks. Rules can be configured to flag transactions originating from these IPs.
  • Sanctioned Entities: Lists of individuals, businesses, or organizations that are under sanctions or restrictions.
  • High-Risk Countries: Country lists that represent high-risk jurisdictions, useful for monitoring transactions coming from or going to these regions.
  1. Navigate to the Settings Page.
  2. Go to the Data Uploads section.
  3. Select the type of data (e.g., IP blacklist, sanctioned entities, etc.).
  4. Upload the data file (e.g., CSV) containing the relevant information.
  5. Once uploaded, the data becomes accessible for rule evaluation across the platform.

These data sources can then be referenced in rules to automatically flag transactions that match the uploaded data (e.g., transactions from blacklisted IPs). This ensures that the system can easily adapt to external risks by allowing users to update or modify these lists as needed.

Transaction Response Categories for Rules

After sending a transaction, the system's response for each rule will fall into one of the following three categories:

  1. RULE_VIOLATED:
    • Indicates that the transaction has violated that rule. The response will specify which rules were triggered based on the transaction data.
  2. RULE_COMPILED:
    • Indicates that the transaction has been successfully processed, and no rules were violated.
  3. RULE_EVALUATION_FAILED:
    • Indicates that there was an error in the rule, such as syntax error , preventing the system from evaluating the transaction.

These categories provide essential feedback to ensure proper transaction handling and compliance.

Updated 16 Oct 2024
Doc contributor
Did this page help you?