Centralpay's fraud detection is based on 4 complementary services:
- Blacklists / whitelists management
- A transaction acceptance service based on contextual rules
- A real-time fraud detection service
Those 4 complementary services form a new approach to fraud management, the aim of which is to offer merchants a better acceptance rate for a minimum of chargebacks. The fact is that most of the current anti-fraud solutions generate a large number of false positives which cause loss of sales and do not sufficiently protect the merchant against fraud and unpaid payments.
1. BLACKLISTS / WHITELISTS
Several levels of black or white lists are available:
- Card numbers
- Phone Numbers
- IP Addresses
Blacklists allow unconditional refusal of a transaction on the basis of the criteria mentioned above.
On the basis of these same criteria, the whitelists allow to bypass the potentials blacklists and other acceptance rules.
For example : If a whitelisted card, IP, e-mail or phone number is presented to the rules engine, only unconditional rules will be executed.
2. ACCEPTANCE RULES ENGINE
This service defines the action associated with more than 100 attributes in order to determine whether an operation should be :
- validated in 3DS,
- validated using an OTP (Mail or SMS),
- validated using a CVC
Right to Rules
The right to execute a rule follows the logic of the platform:
N +2 <Platform>
N +1 <Merchant>
N <Point of Sale>
Thus, a rule executed at the top level will always have the ascendant on the lower rule.
Acceptance rules and scenarios
The unitary rules thus created are organized in a rules container called scenario. It allows each rule to be executed in a logical order.
Each rule can then be defined as:
- Unconditional, intangible and immutable rule that will be executed even for whitelists
- Conditional rule that will not be applied for whitelists
- String: = | ! = | IN | NOT IN
- Integer | Double: = | ! = | IN | NOT IN | <| > | <= | > =
- Boolean: = | ! =
Interaction with payment forms (Custom Form)
According to the defined rules and in the case where an interaction is foreseen with the cardholder, a transaction request may involve the cardholder.
Two interactions are currently planned:
- A request for CVC
- A request for OTP (One Time Password)
- A request for a 3DS payment with a checkEnrollement
In both cases, an HTTP 307 response from the platform will be returned in JSON format. This will contain the value of the 3 attributes:
For 3DS requests: the result of the Enrollment object from the checkEnrollment service
For OTP: a boolean
For CVC: a boolean
A) Response to a request for check-Enrollment
If the transaction must be 3D-Secure then the JSON checkEnrollment attribute is populated with the result of a checkEnrollment performed by the API itself. This operation is therefore carried out in place of the merchant.
The merchant can thus directly carry out the redirection of the carrier with the information transmitted without making himself checkEnrollment.
Example of a return of 307 for a 3DS checkEnrollement:
"merchantName": "My merchant",
"paReq": "eJxVUsGSmzAM/RWGO7GNoYaM8A7dTKc5sM1ssx/gGCWhkwBrQ0n69bUT0t0ePNaTZOnpyfB0OZ+C32hs07VFy BY0DLDVXd20hyJ8236LsjCwg2prdepaLMIr2vBJwvZoEFc/UY8GJVRorTpg0NRFqPVOcb5jUZ7u8yjhuYqyJN1HHAX dZRS14nEoYVO+4ruEubN0jRcxkAd0FY0+qnaQoPT71/WLTHJBGQMyQzijWa8kZUnMv1AgdwitOqPcdDYJlNbYO94 agdy8oLuxHcxVijgB8gAwmpM8DkNvl4RM07TQ6Pzq1KvrAkeyNwSITwHywWgzesu6kpemltVWTy9/SlZt36bqV0V/rMr L+rk8uFMA8RlQqwFlTJmggqYB40saL3kK5OYHdfZcpMhyN93dht63KD8FPjvAiW7ckq4yF5kb5YEAL73bkctwSv6zoU arHf/5+iD//N2Lqwen24MbS2nMUyqE1/kW8TUbpxMT7F7UAyD+LZlXSObtO+u/X/EXy9fEgw\u003d\u003d",
Thus, in this case, the transaction will only be accepted if the cardholder validates his 3DS code.
B) Response with OTP
If the transaction must contain an "OTP" (HTTP parameter otp) then the otp attribute is true. In this case the merchant must request for this "OTP" to the cardholder.
This OTP is a 6-digit OTP type, then the merchant must use a new OTP service to send the OTP by email or SMS and then request that OTP to the cardholder in order to send it in the http otp parameter of its transaction.
Example of return of http 307 for an OTP request:
In this case, the transaction will only be accepted if the cardholder validates the OTP (6-digit otp).
C) Response with CVC
If the transaction must contain a "CVC" (HTTP parameter cvcValidation) then the cvc attribute is true.
Then the merchant must request the CVC from the cardholder and pass it in the http cvcValidation parameter of the transaction.
Example of return of http 307 for an CVC request:
In this case, the transaction will only be accepted if the cardholder validates the CVC.
3. FRAUD SCORING
Centralpay also request a fraud detection service.
This real-time service is obtained by crossing the following criteria:
- Verification of geolocation
- Risk analysis associated with IP address, equipment and e-mail address
- Credit card information
- Transaction data
- Reputation analysis
This fraud exposure analysis service allows the analysis of the risk exposure context of each transaction. This service returns a score that manually processes a transaction potentially exposed to fraud.
The score is based on a cross-analysis of the following data:
- IP risk index
- Proxy Detection
- Digital network detection
- Checking the IP address
- Confidence factors
- Email checks
- Financial institution checks
- Address & phone checks
- High Risk Shipping Address
- Geolocation of IP addresses
- Identification of equipment used
- E-mail adress
- Browser Type
- Security code CB
- Country discrepancies
- Distance from the shipping address
- Distance from billing address
- Domain e-mail
- Amount of the order
- Phone number
- IP owner
- Holder of the e-mail
- CB address verification