Create custom rules
Create unlimited custom rules using your own data sources.
Sumsub's highly flexible rule builder allows teams to design complex, custom rules to meet virtually any specific regulatory or internal requirement. This capability ensures complete control over compliance logic and risk management workflows, providing tailored solutions without limitations.
The core function of the rule builder lets you precisely define the logic of a custom rule. The definition relies on two complementary components: conditions and actions.
Conditions are the criteria that must be met for a rule to be triggered. They evaluate specific data attributes - such as transaction amount, country of origin, or applicant age.
You can define conditions in two ways:
- Visual editor — A simple, no-code way to build logic using standard operators and connectors like AND and OR.
- SumScript — An advanced mode for creating complex, highly customized logic that goes beyond standard templates.
Actions define the automated response that will be executed if your rule conditions are met. Depending on your needs, you can:
- Manage risk — automatically adjust risk scores or reject suspicious activities.
- Handle investigations — put transactions on hold or create dedicated cases for manual review.
- Update profiles — change applicant statuses, add notes, or manage tags.
Get started with custom rules
To get started, navigate to the Installed rules page in the Dashboard and click the Create rule button in the top menu. This will open the rule configuration interface where you can build your logic from scratch.
Step 1: Select rule type
First, determine when your rule will be evaluated:
- Check and evaluate transactions — Use this for real-time monitoring where the rule triggers every time a new transaction occurs.
- Trigger a scheduled event — Use this for periodic checks to identify patterns that emerge over time rather than during a single transaction. For more information on how to set up periodic verification, see this article.
Step 2: Define conditions
Specify the criteria that will trigger the rule. The available options depend on your selected rule type.
To ensure precise detection, minimize false positives, and make sure the rule aligns with your expectations, verify that your conditions include the following key elements:
- Target scope — specify what is being monitored (for instance, Individual customers or high-risk segments).
- Activity — specify which actions are analyzed (for instance, outgoing cross-border transfers or crypto purchases).
- Metric and threshold — specify the limits (for instance, amount > 5,000 or MCC IN high risk list).
If you are building a rule based on historical activity, you must also specify:
- Timeframe — the lookback period, such as last 24 hours or current calendar month.
- Calculation logic — specify how we should process the data (for instance, sum of amounts or count of unique remitters).
Transaction rules
You define a single Conditions block to evaluate the transaction. For that, you can use SumScript — high-performance scripting method for complex and granular logic. For more details on syntax and functions, see this article.
You can use AI Generation to transform your natural language requirements into ready-to-use SumScript conditions. To get accurate results, your request must be expressed as a precise, testable condition. Avoid subjective wording that lacks measurable value and transform vague requirements into concrete triggers.
In the following table, you can find examples of such wording.
| Subjective terms | Objective terms |
|---|---|
| Payments slightly less than threshold. | Trigger if a transaction amount in default currency is between 9,500 and 9,999. |
| Many transactions to the same person. | Trigger if more than 5 outgoing transactions to the same beneficiary occur within a rolling 24-hour period. |
| Unusual increase in volume. | Daily transaction volume exceeds 200% of the customer's 30-day historical average. |
ImportantWhile AI generation significantly speeds up the process, it is a supportive tool, not a final authority. Always review the generated condition to ensure it aligns perfectly with your specific compliance requirements and internal logic. The AI might interpret nuances differently, so a manual check is mandatory before using rules.
If you are already familiar with SumScript syntax and functions, you can use Manual configuration to type your specific conditions directly into the editor for full control.
Alternatively, you can use no-code condition — simple, dropdown-based builder with pre-defined fields for standard monitoring. This is an older engine with lower performance compared to SumScript. It is available for basic conditions, but for optimal efficiency and advanced logic we recommend using SumScript.
TipUse the built-in validation tools to verify your conditions and catch errors early:
- Validate your logic. After you write or generate a condition (manually or with AI), click Validate. The system checks the syntax in real time.
- Review diagnostics. If the editor finds an issue, it highlights the exact location and shows a detailed error message with suggested fixes.
- Fix with AI. For complex errors, you can use the Fix with AI button. The feature analyzes the condition and the error message, then suggests a corrected script to resolve the issue.
Scheduled event rules
Scheduled rules utilize specific triggers and filters to define exactly when and for whom an event should be triggered.
- Event timer — define when the rule is triggered. You can use the default Time since a level was completed condition to trigger the event a specific number of days after an applicant is approved at a chosen level. Alternatively, you can create a custom condition to define your own timing logic.
- Activation scope (optional) — limit the rule to applicants who met the trigger condition after a specific date.
- Applicant filter (optional) — add a secondary layer of SumScript logic to target specific sub-groups.
Step 3: Implement variables for dynamic logic
Define variables in your SumScript rules to control thresholds, time windows, and flags from the UI without editing the underlying code. This approach increases the flexibility of the rule logic and enables team members to adjust rule parameters in real time without modifying the condition itself.
To set up a variable:
- Specify its name and data type.
- [Optional] Add a description.
- [Optional] Set a default value.
- Reference the variable in your conditions.
Supported Variable Types:
- Standard Values. Use String for text (like currency codes), Int or Float for numeric thresholds, and Boolean for simple on/off logical flags.
- Geographical data. Country supports single Alpha-3 country codes, while Country List allows you to group multiple regions for easier filtering.
- Time and collections. Duration allows you to define time windows for aggregations, and String List allows you to manage sets of text values, such as allowed or restricted categories.
Step 4: Configure rule actions
Define the automated response that triggers once your rule conditions are met. While the primary rule action is mandatory, you can supplement it with additional automated tasks to further streamline your operations.
Rule action
Every rule must define a core response that determines the immediate system outcome when conditions are met. This action provides the primary categorization needed for real-time monitoring, such as assigning a risk score or applying specific transaction tags.
You must select a status to define the next step for the transaction:
- Only score — updates the risk score without changing the transaction's current state.
- Put on hold — suspends the transaction for further review or internal investigation.
- Awaiting user — flags the transaction as requiring additional input or documentation from the applicant.
- Reject — automatically rejects the transaction based on the rule match.
Additional automated actions
You can further automate your compliance process by adding one or more of the following:
- Create case — automate case creation by selecting a blueprint to define the investigation flow and choosing how flagged transactions should be grouped.
- Choose Rule and applicant if you want a separate case created for each rule triggered for an applicant.
- Select Applicant if you prefer all alerts regarding the rules triggered for a specific applicant to be combined into a single case.
- Review applicant — automatically update an applicant verification status or risk categorization. You can change their verification level, move them to manual review, or trigger a re-check or final rejection.
- Modify applicant tags — automatically add or remove specific tags from an applicant profile based on the rule outcome.
- Add note — attach a note to an applicant profile for future reference.
Step 5: Define rule details
Complete your rule setup by defining its operational behavior and metadata in the Configurations panel on the right.
Technical settings
Refine how the system processes the rule during transaction monitoring:
- Monitor transactions with type. Select the specific category of transactions this rule applies to, for instance finance.
- Set up the priority of rule. Assign a numerical priority to determine the order of rule execution.
- Enable the Stop on match toggle to prevent the system from processing subsequent rules once this specific rule is triggered.
- In the Transactions from sources field, choose whether the rule should evaluate all transactions or only trigger for those with a specific source key.
Rule details
Set the identifying information for your rule:
- Title and description — use the Fill in with AI tool to automatically generate an appropriate name and explanation based on your rule configuration, then manually refine the content if needed.
- Bundle — assign the rule to a specific bundle to group related logic and simplify organizational management.
Step 6: Test configuration
Once you configure all of the settings above, use the testing tool to verify how your rule performs against your existing data.
- Click Run test to see a preview of transactions that would have triggered this rule.
- Analyze the list of matching transactions and their associated data to ensure the logic works as intended.
- In case no matches are found, you can manually create a transaction to test your specific conditions.
Updated 9 days ago