Custom rules and parameters

Updated on 27.11.23
10 minutes to read
Copy link

Overview

Custom rules are how you can hone SEON to your risk appetite and counter fraud specific to your business. From simpler data match and compare rules to complex velocity and regular aggregate velocity rules, use custom rules to unlock the full power of SEON.

 

Creating rules – The rules editor

You can quickly and easily create new custom rules from the Scoring Engine page. Open the Custom rules tab and click Create new rule to get started.

Rule creation is divided into three widgets: Rule Settings, Rule Parameters, and Test rule on existing data.

Rule Settings widget

Set your rule's basic characteristics: give it a name, select its action and add it to a Rule category or set its expiration date if needed.

Use the toggles at the top of the widget to turn your rule on or off. Use the expiration date toggle to automatically turn your rule off on a certain calendar date. This is great for rules connected to time-sensitive promotions or events.

You can also batch turn on/turn off, copy or change the category of custom rules directly under from the Custom Rules if you select multiple rules and use the actions in the toolbar at the bottom.

Rule parameters widget

This is where the magic happens. Build the logic your rule will follow to analyze transactions. The widget will change slightly depending on which parameter type you've selected for your rule but will always follow the same logic.

Select your rule parameter on the left side of the widget, or choose a rule template from the dropdown list on the right. SEON preconfigured rule templates to help you build rules quickly and efficiently. You can mix and match rule templates within the same rule.

Name the data field you want to check in the Value column. The dropdown menu will always display items relevant to the parameter type you've selected. The data field dropdown will only display data fields that work with the selected parameter. If you can't find the field you're looking for, try changing your parameter type.

The Operator column houses a dropdown menu with logical operators (e.g., is equal to, is larger than, includes, exists). SEON will filter the list of operators for you and only display those that work with your selected data field.

Enter the field or value to which you want the rule to compare value in the Compare to column. Options will change based on the parameter type you're using. For compare rules you'll check against given fixed value. Compare two data points of the same transaction using data match rules. You can use velocity rules to compare countred, summarised or aggregate data and set up the aggregate in this column.

Test rule on existing data widget

If the rule you're creating is a Data Match or Compare rule that modifies transaction states, then you can test it using the widget at the bottom of the screen. This lets you see the effect the rule would have had if running in the past day, week, month, or year.

The widget uses a confusion matrix to showcase the performance of rules. Read our detailed explanation below.

 

Custom Rule Parameters

In SEON, rule parameters are the smallest units of each rule. A rule is built of a single or several rule parameter. You can also combine several rule parameters into rule parameter groups. You can use three different types of parameters in your custom rules:

Custom rule parameters
  • Compare: Compare a data field to a predetermined value using your selected logic operator. For example, IP Country is UK, Transaction Amount > 100 EUR, or Browser Hash is XYZ.
  • Data match: Compare two values in the same transaction. For example, check for IP and card country mismatches.
  • Velocity: Compare historical values of a data field with a defined value within a specified timeframe. For example, the number of customers with the same IP address in the last day.

Using the three parameters, you can stop simple tricksters and uncover large-scale fraud rings at the same time. You can tailor SEON to your business needs and the most common risk scenarios with them.
 

 

Data match rules

Use data match rules to compare two data points in the same transaction. This can help you spot suspicious mismatches in the data of a transaction.

Let's look at a few examples:

  • The country the bank card used to pay for an order does not match the country given in the shipping or billing address.
    Card country is not equal to billing country OR Card country is not equal to shipping country.
  • If your site tracks user balances, you can monitor how much of their balance a user is trying to use at a time. Say a bet that costs over 80% of the user's balance is suspicious.
    80% of User balance is less or equal to Transaction amount.
  • When a user's full name does not match the name given on the card you may be facing stolen card details or a case of friendly or family fraud.
    User full name is not equal to Cardowner full name.
Data FieldOperatorsCompare to

The data point of the incoming transaction you'd like to analyze.

You can add percentage modifiers to value-based data points (e.g., 50% of the transaction amount) 

= (is equal to)
(is not equal to)


Use the case sensitivity toggle to make matching text values case-sensitive or not.
 

The connected data point to which you are comparing the original data field.

 

Compare rules

Use compare rule parameters to compare a data point to a specific value, to check whether it exists, or to examine how similar it is to another piece of text (string).

Let's look at a few examples:

  • Sometimes you want to track high-value deals more closely. A compare rule can  trigger on orders over a certain threshold in value. 
    Transaction amount is greater than 1500.
  • Fraudsters often use throwaway or fake phone numbers when placing orders. With SEON, you can flag transactions that contain suspicious phone numbers.
    Phone number valid is equal to false OR Phone disposable is equal to true.
  • We know it's not economical for fraudsters to create email accounts with realistic backgrounds. That's why emails with few associated digital profiles are suspicious.
    Online profiles count (Email) is less than 2.
     

Data Field

Operators

Value

The data point of the incoming transaction you'd like to analyze.

The specific operators displayed will depend on the data field you select. See the list of all possible operators below:

= (is equal to)
(is not equal to)
> (greater than)
(greater or equal to)
< (less than)
(less or equal to)
exists
(does not exist)
contains
does not contain
Is either
Is neither
is in range
is not in range
starts_with
ends_with
is listed on
is not listed on


Use the case sensitivity toggle to make the comparison of text values case-sensitive or not.

The value to which you are comparing the original data field.


The type of input the field accepts will change based on the data field and operators selected (e.g., a true-false dropdown, text only, numbers only).

 

Velocity rules

Use velocity rules to compare a data field with a value, percentage or another field over (or within) a certain time frame or several repeating timeframes. Velocity rules will let you monitor for suspicious user behavior, strange patterns, and changes in usual buying habits. Velocity rules can also check the number, average, sum, maximum, and minimum values of chosen fields in a given time period.

Velocity rule parameters can be combined with IF conditions, called Where blocks, to create more precise rules. By adding Where block to a rule, you can limit which transactions will be taken into account when SEON calculates if the rule should be triggered or not.

Let's take a look at a few examples:

  • Sudden spikes in user activity can often be suspicious. Using velocity rules you can monitor for quick changes in user buying patterns. For example, a customer has closed over 10 transactions in the last 30 minutes.
    Number of transactions in the last 30 minutes in current and previous transactions where User ID is equal to current value is greater than 10.
  • A similar rule could compare the user's current behavior to their past behavior patterns. For example, a rule that spots orders which are much higher in value than a users usual transactions. 
    150% of the Average of Transaction amount in the last 1 week in current and previous transactions where User ID is equal to current value is less than Current Transaction amount 
  • Large amounts spent from prepaid cards can also be suspicious in certain cases. Velocity rules can help you here as well. 
    Sum of Transaction amount in the last 1 week in previous transactions where User ID is equal to current value AND Card type is equal to PREPAID is greater or equal to 2000.

 

Value column

Select the aggregate you want to use for your rule from the dropdown at the top of the Value column. Velocity rules can count the number of occurrences or values or calculate the average, sum, minimum and maximum values.

  • Regular aggregate: Calculate aggregates from regularly repeating time intervals (e.g., hours/days/weeks/months). The rule above that calculates the average transaction amount for a user from the last week is an example of a regular aggregate.
  • Where: Filter which transactions you want the rule to consider when calculating aggregates. For example, adding the statement "UserID is equal to current value" will limit aggregate calculations to transactions completed by the current user.
  • Count current transaction: The toggle sets whether SEON should include the values of the current transaction in the aggregates it calculates.
  • Time frame: Simple time frames use "in the last" X seconds, hours, days, weeks, months logic. Click the Advanced toggle to specify the beginning and end of a timeframe manually.

 

Operator and Compare to column

Use the drop-down in the Operator column to select how you would like to compare the values on either side of the rule. Velocity rules support the following operators: 

  • = (is equal to)
  • (is not equal to)
  • > (is greater than)
  • (is greater or equal to)
  • < (is less than)
  • (is less or equal to)

Chose the value you'd like the rule to compare the aggregate to in the Compare to column. Select from the following options in the dropdown: 

  • Fix value – Input the exact numerical data you'd like to compare the aggregate data to.
  • Current value – Select the data filed of the current transaction you'd like to compare the aggregate to.
  • Second time frame – The rule will calculate the same aggregate for a different time frame and compare the results.

Modify score by velocity value: Increase the score the rule adds to a transaction based on the difference between the aggregate and the "Compare to" value. Larger differences will thus result in higher fraud scores.

 

Velocity rule types

Velocity rules can be divided into categories based on the aggregation they perform.

AVG Velocity Rules

AVG Velocity Rules compare the average of values in the specified field within a timeframe. These can be compared to either a present incoming field, a percentage of the same field in the current transaction, or a specific value. 

COUNT Velocity Rules

There are two types of COUNT Velocity Rules. 

  • Basic COUNT rules can calculate the number of transactions made in a given timeframe in which the "Where" field values are shared.
  • COUNT DISTINCT rules work by only taking unique values into account.

SUM Velocity Rules

SUM rules work by totaling all the values in the specified field within the chosen period. You can then compare this value to a present field, value, or percentage, as with the other Velocity rules.

MIN and MAX Velocity Rules

Use MAX and MIN rules to compare the highest or lowest value in a chosen field over a given timeframe. MAX and MIN work similarly, with MAX identifying the largest value and MIN identifying the smallest transaction.
 

Testing rules

If your rule is a Data Match or Compare rule that modifies transaction states, you can test how it would work. These tests can help you determine whether it’s safe to run a rule (for example, if the rule would automatically decline transactions based on given criteria).

Running a test will create a confusion matrix based on previous transactions from the selected time frame and calculate the estimated accuracy of the rule. The time frame can take transactions from the last hour through to the last year.

Was this article helpful?