What is a Velocity Check?

A velocity check is a risk-assessment regulation (in real-time) that observes the frequency of a specific customer action over a period of time that the company has as a target. The system addresses activities that occur at a frequency exceeding an established limit, such as a customer attempting payment more than once per second, by flagging or blocking them.

The web pages associated with SaaS product sales are sometimes marked as initial access points for automated software, consistent with their characteristic public availability (and not typically requiring a password for initial service interaction). Implementing velocity checks provides a means to manage at least the three most frequent categories of abuse:

•       Card testing involves the use of automated systems to submit numerous compromised card numbers through a merchant’s transaction portal to identify their operational status. A merchant’s operational expenditures encompass items such as processing fees and financial obligations related to chargebacks.
•       With Credential Stuffing, bots perform automated login sequences to test whether a considerable number of usernames and passwords, obtained through prior data collections, are functional within a SaaS platform.
•       The creation of numerous temporary free accounts via scripts enables access to various paid services, such as cloud computing or scraping tools, without a corresponding subscription. As of now, the features are accessible to these users without a fee, and future monetization is not foreseen.

A really strong set of velocity rules will only pay attention to the frequency of “a click” and also examine combinations of identity-related information to catch the fraudster who is trying their best to disguise themselves as:

• The Transaction Log: The system shows the frequency of a single credit card number, account ID, or billing address of a person being used within the given period of time.
• Device Fingerprints: Records the precise combination of hardware, browser version, and screen resolution. The scenario where a browser profile displays 20 uses within a two-minute timeframe, accompanied by varied user names, corresponds to a block classification outcome.
• IP Geolocation: The number of times a request comes from the same IP address. The system is also configured to detect occurrences as “impossible travel,” such as a login originating in New York and subsequently from Tokyo within a five-minute interval.
• Analyzing Email Behavior: Studying the behavior of a certain number of accounts being registered with temporary email providers only, or through different variations of the same email base address (like, for example, [email protected], [email protected], and so on).

Depending on the size of the company, engineering teams generally choose one of the two main implementation options:

• The Payment Service Provider: Its dashboard offers capabilities to define rules that address card-testing attempts at an initial stage. The use of this functionality does not involve modifications to the primary system or additional programming.
• Custom-Made Fraud Check (Dedicated API): A few steps before the customer action reaches your billing system, you have the right to intercept it and send in your external fraud vendor an API request. This level of analysis is based on deep in-application data tracking and complex historical decision-making, and decides to allow or block before anything is even passed further along the payment ​‍​‌‍​‍‌process.

Specific rule sets identify situations where genuine users might experience access impediments (for example, an unremembered password or a restricted internet). Here are a few tips to help you fine-tune your rules:

• Review Historical Baselines: Get insights into real user activities by looking at customer logs during periods of high volume, e.g., big product launches, to see how fast a human could work to the maximum. Initial fraud limits can be established at a level that exceeds typical human thresholds.
• Use Dynamic Rolling Windows: Instead of restarting the count after midnight, implement rolling time windows (e.g., a maximum of 3 attempts per 60-second window).
• Divide by User Trust Level: Permit faster velocity checks for well-recognized, long-time logged-in users; meanwhile, enforce strict velocity checks for unregistered guest checkouts or new accounts.

This sign is associated with the input request volume being above the configured maximum threshold during a specific duration. A simple, generic error message (paired with blocking subsequent attempts) could inform unauthorized entities about aspects of security measures. This combination also bears on the experience of authenticated users. One efficient way to address an overflow is to introduce CAPTCHA or multi-factor authentication (MFA), as doing so stops the bot’s automation, at least for the moment, and also gives the human user a way out by letting them complete their work.