Scoring Engine & Rules

Updated on 08.11.21
30 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.

Scoring Engine

By default the fraud scores generated by SEON are based on the Default Rules in the system.

In order to personalise the Scoring Engine, users can create rules based on any relevant logic. On the Scoring Engine Page, users are able to review and modify all existing rules or add new ones to the system.

Users are able to navigate between different rule types by using the navigation bar at the top of the screen.
 

 

Rule Types

There are three rule types within SEON - Default Rules, Custom Rules and Machine Learning Rules.
 

Default Rules

These are pre-added rules tailored to your industry and geographic area. It’s possible to turn them on/off and modify their score, but you can’t add new ones or delete any. You can set up similar rules as custom rules.
 

Custom rules

Custom rules allow you to tailor the SEON algorithm to your specific needs and are created by you or by SEON Support. You can modify them and add new or delete.
 

Machine Learning Rules

These are rules automatically generated by the SEON Machine Learning algorithm and are based on your feedback from labelling and manual reviews. It’s possible to turn them on/off, but you can’t add new ones or delete any.

You can learn more about them from their respective Knowledge Base article.
 

Dashboard

On the Dashboard, you can see an overview of all the rules in the three different categories of SEON. This shows against each rule type the number of active rules as well as the total number of rules available.
 

 

Beneath the initial overview, the Applied Rule Statistics Widget is shown. This shows the list of rules in the system that have been triggered either Today, within the last 7 days or the last 30 days as well as their frequency. It can be helpful to understand what rules are being triggered and also which may be unnecessary.

Hovering over any of the applied rules shows options to edit the selected rule or to display a filtered list of all transactions triggered by the selected rule.
 

 

Scoring Engine Rule Management

Scoring Engine Rules are able to be managed from the top navigation, with the basic functionalities being the same regardless of the rule type selected.

Additional functionality is available for Custom Rules - explained further in the documentation.

  • Clicking on the Open Filters button allows you to filter your rules based on both their contents and/or their properties - for example either whether they contain a specific data point rule and/or whether a rule undertakes a specific action such as setting a fraud score or state.
     

 

  • Rules may be assigned to particular categories and these are shown at the top of the rule listings. Categories are fixed for the Default Rules and Machine Learning Rules but new categories can be created for Custom Rules by clicking the Add New Category button. When creating a custom rule you can select the category you want to put the rule in or you can move existing rules into a category at a later time. 
  • Individual rules can be turned on-off by clicking the switch to the left of the rule title
  • Clicking on any rule in the rules list will bring up the detailed profile of the selected rule.
  • New custom rules can be created by clicking the “Create New Rule” button at the top of the Custom Rules screen.

You may also export all rules using the ‘Export all rules’.
 

 

You also have a number of mass management functions available which become visible once you start selecting rules using the check box next to them.

  • Duplicate rules: this feature creates copies of your rules in a turned off state.
  • Copy to Sandbox/Production environment: depending on which instance you are currently in, this function allows you to copy your rules over to the other environment, either Sandbox or Production. Please note that, similarly to the previous feature, this creates rules in a turned off state.
  • Turn ON/OFF rules: you can turn multiple rules ON or OFF at the same time instead of having to do this one-by-one.
  • Move rules to category: using this feature you are able to move multiple rules to a desired category by the click of a button.
  • Delete rules: instead of having to open a rule to delete it, you can now do this with any number of rules all at once.
     

Rule Setup

Rules represent the various branches in the SEON decision tree. Rules may contain one or more parameters joined by specific operators. These rule parameters can be considered the nodes of the decision tree. 

You may add new or modify existing Custom Rules and their actions, turn them on or off, rename them or add triggering conditions. For Default and Machine Learning rules you can turn them on or off and change the scores given as a result of a rule match.
 

Rule Actions

Rules may have one of three actions. A rule can either change the score of a transaction, it can set the state of a transaction or it can blacklist/whitelist a certain field. The state of the action is set using the ‘Action’ toggle option at the top of the Rules details.

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 Field

Operators

Compare to

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)

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 Transactions Detail 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.

 

Confusion Matrixes Explained

In the field of machine learning and specifically the problem of statistical classification, a confusion matrix, also known as an error matrix, is a specific table layout that allows visualization of the performance of an algorithm. This allows for the calculation of rate of true positives and true negatives as opposed to simply screening for rule accuracy, which can be misleading if the cases in the two sets vary greatly.

 Predicted: NoPredicted: Yes
Actual: NoTrue NegativeFalse Positive
Actual: YesFalse NegativeTrue Positive

 

Understanding a confusion matrix - an example case

Consider the following hypothetical scenario:

The machine learning system has identified a pattern associated with a fraudster and suggests a rule for it. When searching for these attributes, 165 transactions in the system are identified that match this pattern (n = 165), however only 105 are actually true fraud with 60 legitimate transactions. 

Running the rule in the Rule Tester flags 110 transactions as fraud of which 10 belong to legitimate users (false positives) while catching the fraudsters 100 times, meanwhile only missing 5 fraud attempts (false negatives).

N = 165Predicted: NoPredicted: Yes
Actual: No5010
Actual: Yes5100

 

Based on this, it is possible to calculate the accuracy and the misclassification rate:

  • Accuracy: Overall, how often is the rule correct?

(TP+TN)/total = (100+50)/165 = 0.91
 

  • Misclassification Rate: Overall, how often is it wrong?

(FP+FN)/total = (10+5)/165 = 0.09

equivalent to (1 - Accuracy)

also known as "Error Rate"

Was this article helpful?

?Got a question

Talk to sales