Velocity
Velocity Check helps identify fraud in online purchases by detecting repeated data such as CPF, card number, ZIP code, and purchase amount. This tool combats bursts of fraudulent cards.
As the main benefit, e-commerce merchants can protect themselves against card testing attacks, one of the biggest offenders of conversion rates.
The API uses REST architecture and exchanges data in JSON format. Authorization follows the OAuth 2 protocol, widely adopted by the market and technical communities
To learn more about OAuth 2, see https://oauth.net/2/.
Objectives
- Qualifies transactions received by acquirers;
- Assists in detecting suspected fraud;
- Acts as an ally to block burst attacks (such as card testing) and to assess suspicious purchasing behaviors;
- Uses calculations based on variable velocity analysis and their incidence within specific time intervals.
How does Velocity work?
Velocity Check analyzes the repetition of the following traceability elements:
- Card number;
- Cardholder name;
- Delivery ZIP code;
- Billing ZIP code;
- Order number;
- Shopper's IP address;
- Identification document (CPF or CNPJ);
- Shopper's email.
The mechanism calculates the number of repetitions for each traceability element within a specific period, based on the merchant's transaction history.
Both the number of repetitions and the period are configurable. Example of a configured rule:
- Variable (V): card number;
- Repetitions (H): five;
- Period (P): one hour.
Under this rule, the sixth purchase attempt using the same CPF within one hour will be rejected.
Quarantine
When creating a rule, you can define how long a piece of data will be considered in future analyses. For example, if the merchant wants to track how many times the same card number was repeated over a 12-hour period within a 2-day window, Velocity Check does not need to count old data in separate periods.
Without quarantine, the application would need to count data in separate periods, such as:
- D-2 = 0h to 12h
- D-2 = 12h to 0h
- D-1 = 0h to 12h
- D-1 = 12h to 0h
With quarantine configured, the application checks if the data is already in quarantine. If it is, it will be automatically blocked without counting separate periods.
For example: if the rule sets a quarantine time of 2 days, the system analyzes the last 12 hours and checks if the card number was placed in quarantine within the past 2 days.
If the transaction is not rejected by the rule but is rejected by quarantine, the response will indicate that it was rejected due to quarantine
Negative List
If the card number is on the negative list, the transaction will be automatically rejected, even without specific rules.
A transaction analyzed and rejected by the negative list will return a message indicating it was rejected due to the negative list.
Positive List
If a transaction is under analysis and the card number sent for review is on the positive list, the transaction will be approved regardless of whether there is a registered rule for this variable. All other rules for different variables will be ignored.
A transaction analyzed and approved b
Updated 2 days ago