Anti-fraud services

1. Organization of anti-fraud services

Anti-fraud services are segmented into 4 tools:

• Whitelist
  The purpose of the “whitelist” is to make the application of a transaction acceptance rule selective. It becomes inoperative for identified customers, VIPs, or trusted customers who are included in a “whitelist”. “Whitelists” apply to customer-specific data, such as their bank card number or IP address. This feature makes it possible to be less restrictive for certain user populations.
• Blacklist
  The “blacklist” service makes it possible to refuse payments. As with “whitelists”, “blacklists” apply to data specific to the cardholder (card, IP, phone, email).
• Transaction acceptance rules
  This tool makes it possible to build the specific rules that define the conditions for accepting a payment.
• Anti-fraud scoring
  The scoring service detects potentially fraudulent transactions based on cross-analysis of multiple payment-related data points.

The transaction processing phases are always executed in this order.

If the input data meets all the conditions of the defined “whitelist”, the “blacklist” service will not be executed and the transaction will be processed normally.

If the input data meets one of the conditions of the defined “blacklist” and is not included in the “whitelist” service, the transaction will be refused and the “acceptance rule” service will not be executed. Each service is executed top-down with respect to the CentralPay actor hierarchy, which means that a platform can apply its anti-fraud service settings to its merchants, but the reverse is not possible.

2. Fraud scoring tool

CentralPay relies on a fraud detection service based on machine learning algorithms.

This predictive engine is built from a large sample of data provided by CentralPay in JSON format and sourced from transaction, refund, dispute data.

This service relies on behavioral classification linked to the merchant’s business sector.

The engine returns an action and a score. The action instructs the payment service to accept or refuse the transaction.

The score classifies the risk level by providing a percentage probability of fraud. This score is then interpreted in the rules engine.

The score enables the merchant and the algorithm to interact together to improve.

Scores are classified as follows:

• From 0 to 19 = low risk
  Transaction accepted
  No action
• From 20 to 59 = medium risk
  Transaction accepted
  Action: Send an event with score details for manual review and learning
• +60 = high risk
  Transaction refused
  Action: Send an event with score details for manual review and learning

This fraud exposure analysis service analyzes the fraud risk exposure context of each transaction. This service returns a score that makes it possible to automatically process the expected response in the rules engine.

The score is based on cross-analysis of the following data:

• IP risk index
• Proxy detection
• TOR network detection
• IP address verification
• Confidence factors
• Email checks
• Address & phone checks
• High-risk shipping address
• IP address geolocation
• Identification of the devices used
• Email address
• Browser type
• Country mismatches
• Shipping address distance
• Billing address distance
• Email domain
• Time
• Order amount
• Country
• Phone number
• IP owner
• Email owner
• Card address verification

3. Whitelists and blacklists

3.1. Whitelist

The purpose of the “whitelist” is to make the application of an acceptance rule selective. This rule becomes inoperative for identified customers, VIPs, or trusted customers who are included in a “whitelist”.

The anti-fraud service then moves on to the next step.

“Whitelists” apply to customer-specific data, such as their bank card number or IP address. This feature makes it possible to be less restrictive for a user population.

3.2. Blacklist

The “blacklist” step makes it possible to refuse payments.

As with “whitelists”, “blacklists” apply to data specific to the cardholder:

• Country
• Geographic regions
• Card numbers
• Phone numbers
• Email
• IP addresses
• IBAN

4. Transaction acceptance rules

The acceptance rules engine is a powerful, modular application component that makes it possible to adapt the processing behavior to be applied to each transaction, such as:

• Allow
• Refuse
• Alert

This service therefore makes it possible to define actions to be performed on each transaction from a wide list of available attributes: fraud score, cardholder location, total sales amount over 7 or 30 days, VIP whitelist customer, specific parameter provided by the merchant…

An acceptance rule is a logical condition. It makes it possible to authorize, restrict, and/or prohibit transactions.
A rule consists of 4 elements: the action, the attributes, the operators, the values.

The syntax of a rule is as follows: “Action” “if” “Attribute” “Comparison operator” “Comparison value”

Example:

REFUSE if card_country != 'FRA'

The rule shown in this example makes it possible to automatically refuse payments when the card country is not France.
The grammar syntax chosen by the platform for its acceptance engine is very similar to SQL syntax (used to interact with databases).

4.1. Available actions

• ALLOW
  Allows the payment
• REFUSE
  Refuses the payment
• ALERT
  Sends a “webhook” notification for the associated transaction

4.2. Available attributes

By typing “#”, the available attributes are displayed.

In a rule, an attribute is always followed by a comparison operator.

List of attributes:

Attribute	Description	Value type	Example
#always		None
#transactions[_état][_entité] [_temporalité]	Transaction count quota [state] [entity] [time period]	Integers
#transactions_amount[_état] [_entité][_temporalité]	Transaction amount quota [state] [entity] [time period]	Integers
#amount	Transaction amount in cents	Integer	#amount > 100
#card_country	Card issuing country	String ISO 3166-1 alpha-3	#card_country IN (‘FRA’, ‘USA’, ‘BEL’, ‘DEU’)
#card_establishment	Card issuer
#card_product	Card type	‘gold’, ‘platinium’
#card_product_type	Card type (personal or corporate)	CONSUMER CORPORATE	#card_product_type = ‘CONSUMER’
#card_region	Card issuing region	‘ASIA_PACIFIC”EUROPE”LATIN_AMERICA”MIDDLE_EAST_AND_AFRICA”USA_AND_CANADA”ANTARCTIQUE”UNKNOWN’	#card_region NOT IN (‘ASIA_PACIFIC’, ‘LATIN_AMERICA’)
#commercial_brand	Card brand	VISA MASTERCARD AMEX OTHER	#commercial_brand != ‘VISA’
#currency	Transaction currency	String ISO 4217	#currency = ‘EUR’
#ip_country	IP address country	String ISO 3166-1 alpha-3	#ip_country IN (‘FRA’, ‘USA’, ‘BEL’, ‘DEU’)
#ip_region	IP address region	‘ASIA_PACIFIC”EUROPE”LATIN_AMERICA”MIDDLE_EAST_AND_AFRICA”USA_AND_CANADA”ANTARCTIQUE”UNKNOWN’	#card_region NOT IN (‘ASIA_PACIFIC’, ‘LATIN_AMERICA’)
#is_anonymous_ip	Is an anonymous IP	TRUE | FALSE	#is_anonymous_ip = TRUE
#is_three_d_secure	Is a 3D-Secure transaction	TRUE | FALSE	#is_three_d_secure = TRUE
#payout_amount	Payout amount	Integer	#payout_amount > 100
#payout_currency	Payout currency	String ISO 4217	#payout_currency = ‘EUR’
#risk_score	Anti-fraud score	Double	#risk_score > 2,34
#custom_acceptance_data[‘key’] = ‘value’	custom field	key : Regex [a-zA-Z0-9_-]value: Regex [a-zA-Z0-9_-]	#custom_acceptance_data[‘product_category’] = ‘high’

In the case of custom_acceptance_data[‘key’] = ‘value’, for it to be taken into account, the exact same field must be included in the request for the targeted object.

Logical operators and parentheses:

Logical operators AND and OR

The syntax used to define rules makes it possible to create multiple conditions within the same rule. The conditions will remain defined in the same way, with the only difference being that a keyword will be placed between the conditions.

The keywords are and and or. They define how the rules engine will interpret the sequence of these rules. “AND” corresponds to inclusion and “OR” to exclusion.

Example:

ALLOW if #amount < 1000 and #card_country = 'FRA'

The previous example allows payments whose amount is less than 10 AND whose card is French. If one or the other of the defined conditions is not met, the action will not be executed.

Example:

ALLOW if #amount < 1000 or #card_country = 'FRA'

The previous example allows payments whose amount is less than 10 OR whose card is French. If one or the other of the defined conditions is met, the action will be executed.

Parentheses

Using parentheses when defining a multi-condition rule makes it possible to define condition blocks and the priorities between these blocks. The principle is the same as for priorities in mathematical operators.

Example:

ALLOW if #amount < 1000 and (#card_country = 'FRA' or #currency = 'EUR')

In the previous example, the rules engine will first interpret the block (#card_country = ‘FRA’ or #currency = ‘EUR’). That is, the payment will be allowed if (the card is French or the currency is the euro), AND the amount is less than 10.

Rule execution order

Rules are executed in an order to be defined. This order is important because as soon as a transaction meets the criteria of a rule, the following rules will not be processed.

Rules are executed in the display order of the list in the interface.
A position indicator is displayed in each list. To change a rule’s position, simply drag it to the desired position.

Rule examples:

ALLOW if #amount < 1000 and #transactions_amount_daily < 10000

This example allows transactions whose amount is less than 10 if the sum of the day’s transaction amounts is less than 100.

REFUSE if #risk_score > 3 or (#ip_regions = 'ASIA_PACIFIC' and #card_region = 'ASIA_ PACIFIC')

This rule blocks payments if the risk score exceeds 3 or if the IP used and the card issuing region correspond to the ‘ASIA_PACIFIC’ zone.

THREE_D_SECURE if #card_country NOT IN ('FRA', 'USA', 'GBR') 

This rule requires a 3D Secure transaction if the card country is not France, the United States, or Great Britain.

ALLOW (#amount < 10000 and #transactions_amount_daily < 100000) or (#currency IN ('EUR', 'USD') and #transactions_amount_monthly < 1000000)

This previous example ALLOWS payments IF the amount is LESS THAN 100 AND the sum of the day’s transaction amounts is LESS THAN 1000 OR the currency is € or $ AND the sum of the month’s transaction amounts is LESS THAN 10,000.

The logical operators “AND” and “OR” are only syntactically correct in lowercase.

4.3. Available comparison operators

• = (equals)
• != (not equal to)
• < (less than)
• <= (less than or equal to)
• in (in the following)
• not in (not in the following)

The comparison operators = , != , > , < , >= and <= must be followed by a value.

The IN and NOT IN operators are followed by a list of comparison values.
A list of values is enclosed in parentheses, and the values inside the list are separated by commas.

Example:

REFUSE if #currency NOT IN ('EUR', 'USD', 'GBP', 'CHF')

The example shown above makes it possible to refuse all payments whose currency is not the Euro, the US Dollar, the Pound Sterling, or the Swiss Franc.

This syntax avoids writing multiple rules or multiple conditions within the same rule.

4.4. Available values:

Depending on the value type, the syntax used to define the value will not be the same:

• Integers (numeric value without decimals): Standard syntax (e.g., 100)
• Doubles (numeric value with decimals): The value is defined with a dot as the decimal separator (e.g., 12.32)
• String: The value is defined between single quotes (e.g., ‘FRA’)
• Booleans: The value is true or false (e.g., false)

ℹ️ "Amount" values must be provided in cents (e.g., for €10 you would provide a value of 1000).

4.5. Logical operators:

The available operators are AND and OR. They define how the rules engine will interpret the sequence of these rules. “AND” enables inclusion, while “OR” enables exclusion.

Example:

REFUSE if #amount < 1000 and #card_country != 'FRA'

The example shown above makes it possible to refuse payments whose amount is less than €10 AND whose card is not French. If one or the other of the defined conditions is not met, the action will not be executed.