Rules

Mangopay’s fraud prevention solution runs rules on an inquiry to generate a final recommendation. Rules are combined into rule sets, even if the set contains only one rule. A rule set is triggered against its conditions. Rule set conditions allow you to run different sets of rules for different scenarios, for example different countries or payment methods. If an inquiry doesn’t meet the conditions of the rule set, the set is skipped.

​

Strategies

At the level of the inquiry:

• If any rule set returns Refuse, the final recommendation is Refuse
• If any rule set returns Review, and no set returns Refuse, the final recommendation is Review

This means a worst-case strategy is always applied to inquiries. For each rule set, you can choose between two strategies for how to combine different recommendations from its rules.

​

Worst case

For a given rule set, a less favorable recommendation takes precedent:

• If any rule returns Refuse, the set returns Refuse
• If any rule returns Review, and no rule returns Refuse, the set returns Review
• If all rules return Accept (or Skipped), the set returns Accept

​

Best case

For a given rule set, a more favorable recommendation takes precedent:

• If any rule returns Accept, the set returns Accept
• If any rule returns Review, and no rule returns Accept, the set returns Review
• If all rules return Refuse, the set returns Refuse

In the details of an inquiry you can see the full logic that generated the final recommendation, including which sets were run to generate which recommendations (at the level of the rule set and the rules within it).

​

States

Rule sets, and each rule within a set, can be published in one of three states, or modes:

• Simulation - The rule is run on the events screened and generates a recommendation, but the recommendation does not trigger an automated action.
• Active - The rule runs on the events screened and generates a recommendation which triggers an automated action.
• Inactive - The rule is disabled and does not generate a recommendation (the inquiry is still sent and the event screened). An inactive rule can be re-activated or set to simulation mode.

The final state for each combination is shown below:

	Rule – Inactive	Rule – Simulation	Rule – Active
Rule set – Inactive	Inactive	Inactive	Inactive
Rule set – Simulation	Inactive	Simulation	Simulation
Rule set – Active	Inactive	Simulation	Active

​

Creating rules

At the most basic level, a fraud prevention rule is a conditional “if” statement. Expressions in the statement can be based on transaction data in the inquiry (such as User ID), lists, or signals generated by the profiler. The logic can be nested indefinitely and a range of operators (=, >, etc.) can be applied depending on the data type. There are several ways you can create rules in the fraud prevention panel:

• Rule builder
• List-based rules
• Velocity-based rules
• Profiler-based rules

The method of creation of the rule is shown under its title in the rule set.

​

Transition to rule builder

The rule builder interface is replacing the other rule-creation methods. Functionalities of the other methods are in the process of being added to the rule builder. We recommend that you use the builder unless the feature you require is not available.

​

Rule builder

The rule builder interface facilitates building rules and the expressions upon which to return the recommendation you select. The basic structure of a rule is as follows:

• If Expression (optional as necessary: AND/OR Expression), then Recommendation, otherwise Recommendation.

For example: If the payment card country code equals XX, then Refuse, otherwise Accept.

​

Expressions

The expressions in a rule consist of:

• Value A
• Operator
• Value B

For Value A, you can input the following possible elements:

• Attributes - An element of inquiry data (e.g. the cardholder’s name)
• Velocity - A formula to count instances of a data point (e.g., distinct card BINs) with common characteristics (e.g., the same cardholder) in a time frame (e.g. last 24 hours). You can also filter this count on other inquiry characteristics (e.g. same inquiry origin).
• Distance - The distance between two elements (e.g. user’s billing address and registration address)
• Text similarity - The similarity between two text strings (e.g. user’s full name and bank transfer owner’s full name), based on the Gestalt pattern matching method where 0 indicates no similarity and 1 indicates full similarity.

For Value B, the possibilities depend on the input of Value A.

​

Network data

For velocity rules involving some elements of card data, you are able to leverage anonymized data from all platforms processing card payments with Mangopay, not just your own. This means that if there is known or suspected fraudulent activity that occurs on other platforms, you may be able to protect your platform from similar attempts.

​

Operators

Depending on the data type of Value A, you can use the following operators when you define Value B:

​

=, !=, <, <=, >, >=

Relate Value A with the Value B that you define.

​

matches (REGEX), not matches (REGEX)

Check Value A against a regular expression (regex) that you define as Value B. In defining your regex you can use the following metacharacters:

• [ ] - Matches a single character that is contained within the brackets. For example, “[abc]” matches “a”, “b”, or “c”.
• ^ - Marks the start of the string. For example, “^Ex” matches “Example”
• $ - Marks the end of the string. For example, “ple$” matches “Example”
• \ - Marks the next character as literal. For example, ”(” matches ”(”
• * - Matches the preceding character zero or more times. For example, “Exam*ple” matches “Exaple”, “Example”, and “Exammple”
• + - Matches the preceding character one or more times. For example, “Exam+ple” matches “Example” and “Exammple”
• ? - Matches the preceding character zero or one time. For example, “Exam?ple” matches “Exaple” and “Example”
• . - Matches any single character. For example, “a.b” matches “afb”
• | - Separates alternatives. For example, “a|b” matches “a” or “b”

​

in, not in

Check if Value A matches any of a list of strings that you define as Value B.

​

is substring, is not substring

Check if Value A appears within the string that you define as Value B.

​

contains, not contains

Check if Value A contains the string that you define as Value B.

​

Versioning

The rule builder integrates versioning when you create rules, meaning that when you first save a rule it saves as V1 Draft. The versioning and publishing works as follows:

​

Not yet published - Draft

You can only edit a rule in a draft version. Drafts are saved work in progress that is not yet published: they have no impact on inquiries or recommendations.

​

Published - Active, Simulation, Inactive

Publishing a rule requires you to select a published state: Active, Simulation, or Inactive (see States). You can change the state of a published rule. To edit a published rule, you need to duplicate it. Duplicating a rule creates a new draft version (V2 Draft), which you can edit, and automatically archives the previous version (V1 Archived).

​

Previously published - Archived

Publishing a new version automatically archives the previously published version so that it can no longer be modified. You can duplicate an archived version to create a new draft version which you can edit.

​

Backtesting

In the rule builder, you can draft rules before publication and test them on historical data (a technique called backtesting) to assess their performance. This feature lets you gain an indication of how a rule behaves immediately as you build it, without needing to publish it in Simulation to assess the impact over time.

​

List-based rules

A list-based rule is based on a list of data that to accept, review, or refuse:

• A refuse list is connected to a list-based rule that generates a Refuse recommendation
• A review list is connected to a list-based rule that generates a Review recommendation
• An accept list is connected to a list-based rule that generates an Accept or Overriding Accept recommendation

The type of inquiry data in the rule must also match the list. For example, a rule that generates Refuse based on the country of a card BIN requires a list of country codes. The structure is:

• If an item on the list was found then Recommendation, otherwise Recommendation.

A list serves no purpose unless it is attached to a rule.

​

Velocity rules

Velocity rules are also available in the rule builder (see note on Transition to rule builder above). The structure is:

• Count instances of a data point (with optional filters applied). If the value is X, then Recommendation; otherwise Recommendation.

​

Profiler-based rules

The profiler enables you to leverage signals from the user’s session in your rules. When creating the rule, you can select any number of signals from the list of all those available. You can define a number of signals above which to trigger the recommendation, giving the following structure to the rule:

• If X or more signals from your list are triggered, then Recommendation.

​

Related resources

Guide

Learn about fraud prevention