GeoComply vs Xpoint: Selecting a Geolocation Vendor for US iGaming Compliance

Every session on a US-regulated iGaming or sports betting platform begins with a question a player never sees answered: does this device’s location meet the requirements of the state in which the operator is licensed? That question is resolved not by the operator’s platform, but by an independent geolocation service: a vendor approved by the relevant state regulator, certified against the applicable technical standard, and capable of making a legally defensible location determination in real time. Choosing the wrong vendor, or choosing the right vendor without understanding its integration requirements and fallback behaviour, creates a compliance exposure that no amount of responsible gambling tooling or AML monitoring can remedy after the fact.

Why Geolocation Is a Regulatory Requirement, Not a Product Feature

US iGaming operators frequently treat geolocation as a product layer, something the platform team integrates and the compliance team checks off. That framing understates the legal weight of the obligation. Under the state-based regulatory model that governs online gambling in New Jersey, Pennsylvania, Michigan, and every other regulated US jurisdiction, an operator that accepts a wager from a player physically located outside the state has committed a regulatory violation regardless of the player’s account registration state, regardless of their identity documents, and regardless of whether the platform’s own systems showed a passing result. The violation is the accepted wager, and the geolocation system is the last line of defence.

State regulators treat geolocation as a non-negotiable foundational control, not a configurable option, as reflected in regulatory guidance and enforcement actions across licensed US markets.

What the Technical Standards Actually Require

GLI-19: Standards for Interactive Gaming Systems (v3.0) and GLI-33: Standards for Event Wagering Systems (v1.1) are the two primary technical standards against which US regulated geolocation implementations are evaluated. Both are published by Gaming Laboratories International and are adopted, in whole or with jurisdiction-specific additions, by state regulators across the licensed US market.

The geolocation architecture mandated by GLI-19 section 2.7 and GLI-33 section 2.7 is substantially identical across both standards and rests on several non-negotiable elements.

Check frequency. Under both GLI-19 (section 2.7.4) and GLI-33, each player must pass a location check prior to initiating the first game or completing the first wager after logging in on a specific remote device. Subsequent checks must occur prior to completing wagers after a period of 30 minutes since the previous check, or as otherwise specified by the regulatory body. States may, and several do, impose shorter re-check intervals or per-wager checking requirements.

Confidence radius. GLI-19 section 2.7.4(b) requires that a geolocation method provide a player’s physical location and an associated confidence radius, and that the confidence radius be entirely located within the permitted boundary. A result where the confidence radius straddles a state border is, by definition, a failed check. The vendor’s boundary polygon implementation determines whether border-adjacent players are systematically blocked or systematically passed, operators near state boundaries need to verify the vendor’s polygon accuracy and buffer zone configuration.

Multi-source data fusion. Both standards require that accurate location data sources, Wi-Fi, GSM, and GPS among them, be used to confirm the player’s location. IP address alone is expressly insufficient. Where the remote device’s only available data source is an IP address, the standards permit the location data of a registered mobile device to be used as a supporting source, but only under specific conditions: the remote device and the mobile device must be determined to be near one another, and carrier-based data may only be used if permitted by the regulatory body.

Anti-spoofing controls. GLI-33 section 2.7.2 is explicit. The location service must detect and block fake location applications, virtual machines, and remote desktop programs prior to completing each wager. It must examine the IP address upon each device connection to ensure a known VPN or proxy service is not in use. It must detect and block devices indicating system-level tampering, rooting and jailbreaking are named examples, and must prevent Man-in-the-Middle attacks. The standard also requires monitoring and prevention of wagers placed by a single player account from geographically inconsistent locations that would be impossible to travel between in the reported time.

“Modern geolocation technology is specifically designed to detect VPNs, proxies, remote desktop tools and other forms of location manipulation. The bigger issue is that illegal operators often choose not to deploy these controls.”, Elizabeth Cronan, VP Government Affairs, GeoComply (iGamingBusiness, 2026)

Location service provider audit. GLI-19 section C.5.1 imposes an obligation that compliance teams often miss: the operator, or a third-party location service provider, shall undergo a specific audit as required by the regulatory body to assess and measure its continued ability to detect and mitigate existing and emerging location fraud risks. This audit obligation sits on the vendor, not merely on the operator’s integration of the vendor. A vendor that holds a state approval but has not recently undergone, or cannot produce documentation of, its C.5.1 audit cycle creates a residual compliance risk for any operator relying on it.

How GeoComply Meets These Requirements

GeoComply is the established incumbent in the US regulated market. The company’s GeoGuard product combines device-level software with server-side IP intelligence to deliver a multi-layer determination covering GPS, Wi-Fi triangulation, GSM cell data, and IP geolocation. Its fraud detection layer maintains closed-source databases of known VPN providers, proxy services, virtual machine signatures, and fake GPS applications, updated on a rolling basis in line with GLI-33 section A.8.3(d)(i), which requires that such databases be frequently updated and periodically tested for accuracy.

GeoComply has approval across New Jersey (DGE), Pennsylvania (PGCB), Michigan (MGCB), Indiana, Iowa, Colorado, Tennessee, and numerous other regulated sports betting and iGaming states. Its approval footprint is the widest of any vendor currently active in the US market, which matters practically: for operators seeking multi-state registration without managing separate vendor relationships, a single GeoComply contract substantially reduces the procurement and integration overhead.

The vendor’s integration model relies on a lightweight SDK deployed inside the operator’s native app (iOS and Android) or browser-based client. The SDK handles the actual device-level data collection, GPS signal, Wi-Fi scanning, and device integrity checks, and transmits that data to GeoComply’s servers for adjudication. The result returns to the operator’s platform as a pass, a fail, or a troubleshoot, the last being a result requiring player action such as enabling location permissions. The operator’s platform must be configured to act on each outcome correctly: pass allows session or wager progression, fail triggers a denial, troubleshoot surfaces a guidance prompt.

On latency, GeoComply’s server-side adjudication model introduces a network round-trip into every location check. For login checks and session-establishment verifications, this latency, typically sub-second in well-connected environments, is tolerable. For live in-play wagering, where the window between event occurrence and line movement can be measured in milliseconds, even a modest location check delay can create exposure if the check is performed synchronously on the critical path of wager placement. Operators running high-volume in-play books should verify whether their GeoComply integration performs the check asynchronously at session establishment or synchronously at wager submission, and should understand the fallback logic applied when a check times out.

How Xpoint Differs

Xpoint entered the US market as a direct competitor to GeoComply, positioning its technology primarily on integration simplicity and latency performance. The vendor’s architecture places a heavier emphasis on on-device computation, reducing the reliance on a server-side round-trip for the initial determination. In markets where Xpoint holds regulatory approval, this architecture can produce a faster time-to-determination, which matters most in the sports betting context where GLI-33’s per-wager check cadence is the operative standard.

Xpoint’s approval footprint is narrower than GeoComply’s, though it has expanded since its initial US market entry. Compliance teams must verify current state-by-state approvals directly with Xpoint and the relevant state regulator before incorporating Xpoint into a multi-state platform architecture. A vendor approval in New Jersey does not transfer to Pennsylvania, each state regulator conducts its own review, and approval lists are updated on timelines that differ by jurisdiction. Operators who discover mid-integration that their preferred vendor lacks approval in a target state face the prospect of a parallel vendor integration or a delayed market entry, both of which are preventable with earlier due diligence.

Xpoint’s SDK approach is, in practice, lighter-weight than GeoComply’s in certain implementation scenarios, which has attracted operators and B2B platform providers seeking to minimise the compliance footprint of third-party SDKs inside their apps. On iOS and Android, each additional SDK introduces dependency management complexity, potential conflicts with other libraries, and app review sensitivity. Operators with mature mobile stacks who have already rationalised their SDK footprint may find Xpoint’s integration profile easier to manage. This is an engineering and product consideration rather than a compliance one, and it does not affect the operator’s regulatory obligations under GLI-19 or GLI-33.

What Does Latency at Bet Actually Mean for Compliance?

GLI-19 section 2.7.4 and GLI-33’s equivalent provision require a location check prior to completing the first wager after login, and then at 30-minute intervals or as specified by the regulator. Neither standard prescribes a maximum latency budget for the check itself. The regulatory obligation is that the check occurs and that a failed result causes the wager to be rejected. Whether the check takes 200 milliseconds or 2 seconds to return a result is a product-quality matter, up to the point where the check’s duration creates a window in which a wager is accepted before the check result is received.

That failure mode, accepting a wager before the location result is confirmed, is the specific configuration error that creates a compliance violation. If the platform sends the wager to the bet engine on the assumption the check will pass, and the check subsequently returns a fail, the wager has already been accepted on an unverified location. The correct implementation is to hold the wager pending the check result, or to perform the check asynchronously against a session-level approval that is refreshed independently of the wager flow. The latter approach reduces per-wager latency perception but requires the operator to manage the session state carefully.

Under GLI-19 v3.0 section 2.7.4(a)(i): “If the location check indicates the player is outside the permitted boundary or cannot successfully locate the player, the wager shall be rejected, and the player shall be notified of this.” The standard does not permit a default-allow on a failed or timed-out check.

In-play betting amplifies this question. According to industry data, in-play wagers have become a significant portion of sportsbook handle. At scale, a geolocation check on every in-play wager from every active bettor represents a significant API call volume. Both GeoComply and Xpoint offer session-based caching mechanisms that allow a recent passing check to satisfy the per-wager requirement without a new network call, provided the session duration has not exceeded the regulatory interval. Operators should verify that their vendor’s caching logic aligns precisely with the re-check interval required in each state, since a cached result from a check performed 28 minutes ago satisfies a 30-minute interval requirement but may not satisfy a state that has imposed a shorter cadence.

The State Regulator Approval Process and What It Covers

State regulators in New Jersey, Pennsylvania, Michigan, and other US iGaming jurisdictions do not simply add vendors to an approved list without scrutiny. The approval process typically involves the vendor submitting its technical documentation, undergoing testing by an independent testing laboratory (ITL) against the applicable GLI standard, and demonstrating that its detection capabilities meet or exceed the requirements of sections 2.7 and C.5 of GLI-19, or the equivalent in GLI-33. The ITL’s role is analogous to its role in certifying the operator’s gaming system: it evaluates the vendor’s implementation against the standard and reports to the regulator.

A vendor’s regulatory approval is an approval of a specific version of its technology. When GeoComply or Xpoint updates its detection databases, its SDK, or its server-side logic, the question of whether those updates constitute a material change requiring re-approval is a regulator-specific determination. Some states require notification of material changes, others require re-testing. GLI-33 section A.8.3(d)(ii) requires that the detection service undergo frequent updates to maintain cutting-edge data collection, device compatibility, and fraud prevention capabilities, meaning static, infrequently updated implementations are themselves non-compliant.

Comparing the Two Vendors: A Practical Framework

Dimension	GeoComply	Xpoint
US state approval footprint	Widest current footprint (NJ, PA, MI, IN, CO, TN, IA, and others)	Narrower, verify current approvals per state before contracting
Detection architecture	Device SDK + server-side adjudication	Emphasis on on-device computation, reduced server round-trip
VPN/proxy blocking	Closed-source, rolling-update IP intelligence database	Comparable closed-source database, verify update cadence contractually
Latency profile at login	Sub-second in typical environments, network-dependent	Can be faster for initial check due to on-device pre-processing
Latency profile at wager	Session-cached results reduce per-wager overhead	Session-cached results, verify interval alignment per state
SDK integration weight	Established SDK, requires standard mobile integration resources	Marketed as lighter, validate against own app architecture
GLI-19 C.5.1 audit documentation	Mature audit trail, request most recent audit report	Newer to market, request current audit status before contracting
Multi-state single contract	Yes, for approved states	Depends on current approval list, confirm per target state

Fallback Rules: The Compliance Detail Most Teams Miss

Both GLI-19 and GLI-33 are explicit that a failed or indeterminate location result must result in wager rejection. GLI-19 section 2.7.4(a)(i) states that if the location check indicates the player is outside the permitted boundary, or cannot successfully locate the player, the wager shall be rejected and the player shall be notified. There is no provision for a default-allow on a timed-out or indeterminate result.

Fallback logic is where platform integrations most commonly diverge from this requirement. Three failure modes recur in practice. A check that times out due to network degradation is treated as a pass by the platform, on the assumption that the player is probably inside the boundary. A check that returns an “unable to determine” result from the vendor is not mapped to the rejected state in the platform’s logic. A check performed on a web session does not inherit the result from a recently completed native app check, causing the web platform to request a new check that the device cannot service due to browser permission restrictions.

Each of these scenarios represents a live compliance gap. Operators should conduct end-to-end fallback testing, simulating check timeouts, indeterminate results, and permission-denied scenarios, against their specific vendor integration before go-live, and should document the expected platform behaviour in their internal control procedures. The AGCO’s Registrar’s Standards for Internet Gaming in Ontario impose a similar discipline on operators registered there: location checks must be performed on every login, and the outcome must be logged regardless of the result. That logging requirement, common across regulated markets, means that fallback events are auditable, and regulators can identify patterns of defaulted-pass outcomes during an audit.

Geolocation at the Jurisdictional Frontier: Sweepstakes, Prediction Markets, and the SAFE Bet Act

The regulatory status of geolocation as a non-negotiable requirement is being tested from two directions simultaneously. Sweepstakes casino operators and prediction market platforms have advanced arguments that geolocation requirements are either not applicable to their product category or are technically infeasible at the scale they operate. Multiple state attorneys general have rejected the feasibility argument and are pursuing enforcement on the basis that operating without geolocation controls in a state that requires them constitutes unlicensed gambling activity.

The SAFE Bet Act, reintroduced at the federal level, reflects a legislative view that state-level geolocation requirements may need federal reinforcement to maintain their effectiveness. Whether that legislation advances or not, its introduction signals that the regulatory community views geolocation as a core pillar of the US digital gambling framework, not an implementation detail that individual operators can opt out of by choosing a non-standard product category.

Compliance teams at operators active in, or considering entry into, the sweepstakes or prediction market verticals should take specific legal advice on whether their jurisdiction-specific obligations include geolocation. As a matter of verified regulatory requirement, licensed US sportsbook and iGaming operators must deploy a state-approved geolocation service. The question for adjacent product categories is a live legal and regulatory matter, not a settled one, and operators should not rely on vendor representations about regulatory applicability without independent legal analysis.

For US-regulated iGaming operators already subject to state licensing, the compliance framework is settled. The standards are GLI-19 and GLI-33. The vendor must be approved by each state regulator. The technical implementation must satisfy the confidence radius, multi-source fusion, anti-spoofing, and fallback-rejection requirements. The vendor’s audit documentation under GLI-19 section C.5.1 must be producible on demand. Operators building a US multi-state presence should evaluate GeoComply and Xpoint, and any other approved vendor, against all of these dimensions before contracting, not after. Qualified legal and technical counsel should be engaged to verify jurisdiction-specific approval status and integration requirements before any go-live commitment is made.

For a broader view of how geolocation obligations fit within a full GLI certification programme, the GLI Certification hub covers the end-to-end certification process, jurisdiction acceptance patterns, and the relationship between technical standards and regulatory approval across multiple markets.

Operators already registered in Ontario under the AGCO’s Registrar’s Standards for Internet Gaming will find that the geolocation obligations closely parallel the GLI framework: per-login location verification is mandatory, the check must be performed on every session, and the result must be logged. Ontario-registered operators expanding into US states will find the underlying discipline familiar, though the vendor approval lists differ by jurisdiction. A review of the AGCO compliance lessons documented after Ontario’s first three years of operation provides useful context on how regulators treat location-check logging during audit cycles.

Key Resources

GLI-19: Standards for Interactive Gaming Systems, Version 3.0, Gaming Laboratories International. Sections 2.7 (Location Requirements) and C.5 (Location Services) are the primary reference for iGaming geolocation obligations.

GLI-33: Standards for Event Wagering Systems, Version 1.1, Gaming Laboratories International. Sections 2.7 and A.8.3 govern geolocation in sports betting and event wagering systems.

AGCO Registrar’s Standards for Internet Gaming, Alcohol and Gaming Commission of Ontario. Establishes Ontario-specific per-login location verification requirements applicable to all registered operators.

Elizabeth Cronan, VP Government Affairs, GeoComply, Commentary in “The VPN Dilemma: A Regulatory Loophole or Gambling’s Red Herring?” iGamingBusiness, June 2026. Primary market participant perspective on VPN detection capabilities and the regulatory burden allocation between licensed and unlicensed operators.

Begin your vendor evaluation by requesting current state-by-state approval documentation directly from GeoComply and Xpoint, and cross-reference those approvals with your target jurisdictions’ regulatory bodies before initiating any procurement or integration process.