1. Background

The rule system allows users to define automated checks and processes within the case management system. These rules can be applied for various purposes, including:

• Know Your Customer (KYC) Verification / Cross-checking: Ensuring compliance with Simplified Due Diligence (SDD), Customer Due Diligence (CDD), or Enhanced Due Diligence (EDD) requirements.

• Ongoing Due Diligence (ODD): Periodic review of customer risk profiles.

• Risk Scoring: Evaluating an entity’s risk based on submitted KYC data.

• Transaction Monitoring: Detecting anomalies in financial activities through behavior deviation analysis.

• Fraud Prevention: Implementing rule-based detection mechanisms to identify suspicious activities.

2. Request-Based Rules Configuration

Request-based rules are triggered based on specific requests, such as KYC submissions or transactions. When a rule is created, it follows certain parameters:

2.1 Rule Parameters

Rules can have specific or generic parameters. The key parameters include:

• process: Only requests matching the process type will activate the rule.

• groups: Determines applicable user groups. Can specify groups to add or remove upon rule activation.

• informationRefreshDays: Defines the frequency (in days) for refreshing rule-related information.

• ruleRecommendation: Specifies action options – Block, Review, or Proceed.

• triggerAtNoInputData: A Boolean flag (TRUE/FALSE) controlling rule execution when input data is missing.

• createPing: If TRUE, additional parameters are activated:

  • autoConfirm: Automatically confirms the rule-triggered action (TRUE/FALSE).

  • overrideRecDays: Specifies an override time period (in days).

  • ruleScore: Probability percentage (0-100%) determining risk level.

  • riskDecreaseTimeline: A function that models the probability decline over time.

These rules check for required data fields and decide their behavior based on triggerAtNoInputData.

2.1.1 Rule Identifiers

Each rule in the system is tracked with two identifiers to ensure auditability and traceability:

• Rule ID: The identifier for a specific version of a rule. Each time a rule is modified and saved, a new Rule ID is created, tied back to the same Origination Rule ID.

  • This allows the system to show exactly which version of a rule was active when a case, alert, or decision was generated.

  • Rule IDs enable full auditability and compliance reporting, making it clear when changes occurred and what their operational impact was.

• Origination Rule ID: The permanent identifier of a rule’s lineage. It remains constant throughout the lifecycle of a rule, even as it is edited or updated. This ID ensures traceability and provides a stable anchor for audit history.

  • All versions of a rule share the same Origination Rule ID, allowing investigators and auditors to connect alerts or cases back to the original control concept.

  • A new Origination Rule ID is only assigned when a user chooses to re-create the rule in the configuration — for example, when its intent, purpose, or risk treatment changes so significantly that it must be considered a new rule.

2.2 Transaction Monitoring Rules and Filtering by Transaction Type

Transaction monitoring rules can be filtered based on the types of transactions created within the system. This allows users to tailor rule execution based on specific transaction categories, enhancing fraud detection and risk management.

Users can filter transaction monitoring rules based on:

• Active transaction types: Only apply rules to currently active transaction types.

By utilizing transaction type filtering, users can fine-tune monitoring rules to focus on relevant financial activities and improve detection accuracy.

2.3 Threshold Configuration in Monitoring Rules

When configuring rules that rely on thresholds (such as an Amount threshold rule), you can choose between two threshold modes:

• Global threshold – A single threshold value that applies equally to all entities. This ensures consistent evaluation across your entire dataset.

• Risk-based threshold – Threshold values that adjust based on the entity’s assigned risk score. This allows you to apply stricter limits for high-risk entities and more flexible limits for low-risk entities, aligning the monitoring logic with your risk management strategy.

When to use each approach:

• • Use a global threshold when you want simple, uniform monitoring that does not depend on entity-specific characteristics.

  • Use a risk-based threshold when you want monitoring tailored to entity risk profiles, ensuring higher sensitivity for higher-risk entities while reducing unnecessary alerts for lower-risk entities.

3. Ongoing-Based Rules Configuration

Ongoing rules operate continuously, monitoring entities for potential risks without being triggered by specific requests. They are crucial for ongoing due diligence (ODD) and risk management.

3.1 Key Functions of Ongoing Rules

• Automated Monitoring: The system periodically scans entities for risk changes such as change sanctions, PEP-status. 

• Ping Creation: Alerts users if a rule detects a change or risk increase.

3.2 Rule Parameters

Ongoing rules use similar parameters as request-based rules, ensuring consistency across the system. Rule IDs and Origination Rule IDs also apply to ongoing rules, providing the same traceability and audit trail across both real-time and continuous monitoring.

4. Summary

The rules system empowers users by allowing them to configure and define logic-driven monitoring tailored to their specific needs. Instead of relying on fixed, pre-set conditions, users can create dynamic rule sets that determine how cases, transactions, and risk assessments are handled. Request-based rules enable users to define responses based on real-time input data, while ongoing rules provide continuous monitoring, ensuring proactive risk mitigation. By configuring these rules, users take control of compliance processes, fraud detection, and transaction monitoring, adapting them to their operational and regulatory requirements.