Skip to main content
Commerce Security Authority
Category: Fraud Detection Analytics

Geo-Velocity Checks

Also known as: Geo-Velocity, Impossible Travel Check, Geo-Velocity Violation Detection
Simply put

A geo-velocity check is a fraud and identity-risk signal that compares the locations and timing of two events, such as logins or transactions, to judge whether the same person could realistically have traveled between them in the elapsed time. If someone appears to be in two distant places sooner than travel would allow, the check flags this as suspicious. It is one risk signal rather than a standalone control, and it may produce false positives or negatives depending on how location and timing are determined.

Formal definition

Geo-velocity checking is a form of velocity analysis that evaluates whether two authentications or transactions could plausibly have originated from the same actor given the geographic distance between their inferred locations and the time span separating them. A geo-velocity violation is typically defined as occurring when the interval between a prior successful event and the current attempt is shorter than the minimum feasible travel time between the two locations. It functions as an identity-risk signal that can feed adaptive or risk-based authentication decisions rather than as a control in its own right, and its accuracy depends on the reliability of location inference (for example IP geolocation, which can be affected by VPNs, proxies, or mobile carrier routing) and on the configured travel-time thresholds, both of which affect false-positive and false-negative rates. It is one input among broader velocity checks that monitor the frequency and pattern of recurring data points within defined time intervals.

Why it matters

Fraud that involves stolen credentials or compromised payment accounts often manifests as activity from locations inconsistent with the legitimate account holder's normal behavior. Geo-velocity checks give risk teams a way to surface this pattern by asking a simple but revealing question: could the same person plausibly have been in both places within the observed time window? When the answer is no, the event warrants closer scrutiny. This makes geo-velocity a useful contributor to identifying account takeover and unauthorized access attempts, particularly in card-not-present and login contexts where physical possession of a card or device cannot be assumed.

Because geo-velocity is an identity-risk signal rather than a standalone control, its value comes from feeding adaptive or risk-based authentication decisions rather than from blocking activity outright. Treating a single geo-velocity violation as conclusive proof of fraud can harm legitimate users, since location inference and travel-time thresholds are imperfect. The signal is most effective when combined with other velocity checks and risk inputs, so that a suspicious travel pattern raises the assurance required to proceed rather than automatically denying a genuine customer.

The practical limitations are significant and should shape how teams deploy the check. IP geolocation can be distorted by VPNs, proxies, and mobile carrier routing, all of which can make a legitimate user appear to be somewhere they are not, producing false positives. Conversely, an attacker who deliberately routes traffic to appear near the victim can evade the check, producing false negatives. Configured travel-time thresholds also directly affect these error rates. For these reasons, geo-velocity should be understood as one input that helps reduce risk, not a control that prevents fraud on its own.

Who it's relevant to

Fraud analysts and merchant risk teams
Fraud and risk teams can use geo-velocity as one signal for detecting account takeover and unauthorized access, especially in card-not-present and login-based flows. They should weigh it alongside other velocity checks and risk inputs, and account for false positives caused by VPNs, proxies, or mobile carrier routing, and false negatives from attackers who mask their true location.
Identity and authentication engineers
Engineers building adaptive or risk-based authentication can incorporate geo-velocity as an identity-risk signal that raises or lowers required assurance rather than blocking outright. Tuning travel-time thresholds and choosing reliable location inference methods directly affects the balance between false positives and false negatives.
Payment processors and acquirers
Processors and acquirers evaluating velocity-based fraud controls can consider geo-velocity as part of the broader family of velocity checks that monitor the frequency and pattern of recurring data points within defined time intervals. It is one input among many and does not, on its own, eliminate fraud.

Inside Geo-Velocity Checks

Geo-Location Derivation
The process of estimating a transaction's or login's physical origin, commonly from IP address geolocation, device signals, or billing/shipping data. Geolocation is an inference rather than a precise measurement, and accuracy varies by data source, region, and connection type.
Velocity Component
The rate or timing dimension of the check, comparing the time elapsed between two events against the distance between their derived locations to assess whether the movement is physically plausible.
Impossible-Travel Logic
A rule that flags scenarios where the geographic distance between two events could not be covered in the elapsed time, suggesting the events may not originate from the same individual and may indicate account takeover or credential misuse.
Baseline and Thresholds
Configurable parameters defining acceptable travel speeds, time windows, and distance tolerances, tuned to balance detection sensitivity against false positives. Thresholds may vary by risk appetite and customer population.
Signal Context
Supporting attributes such as device fingerprint, known-good locations, VPN or proxy indicators, and historical behavior that help interpret a velocity anomaly rather than relying on distance and time alone.
Scope Boundaries
Geo-velocity is typically applied to card-not-present flows, account logins, or authorization decisioning as one input among many. It is a detection heuristic and is not itself a PCI DSS control requirement, though it may support broader monitoring and authentication objectives.

Common questions

Answers to the questions practitioners most commonly ask about Geo-Velocity Checks.

Does a geo-velocity check prevent card fraud on its own?
No. Geo-velocity checks are intended to help detect improbable travel patterns, such as transactions from widely separated locations in a time window too short to physically travel between them. They may flag suspicious activity, but they do not prevent fraud and are best used as one signal among many. On their own they produce both false positives (legitimate users behind VPNs, mobile carrier gateways, or corporate proxies) and false negatives (fraud conducted from the same region as the legitimate cardholder). They address neither authentication of the party nor validation of the payment instrument, so they should be combined with controls such as multi-factor authentication, 3-D Secure, and broader fraud scoring.
Is geo-velocity the same as simply blocking transactions from certain countries?
No. Geo-location blocking or allow-listing evaluates a single location against a static policy. Geo-velocity instead compares two or more location and timestamp data points to assess whether the implied movement between them is physically plausible. The two techniques answer different questions: one asks 'is this location permitted?' and the other asks 'is this sequence of locations consistent with a real person or device over time?' They can be used together, but they are distinct controls with different data requirements and different failure modes.
What data inputs does a geo-velocity check typically rely on?
Implementations commonly derive location from signals such as IP-based geolocation, device or mobile network data, and, where applicable, billing or shipping geography, each paired with an event timestamp. The reliability of the check depends heavily on the accuracy and freshness of these inputs. IP geolocation in particular can be imprecise or deliberately obscured by VPNs, proxies, and mobile carrier NAT, so teams should document the source of each signal and its known limitations rather than treating any single input as authoritative.
How should thresholds for implausible travel be set and tuned?
Thresholds are typically expressed as an implied speed or distance-over-time that would be physically impossible or highly improbable. Because tighter thresholds increase false positives and looser thresholds increase false negatives, tuning is a trade-off that should be validated against your own transaction population and revisited over time. Consider segmenting by channel and customer behavior, and pair the rule with a review or step-up path rather than an automatic decline, since legitimate users can trigger the rule through routine network conditions.
How does a geo-velocity check fit alongside other fraud and authentication controls?
Treat it as a contributing signal within a layered strategy rather than a standalone decision point. A geo-velocity flag can raise a risk score that then routes a transaction to step-up authentication, such as multi-factor authentication or a 3-D Secure challenge, or to manual review. It complements but does not replace controls that address different risks, and it does not verify the payment credential or authenticate the cardholder by itself. The specific combination should reflect your risk appetite and the fraud types you are targeting.
What are the data handling and scope considerations when logging geo-velocity signals?
Geo-velocity relies on location and timestamp data, and its logs may be correlated with account or transaction identifiers, so treat the associated records under your organization's data protection and retention policies. If these signals are stored alongside cardholder data or within the cardholder data environment, that storage may fall within PCI DSS scope; confirm the applicable requirements against the current published standard rather than assuming specific requirement numbers. Note also that geo-velocity inputs such as IP or device data are not payment authentication data and should not be conflated with sensitive authentication data, which must not be stored after authorization.

Common misconceptions

Geo-velocity checks accurately pinpoint where a user physically is.
The derived location is an estimate, most often from IP geolocation, and can be inaccurate or deliberately obscured. VPNs, proxies, mobile carrier NAT, and corporate egress points can place a genuine user far from their true location, so a flagged anomaly is a signal to investigate, not proof of fraud.
An impossible-travel flag means the transaction is fraudulent and should be blocked.
Geo-velocity is a heuristic that produces both false positives and false negatives. Legitimate scenarios (traveling users, shared accounts, roaming, network routing) can trigger flags, while a fraudster reusing a nearby location may pass. It is intended to help prioritize review or step-up authentication rather than to make a standalone block decision.
Deploying geo-velocity satisfies strong customer authentication or eliminates account takeover.
Geo-velocity is a risk-detection signal, not an authentication factor. It differs from multi-factor authentication, 3-D Secure, and strong customer authentication, which address authentication at defined points in a transaction. Geo-velocity may support risk-based decisioning but does not by itself authenticate a user or prevent account takeover.

Best practices

Treat geo-velocity output as one risk signal to be combined with device intelligence, behavioral history, and other indicators, rather than as a standalone accept-or-decline decision.
Account for VPNs, proxies, corporate egress, and mobile carrier NAT in your logic, and maintain allowlists or context for known-good sources to reduce false positives.
Use anomalies to trigger proportionate responses such as step-up authentication or manual review instead of automatic blocking, and measure the false-positive and false-negative trade-off of your thresholds.
Tune baselines and travel-speed thresholds to your specific customer population and risk appetite, and revisit them regularly as travel patterns and network conditions change.
Validate geolocation data quality against your chosen source and understand its regional accuracy limitations before relying on the results for higher-impact decisions.
Ensure that any cardholder data or authentication data feeding these checks is handled under appropriate controls, remembering that sensitive authentication data must not be stored after authorization even when encrypted.