Score calculation logic

In SEON, each transaction receives a fraud score that reflects the likelihood of fraud. This score helps determine how the transaction should be handled — approved, reviewed or declined.

The fraud score is calculated by adding together the values of all rules triggered during a transaction. Each rule has a predefined decimal value (for example, -15.00 or +3.00), which is applied when the rule is triggered.

Note: While individual rules can have negative values, the final fraud score is always normalized to fall between 0 and 100.

Scores are calculated using floating-point numbers for performance reasons, so minor rounding differences may occasionally occur.

Several factors can influence how a transaction’s final fraud score is calculated:

• Score weights
• Modify score option in velocity rules
• Result of the rules (state, score)

You can adjust how strongly email and IP rules affect the fraud score by applying score weights in the Settings page.

• Weights are applied as percentages, ranging from 0% to 200%.
• These weights scale the original rule scores up or down.

Warning: This applies only to IP v1 and Email v2 and is not supported for Phone scores or newer versions, such as Email v3 (ADF).

Velocity rules include an optional Modify score setting that dynamically adjusts a rule’s score based on how much a value exceeds (or falls below) a defined threshold.

This option can be used when the velocity condition includes numeric comparison operators such as >, <, >= or <=.

How it works

The additional score is calculated as:

int(abs(right side - left side)) * modifyscore

• The modify score value is always stored as a positive number
• In the UI, it is displayed using the same sign as the rule’s base score

Let's see an example using the screenshot above. 
Modify score = 0.5
A rule with a base score of 10 is triggered by a velocity condition. In this case, the number of unique transactions is 5 (left side), while the fixed value on the right side is 9.
The rule’s score is increased by (9 ? 5) × 0.5 = 2, resulting in a final rule score of 12.

1. Default rules are evaluated first
Scores are calculated separately for standalone categories (email, IP, phone, device).

2. Standalone category scores are normalized
Any negative category score is adjusted to 0, and all category scores are kept between 0 and 100.

3. The default fraud score is calculated
The default fraud score is calculated by combining the standalone category scores — applying any configured weights where relevant — with the scores from all other default rules. The result is normalized to ensure it falls within the 0–100 range.

4. Custom rule scores are added
Scores from custom rules are then added to the default fraud score, and the total is normalized again to remain between 0 and 100. At this point, SEON has calculated the final fraud score for the transaction.

5. Transaction state is determined
The final score determines the transaction's state (APPROVE, REVIEW or DECLINE) based on the State thresholds defined in Settings.

If a transaction triggers at least one state-based rule, SEON skips the regular score calculation and relies only on state-based outcomes. Blacklisting and whitelisting rules are handled as state rules.

If multiple state rules trigger and conflict, SEON resolves the final state using the State conflict settings.

Once the final state is determined, SEON assigns the score as follows:

• APPROVE: score is set to 0
• REVIEW: score is set to the lower bound of the Review threshold
• DECLINE: score is set to 100

If a transaction matches a blacklist or whitelist entry, the state is immediately determined:

• Blacklist only: DECLINE (score = 100)
• Whitelist only: APPROVE (score = 0)
• Both: REVIEW (score = lower review threshold)

Similarity-based matching allows SEON to detect values that are not an exact match, but are still close enough to suggest intentional variation. This is commonly used to catch blacklist evasion, multi-accounting or repeated abuse attempts where small changes are made to avoid detection.

How similarity affects scoring and state
When similarity matching is enabled, a similarity match can behave in one of two ways, depending on customer configuration:

• As a state-based rule: The similarity match directly determines the transaction’s state (APPROVE, REVIEW or DECLINE), overriding regular score calculation.
• As a score-based rule: The similarity match contributes a score, which is added to the transaction’s fraud score and processed through the standard scoring logic.

This flexibility allows you to decide whether similarity should immediately block or allow transactions, or simply influence the final fraud score.

Learn more: For more details on similarity matching — including how similarity is calculated, what counts as similar or highly similar and supported use cases — see the Similarity features overview.

For standalone APIs (such as IP or Email), only rules relevant to that API are evaluated. For example, the IP API evaluates only IP-related rules.

Standalone scoring is supported for:

• Email v2
• Phone v1
• IP v1

Newer API versions do not calculate scores.

Customers can configure Rule categories to calculate scores or states at a category level.

• Category results are returned only if rule_category_details is included in the Fraud API request
• Categories can have their own state thresholds
• These scores and states are calculated only using the rules assigned to the category, and they do not affect the transaction’s final fraud score or state at all.

The AI insights score is calculated per transaction using machine learning models.

• It can be enabled from the Settings page
• When enabled, it may introduce hidden state-based rules
• These rules can automatically approve or decline transactions based on the AI score