Rules

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 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 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 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 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 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') 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 the rule is correctly defined according to the organization's monitoring needs the rule syntax and conditions are valid and executable within the system 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 navigate to the settings page go to the data uploads section select the type of data (e g , ip blacklist, sanctioned entities, etc ) upload the data file (e g , csv) containing the relevant information 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 rule violated indicates that the transaction has violated that rule the response will specify which rules were triggered based on the transaction data rule compiled indicates that the transaction has been successfully processed, and no rules were violated 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