Overview
Centralpay's fraud detection is based on 4 complementary services:
- The Black lists and White lists management
- A post-transaction alert service based on behaviour analysis and related transactions
- A transaction-acceptance service based on contextual rules
- A real-time fraud detection service based on machine learning technology
The 4 complementary services form together a new global approach of fraud management which objective is to provide:
- On the one hand, a better acceptance rate for a minimum of unpaid for the merchants
- On the other hand, providing to CentralPay the means to manage its policies AML/FT *.
Blacklists and whitelists management
Several levels blacklisting and whitelisting are available:
- Country
- Geographic regions-MAP numbers
- Phone Numbers
- IP Addresses
- IBAN
BLACKLISTS:
Blacklists allow unconditional transaction denial based on the above-mentioned criteria.
BLOCKING:
On the same criteria basis, blocking allows to avoid potential blacklists and other acceptance rules.
For example: if a whitelisted card, an IP address, an e-mail, or a phone number is presented to the rules engine, only unconditional rules will be executed.
Fraud detection service
CentralPay relies on a fraud detection service based on machine learning algorithms.
This predictive engine is made from a large sample of data provided by CentralPay in JSON format and from TRANSACTION / REFUND / DISPUTE data.
This service is based on a behavioral classification related to the merchant's business line.
The engine returns an action and a score.
The action invites the payment service to accept or deny the transaction.
The score, classifies the level of risk by providing a percentage of probability of fraud. This score is then interpreted in the rule engine.
The score allows the merchant and the algorithm to interact together to improve themselves.
The scores are classified as follows:
From 0 to 19 = low risk
Accepted transactions
No carried out action
From 20 to 59 = average risk
Accepted transactions
Action: send an event with score details for manual review and learning
+60 = high risk
Denied transaction
Action: send an event with score details for manual reviewing and learning
This fraud exposure analysis service analyzes the exposure context of the fraud risk of each transaction. This service returns a score that allows to process automatically the expected response in the rule engine.
The score is based on the cross-analysis of the following data:
- IP Risk Index
- Proxy Detection
- Network Detection TOR
- IP address Checking
- Confidence Factors
- Email Checking
- Address & Phone Checking
- High-risk shipping address
- Geolocation of IP addresses
- Identification of the equipment used
- Email Address
- Browser Type
- Country Inconsistencies
- Distance from the shipping address
- Distance from the billing address
- Email Domain
- Time
- Amount of the order
- Countries
- Telephone Number
- IP Holder
- E-mail Holder
- CB address Checking
Working principle
The rules of acceptance engine is a powerful and modular applicable unit that adapts the behaviour related to the processing to be performed on each transaction like:
- Accept
- Refuse
- Accept in 3DS
- Accept with CVV
- One time Password
- Alert
- …
This service allows you to define actions to be performed on each transaction from a large list of available attributes: fraud score, holder location, cumulative sales amount over 7 or 30 days, VIP client whiteliste, specific parameter addressed by the merchant...
The transaction processing system is composed of several consecutive steps which rules are always linked together in a pre-set order:
The processing system for a transaction is split into three stages:
1White list:
They make the use of a selective rule.
For example, for identified customers, VIP customers or customers acknowledged as trustworthy that are integrated into a White list, the initially defined rule becomes ineffective.
The service therefore goes on to the next stage.
The “White list” deals with specific customer data, such as the number of their bank card or IP.
2Black list:
Black list makes possible to refuse payments.
As for White list, the Black list deals with the card owner’s specific data (Card, IP, Tel., E-mail).
3Acceptance:
This step makes possible to draw up specific rules that define the acceptance conditions of a payment.
The processing phases for transactions are always executed in this order.
- If input data fulfil all the defined conditions of the White list, the Black list phase won’t be executed and the transaction will move directly to the Acceptance phase.
- If the Black list phase is executed on an operation goes, in case of an input data fulfilling one of the defined Black list conditions, payment will be refused and the Acceptance phase will not be executed.
- Each phase is executed top down with regard to the payment system actor hierarchy.
The flowchart shows the hierarchical operation of the payment system.
The transaction processing system falls within this logic of actor hierarchy.
Indeed, each "Actor” can define rules for lower entities on which they have rights. Under no circumstances may a lower entity (sub account) define, modify or consult rules dealing with a higher entity.
The rules therefore follow the same hierarchy as actors whose rules are executed bottom up.
Note: rights on rules only apply to levels N to N-1. Financial institutions with agents may therefore not access rules performed by their agents’ traders.
Acceptance rules
Definition
An acceptance rule is a logic condition. It enables to:
- authorise
- restrict
- and/or prohibit transactions
A rule is composed of 4 aspects:
- actions
- attributes
- operators
- values
The syntax of a rule is as follows:
“Action" "if" "Attribute” "Relational operators" "Comparison value"
Example:
REFUSE if card_country != 'FRA'The previous example refuses payments if the country of the card is not France.
The syntax of the grammar selected by the platform for its acceptance engine is very similar to SQL syntax (used to converse with databasess).
Actions
All rules of acceptance must be related to an action.
Available actions are as follows:
ALLOW
Authorize the payment.
REFUSE
Refuses the payment.
OTP
OTP (One Time Password) asks the card holder to provide a confirmation code, the card security cipher or a single code sent by SMS or e-mail.
THREE_D_SECURE
Imposes a 3D Secure transaction.
OTP_AND_THREE_D_SECURE
Combines OTP and THREE_D_SECURE actions.
ALERT
Sends an "webhook" notification of the associated transaction.
If the transaction meets the conditions set out in the rule, the action will be executed and the following rules will not be processed.
If the action is THREE_D_SECURE or OTP, the following rules will be processed if the action is already performed (the transaction is already 3-D-SECURE or l'OTP already present in the transaction).
Attributes
The attributes (Cf. List of attributes) are comparison criteria related to the transaction admission data.
For example, the card amount or country.
An attribute always begins with the special character "#". This convention enables the rule engine to detect attributes in the rule captured. Moreover, when this character is captured in the form, the comprehensive list of self-completed attributes is available.
Attributes represent different types of values, for example:
- amount = whole type (a numerical value without a decimal),
- card country = string of characters that is 3 characters long Cf. list of attributes.
In a rule, an attribute is always followed by a comparison operator
Comparison operators
Comparison operators are mathematical operators that enable the rule engine to compare the value of the attribute and the comparison value captured.
Comparison operators are to be used according to the type of attribute selected.
| Type | Operators |
|---|---|
| Integer (numeric value without decimal) | = | != | IN | NOT IN | < | > | <= | >= |
| Double (numeric value with decimals) | = | != | IN | NOT IN | < | > | <= | >= |
| String | = | != | IN | NOT IN |
| Boolean (true, false) | = | != |
Operators = , != , > , < , >= et <= are followed by a single comparison value.
Operators IN and NOT IN are followed by a list of comparison values.
A list of values is surrounded by parentheses and values inside the list are separated by commas.
Example:
REFUSE if #currency NOT IN ('EUR', 'USD', 'GBP', 'CHF')Explanation: The previous example refuses all payments whose currency is not the Euro, US dollar, Pound Sterling or Swiss franc.
This syntax avoids drawing up several rules or conditions in the same rule.
Example:
REFUSE if #card_country IN ('ITA', 'AFG')is equivalent to:
REFUSE if #card_country = 'ITA' and #card_country = 'AFG'
Values
Values correspond to comparison aspects you define in relation to the attributes. The value is characterised according to the attribute and, therefore, the type of corresponding operator.
According to the type of operator, the syntax for defining the value will not be the same:
| Type of values | Syntax |
|---|---|
| Integer | Example: [...] = 100 |
| Double | The value is defined with a full stop before the decimal. Example: [...] = 12.32 |
| String | The value is defined between simple quotation marks '. Example: [...] = 'FRA' |
| Boolean | The value is true or false. Example: [...] = false |
For string-like values, according to the attribute selected, the syntax of the value must comply with specific standards.
For attributes such as countries (_country), values are strings of characters and must comply with the standard ISO 3166-1 alpha-3.
For monetary-like attributes (_currency), values are strings and must comply with standard ISO 4217.
Values for attributes such as card commercial brand or the IP region (ip_region), values are strings and correspond to values from a completed list, defined in the list of attributes.
The attribute #always
This attribute will never be followed by any operator or value. It is there to define the behaviour of the rule engine when the transaction has not fulfilled any of the conditions defined in the previous rules.
Example:
THREE_D_SECURE if #alwaysThe previous example imposes a 3D SECURE transaction if the payment’s input data have not complied with any of the conditions defined in the previous rules.
Logic operators and parenthesis
Logic operators and and or
The syntax used to define rules makes it possible to create several conditions within the same rule. Conditions will remain defined in the same way with the only difference being that the keyword will be inserted between the conditions.
Keywords will be and and or. They make it possible to define how the rule engine will translate the succession of these rules. The and corresponds to inclusion and or exclusion.
Example:
ALLOW if #amount < 1000 and #card_country = 'FRA'The previous example authorises payments whose amount is less than 10 AND and whose card is French. If one or other of the defined conditions is not compliant, the action will not be executed.
Example:
ALLOW if #amount < 1000 or #card_country = 'FRA'The previous example authorises payments whose amount is less than 10 OR and whose card is French. If one or other of the defined conditions is not compliant, the action will not be executed.
Parenthesis
The use of parenthesis in the definition of a multi-condition rule enables to define units of conditions and priorities among these units. The principle is the same as the one of the priorities for mathematical operators.
Example:
ALLOW if #amount < 1000 and (#card_country = 'FRA' or #currency = 'EUR')In the previous example, the rule engine will first interpret the unit (#card_country = 'FRA' or #currency = 'EUR'). That is, the payment will be authorised if “(the card is French or the currency is the euro) AND the amount is less than 10.
Order of rules exection
Rules are executed in an order to be defined. This order is important because as soon as a transaction complies with the criteria of a rule, the following rules will not be processed.
Rules are executed in the order the interface list is posted.
A position indicator is posted in each list. To switch the rule position, it is necessary to slide it to the required position.
Rules examples:
ALLOW if #amount < 1000 and #transactions_amount_daily < 10000Explaination: this example authorises transactions whose amount is less than 100 if the sum amount of transactions from the day is less than 1000.
REFUSE if #risk_score > 3 or (#ip_regions = 'ASIA_PACIFIC' and #card_region = 'ASIA_ PACIFIC')Explaination: this rule blocks payments if the risk score is over 3 or the IP used in addition to the region of issue of the card corresponds to the area 'ASIA_PACIFIC'.
THREE_D_SECURE if #card_country NOT IN ('FRA', 'USA', 'GBR') Explaination: this rule requests a 3D Secure transaction if the country of the card 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)Explaination: the previous example AUTHORISES payments IF the amount is LESS THAN 100 AND the sum amount of transactions from the day is LESS THAN 10,000 OR the currency is € or $ AND the sum amount of transactions from the month is LESS THAN 100,000.
Attribute list
| Attribute | Description | Type of values | Example |
|---|---|---|---|
| #always | None | ||
| #transactions[_état][_entité] [_temporalité] | Quota of number of transactions [état] [entité] [temporalité] | Entiers | Cf. attributs quotas |
| #transactions_amount[_état] [_entité][_temporalité] | Quota of number of transactions [état] [entité] [temporalité] | Integer | Cf. attributs quotas |
| #amount | Amount of the transaction in centimes | Integer | #amount > 100 |
| #card_country | Country of issue of the card | String ISO 3166-1 alpha-3 |
#card_country IN ['FRA', 'USA', 'BEL', 'DEU'] |
| #card_establishment | Establishment of the card | ||
| #card_product | Type of card | 'gold', 'platinium' | |
| #card_product_type | Type of card (person or corporation) | CONSUMER CORPORATE | #card_product_type = 'CONSUMER' |
| #card_region | Region of emission of the card |
|
#card_region NOT IN ['ASIA_PACIFIC', 'LATIN_AMERICA'] |
| #commercial_brand | Commercial brand of the card | VISA MASTERCARD AMEX OTHER | #commercial_brand != 'VISA' |
| #currency | Currency of the transaction | String ISO 4217 |
#currency = 'EUR' |
| #ip_country | Country of the IP address | String ISO 3166-1 alpha-3 |
#ip_country IN ['FRA', 'USA', 'BEL', 'DEU'] |
| #ip_region | Region of the IP address |
|
#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 | Amount of repayment | Integer | #payout_amount > 100 |
| #payout_currency | Currency of repayment | String ISO 4217 |
#payout_currency = 'EUR' |
| #risk_score | Maxmind score | Double | #risk_score > 2,34 |
Quota-like attributes
Quota-like attributes are split into two major groups:
- “#transactions_xxx_xxx_xxx": attributes that will deal with the number of transactions
- "#transactions_amount_xxx_xxx_xxx“#": attributes that will deal with the amount of transactions
These attributes may be more or less precise, which means they can be completed by status, entities, and by temporality (none of these aspects are mandatory).
Status
Eenables to differentiate successfully performed and aborted transactions.
The syntax of this aspect is as follows: succeeded or not_succeeded.
Examples:
- #transaction_amount_not_succeeded represents the sum amount of aborted transactions.
- #transaction_succeeded represents the number of successful transactions.
Entity
Enables to divide the attribute by entity. An entity is a card, a customer or an IP address.
The syntax is as follows: per_card, per_customer, per_ip.
Examples:
- #transactions_per_card represents the number of transactions by card
- #transactions_succeeded_per_customer represents the number of successful transactions by customer
- #transactions_amount_not_succeeded_per_ip represents the sum amount of aborted transactions by IP address
Temporality
Enables to add a temporality indicator to attributes.
The syntax is as follows: hourly, daily, weekly, monthly, rolling_hour, rolling_day, rolling_week or rolling_month.
Example:
- #transaction_hourly represents the number of transactions per hour
- #transaction_amount_rolling_day represents the sum amount of transactions by rolling days
- #transaction_succeeded_rolling_month represents the number of successful transactions by rolling months
- #transaction_amount_succeeded_per_customer_rolling_hour represents the sum amount of successful transactions by customer by rolling hours