Custom rules and parameters – Current

Updated on 20.01.23
12 minutes to read
Copy link
Video Guide
A quick video guide explaining the Scoring Engine & Rules features of the SEON Sense Platform

Customizing the rules to meet your risk appetite.

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.

 

 

Rule Parameters and Types

Rule parameters are based on one of four different use cases, called Rule Parameter Types. 
 

 

The four major rule types fit different use cases, ranging from blacklisting or whitelisting data points by simple comparison, to detecting suspicious behaviours or patterns. This allows the SEON ruleset to be completely tailored to both your business needs and the most common risk scenarios. 

Rules can be set up using the same operators that are utilised when filtering on the Transactions page, please see their detailed description above.
 

  • Data match: Used for comparing two values in the same transaction, for example IP and card country mismatches.
  • Compare: Compares a parameter value to a defined value based on one of the standard operators.  For example, IP Country is XY, or Transaction Amount > 100 EUR, or Browser Hash is xyz. 
  • Velocity: Used for comparing historical values of a data point with a defined value based on the specified timeframe. For example, the number of customers that used the same IP address in the last one day. 
  • User Behaviour: Checks for the presence of a matching historical value with the current value of a data point, for the current customer. For example whether the current customer has previously used the current Browser Hash or not.

Multiple rule parameters can be added to a rule by clicking the arrow below the parameter setup, with all parameters for the current rule shown in the Current Parameters list. 

All parameters can be modified, deleted or reordered from within this list. Additionally, just like filters, parameters can also be grouped and connected with logical operators. 
 

 

Rule templates can also be applied to the current rule from the list on the right of the Add Rule Parameter options.
 

Create your rule parameter here.Add parameters using templates here.

 

 

 

Data Match

Data Match rule parameters are used to compare two data points of an incoming transaction. 

Their purpose is to filter out transactions with anomalies relating to fraudulent characteristics. 

Common examples include: 

  • User country is different from IP country.
  • User full name does not match card full name.
     
Data FieldOperatorsCompare toAdditional settings

The data point of the incoming transaction to analyse based on any of the SEON data fields.

= ( is equal to )

 ≠ (is not equal to)

The related data point to compare against, based on any of the SEON data fields.

Case-insensitivity settings can be modified here. Name related rules are case insensitive by default.

 

Compare

Compare rule parameters are used to compare an incoming transaction data point to either a specific value, to check whether it exists and/or to inspect the similarity to a specific piece of text.

Common examples include: 

  • Transaction amount is greater than 1500
  • Phone number does not exist
     

Data Field

Operators

Value

Additional settings

The data point of the incoming transaction to analyse based on any of the SEON data fields.

= (is equal to)

≠ (is not equal to)

> (greater than)

(greater or equal to)

< (less than)

(less or equal to)

exists

∄ (not exists)

contains

does not contain

Is either

Is neither

The value to compare the selected data point against.

Case-insensitivity settings can be modified here. Name related rules are case insensitive by default.

 

Velocity

Velocity rule parameters allow for the comparison of a specific data input field with a value, percentage or a present field over a certain time frame, or multiple time frames.

Velocity rules can also check the number, average, sum, maximum and minimum values of chosen fields in a given time period(s). Past fields are linked through matching data point(s), which may also be selected in the parameter setup.

All velocity rule parameter types can be combined with IF conditions to create more precise rules. By adding an IF condition to a rule, you can limit what kind of transactions will be taken into account when the rule applying conditions are calculated. 

Common Velocity rule examples include:

  • Customer has more than 10 transactions within the past 30 minutes
  • Customer has spent more than 2000 EUR in the last 7 days with prepaid debit cards.
     
FunctionExplanation
AggregateThis aggregate function will be used on the selected past field.

You can also find the settings related to the IF conditions under this menu if applicable.
Past fieldData point from a past transaction based on any of the SEON data fields, including custom fields.
Time frameThe interval over which the selected past field needs to be aggregated. It is possible to select a time range from seconds through to years, or based on a number of transactions.
For the sameThe matching datapoint(s) between the current incoming and past transactions.
Operators

= (is equal to)

≠ (is not equal to) 

> (is greater than)

(is greater or equal to) 

< (is less than)

(is less or equal to)

Compare toUsed to compare to a value or a percentage of a present field, or the present field value itself.
Number / Present field/Percentage/Second time frameChoose the value/percentage/second time frame related to the result of the aggregate function, or select a field for comparison.
Count current transactionYou can choose whether you want the current transaction to count towards the rule.
Modify score by velocity value
This feature allows you to add increasingly higher scores to transactions. The score you add here will be multiplied by the difference between the ‘Compare to’ value and the actual, current value.

 

ADDITIONAL SETTINGS


Regular aggregate: using this function you can aggregate the current rule sentence based on a regular time interval (hours/days/weeks/months). An example for this would be a rule where you want to check the number of transactions a user did every day over the last week, then take the average of those 7 numbers, this would then be compared to the value you set in the rule. 

 

When creating Velocity rules, you have the option to use Advanced time frames instead of the more straightforward Last X seconds/minutes/days etc. time frames. You have the option to set the starting and end dates of the time frames you want to use for the rule. In case you would like to compare two different, advanced time frames, you can use both the Second time frame and Advanced time frames features. Please check this example of such a rule below.

This rule will be applied if the current user’s average transaction amount converted to Euros over the period from 1 year ago until 5 months ago was greater than the average of the same values during the period from 5 months ago until 1 month ago.

AVG Velocity Rules

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

This sample rule would trigger if the current transaction’s amount was greater than the average of the amounts in the last 2 months, for both the same user and the same payment method.

COUNT Velocity Rules

There are two types of COUNT Velocity Rules. 

Basic COUNT rules can be used to calculate the number of transactions made in a given timeframe, with the specified ‘For the same’ field as a shared value.

This rule would be applied if there were at least 2 transactions (including the current one) made in the last 5 hours with the same Card.

COUNT DISTINCT rules work by only taking into account unique values. A great example for this is an anti-ATO/bonus abuse rule. 

If more than one account is being accessed with the same cookie_hash, it would be a certain indication that the same person is either opening multiple accounts, or gaining unauthorised access to these accounts from the same device.

SUM Velocity Rules

SUM rules work by totalling all the values in the specified fields over the chosen time period. The total of these values can then be compared to a present field, value or percentage, as with the other Velocity rules.

This sample rule would trigger if the same user made transactions adding up to more than 1000 EUR in two days’ time.

MIN and MAX Velocity Rules

MAX and MIN rules are used for comparing the highest or lowest value in a chosen field over a given timeframe. MAX and MIN work in the same way to each other with MAX identifying the largest value and MIN identifying the smallest transaction.

 

User Behavior

User behavior rule parameters allow  for the comparison and analysis of incoming transaction fields for the same user.

Past and present fields are linked through matching data point(s), which may also be selected in the parameter setup.

Examples include:

  • Checking to see if a user has previously used the same device.
FunctionExplanation
AggregateThis aggregate function will be used on the selected past field.
You can also find the settings related to the IF conditions under this menu if applicable.
Past fieldData point from a past transaction based on any of the SEON data fields, including custom fields.
Time frameThe interval over which the selected past field needs to be aggregated. It is possible to select a time range from seconds through to years, or based on a number of transactions.
For the sameThe matching datapoint(s) between the current incoming and past transactions.
Operators

= (is equal to)

(not equal)

> (greater than)

(greater or equal to) 

< (less than)

(less or equal to)

Compare toUsed to compare to a value or a percentage of a present field, or the present field value itself.
Number / Present field/Percentage/Second time frameChoose the value/percentage/second time frame related to the result of the aggregate function, or select a field for comparison.
Count current transactionYou can choose whether you want the current transaction to count towards the rule.

 

Exclude From Rule

It is possible to prevent rules from being applied to certain transactions using the Exclude From Rule feature. Each rule has an exclude list whereby one or more User Id's, Email Addresses, Card Hashes or IP Addresses can be added along with an expiration date.

This can be useful in cases where the customer displaying a suspicious pattern has been verified by your team to be legitimate or when you create a rule that would be applied to a user whom you would consider to be a false positive.

Exclusions can be added to rules in one of two ways: either via manual input, or at the transaction details page.
 

Manual Input

Upon opening a custom rule, scroll down, find the Exclude From Rule section and follow the Open List button. This shows the currently excluded values as well as giving the option to add new values using the (+) button. 

Select which data point is required to be added to the exclude list, enter the value to exclude and select an expiration time. Clicking Load reviews the item to be added which can then be finalised by clicking the Exclude from Rule button.

 


Transaction Input

It is possible to exclude specific users directly from an individual Transaction Details screen.

On opening up a transaction, all custom rules that have triggered by the transaction can be seen in the Applied Rules widget. Next to this is an icon of a crossed out man, which when pressed will bring up a window where you can select the same settings as in the previous section to exclude this specific user from the selected rule. On applying the changes it is possible to then see that the user whose transaction you are viewing is excluded from the rule.
 

 

Rule Tester

If the custom rule is a Data Match or Compare rule that modifies state then it is possible to test it at the bottom of the Rule Editor screen. This allows you to test rules on your data before turning them on live, allowing you to determine if it’s safe to run a rule or not (in case it would automatically decline transactions based on given criteria, for instance).

Running a test will create a confusion matrix based on previous transactions over the selected time frame and highlights the estimated accuracy rate of the rule.

It is possible to test the rule over a specific date range - selectable from the last hour through to the last year.
 

Example 1

Example 2

Select currency in the bottom right to see the amounts related to the transactions.

 

Was this article helpful?

?Got a question

Talk to sales