Rule Configuration Guide: Best Practices for High Performance

SEON's scoring engine offers flexibility, allowing customers to create and refine fraud prevention rules in real-time to address evolving fraud patterns. This powerful customization capability supports complex and dynamic use cases across various industries.

To help you maximize this flexibility, this guide provides best practices for crafting high-performance rules. These recommendations ensure that your configurations operate with maximum efficiency, enabling faster decision-making and maintaining seamless system responsiveness at scale.

By following these optimization tips, you can confidently build rules that meet your fraud prevention goals and uphold the speed and scalability for which SEON’s platform is recognized. Our engineering team continually refines the platform and introduces improvements to further boost performance and reliability across all use cases.

Why it matters:

Velocity rules analyze groups of past transactions. To enhance processing speed, the "WHERE" clause should enable the system to narrow down which transactions to check. The more specific the field, the faster the engine can complete the calculation.

Using broad or generic fields (referred to as low-cardinality fields) can make rules less selective and may obscure useful fraud signals.

Recommendations:

Include at least one of these high-cardinality fields in the "WHERE" conditions of velocity rules:

• User ID
• Device hash, True device ID
• IP address
• Browser hash
• Shipping address hash
• Cookie hash
• Card hash
• Phone number
• Billing address hash
• Email address
• User full name

Why it matters:

Using equality-based operators (such as “equals to” or “is listed on”) on high-cardinality fields helps the engine find results quickly. These fields contain numerous unique values, so the rule does not need to scan unnecessary data.

Recommendations:

• Use “equals to” or “is listed on” operators on high-cardinality fields in "WHERE" clauses.
• Avoid operators that are not optimized for this use case (e.g., contains, or range-based conditions).

Why it matters:

Some fields may seem detailed but are frequently reused, for example, the same device hash across different users. These "common" values can slow processing or reduce rule accuracy.

Examples of common data points:

• Device hash
• Shared promo codes (as custom fields)
• Common email domains (e.g., gmail.com)
• BIN number, User country (for region-specific operations)
• Default or empty values

Recommendations:

1. Add rule logic that handles these common values separately in compare or data match type rule parameters.
2. Create and use custom lists for common values (e.g., "Multiple Use Promotion Codes") and reference them in compare parameters for clarity and performance.
3. Combine velocity rule parameters with another high-cardinality field to narrow down the dataset.
4. Where possible, use more selective fields, such as True device ID instead of Device hash.

Why it matters:

Rules that consistently match or never match do not enhance fraud detection and may slow the system. They also consume resources without contributing to meaningful outcomes.

Recommendations:

Use the Applied Rule Statistics widget to review the frequency of each rule being triggered. If a rule is always true or false, it may need to be updated or removed.

Why it matters:

Rules that check the "last N" transactions must identify a certain number of past events. If your filters are overly specific, the engine may scan extensive data to find sufficient matches, negatively impacting performance.

Recommendations:

1. Use parameters that retain sufficient transaction volume to keep the "last N" condition within a short timeframe, ideally within days rather than months.
2. If feasible within the business logic, consider using selective fields to reduce the number of transactions eligible for evaluation.
3. Where appropriate, consider replacing "in the last N transactions" rules with time window-based rules (e.g., "transactions from the past 3 days"). Time-bounded rules mitigate this issue by limiting the evaluation to a fixed interval.

Why it matters:

Test rules may employ broad filters or incomplete logic, and if run in real-time, they can impact production performance.

Recommendations:

1. Run test rules as alert triggers (as these are asynchronous) when possible.
2. Regularly remove test rules that are no longer in use.

Why it matters:

Custom fields can exhibit varying behavior depending on their storage or indexing in the database. Consequently, rules using them might be slower or produce unexpected results.

Recommendations:

1. For high-performance scenarios, please contact our team for assistance in optimizing custom fields in Velocity parameters.
2. Use SEON’s built-in fields whenever possible, as they are optimized for speed and reliability.

Why it matters:

Applying similarity filter conditions in Velocity parameters to a large number of transactions can significantly decrease performance, as the similarity algorithm must evaluate more potential matches. To maintain efficiency, it is crucial to narrow the dataset as much as possible using other filters before applying the similarity filter. Available similarity conditions:

• Previous Email address similarity
• Previous User address hash similarity
• Previous Username similarity
• Previous User full name similarity
• Previous device similarity

Recommendations:

1. Use other conditions or parameters to limit the number of transactions before the similarity check is run.
2. Use shorter timeframes to further reduce the number of transactions considered.

Why it matters:

Velocity parameters can be configured to "count current transaction" along with previous transactions in the aggregation. If this is not essential, excluding it can improve speed.

Recommendations:

If the rule logic does not depend on the current transaction, exclude it for enhanced performance.

Why it matters:

Shorter timeframes result in faster rule evaluation. Long time spans (such as a month or more) increase the amount of data to be checked, slowing down the process.

Recommendations:

1. If long timeframes are required, always include high-cardinality fields to filter the data more efficiently.
2. Try to reduce the frequency of rule triggering by adding conditions (e.g., compare or data match sentences) before the main rule logic.