How Geolocation Works on Regulated Sports Betting Apps

In September 2019, a man attempted to place a bet on a DraftKings app from a motel parking lot outside Easton, Pennsylvania. The parking lot was roughly nine hundred feet east of the Delaware River, which at that point forms the New Jersey border. The app refused the transaction. It told him he was in Pennsylvania and that his New Jersey account was not authorized to place a bet from that location.

He was, in fact, in Pennsylvania. He also had a Pennsylvania account with the same operator, which he switched to and used successfully. He would later file a complaint with DraftKings customer service about the inconvenience of account switching. I mention this case because it illustrates, cleanly, how the system is supposed to work and does.

The Subject and the Stakes

The subject, for purposes of this discussion, is the geolocation compliance stack that every regulated sports betting app in the United States runs on. The stakes are simple. State gaming regulators require that wagers be accepted only from within state lines. A failure of the geolocation system is not a minor technical bug. It is a regulatory violation that can cost the operator its licence. I have interviewed the geolocation vendors and their customers in the course of other work, and the system has been refined substantially between 2018, when the modern regulated US market opened in New Jersey, and now.

The Method, Step by Step

The standard vendor in this space is GeoComply, a Vancouver-based firm that holds contracts with more than ninety percent of licensed operators in the North American market. A secondary vendor, Xpoint, serves a smaller share. The method, as implemented by GeoComply and endorsed by most state gaming commissions, layers several location signals:

• GPS, drawn from the device's satellite receiver when available
• Wi-Fi triangulation, which measures signal strength and MAC addresses of nearby access points against a database of known locations
• Cellular tower triangulation, which performs the same trick against the cell network
• IP address lookup, which gives a coarse indication but is easily spoofed
• Device fingerprinting, which identifies the physical device and checks for VPN or emulator signatures
• An active scan for virtual machine environments, which indicates a user is attempting to falsify the endpoint

When a player opens the app and attempts to place a bet, the geolocation SDK inside the app runs a check against all of these signals. The check takes under two seconds. It returns a confidence score and a location. If the confidence is below a threshold set by the operator, or if the location is outside the authorized jurisdiction, the bet is blocked.

The 900 Feet Problem

The Easton case is instructive because nine hundred feet is inside the margin of error for consumer GPS. A raw GPS reading alone might have placed the device either side of the river. The geolocation stack does not rely on raw GPS. It cross-references the GPS reading against Wi-Fi access points in the area. If the Wi-Fi networks visible to the device are registered, in the vendor's database, as associated with Pennsylvania addresses, the location is snapped to Pennsylvania regardless of what the GPS said.

This is why crossing a state line physically and switching account jurisdictions is rarely a matter of guesswork. The system has a reliable picture of which state's infrastructure the device is sitting in, because the infrastructure itself announces the jurisdiction. The motel in Easton had a Pennsylvania Wi-Fi router, a Pennsylvania cellular tower, and a Pennsylvania ISP on the fixed-line connection. The device was, in every practical sense, in Pennsylvania.

The Spoof Attempts and the Response

I have read the internal case files on several attempted geolocation spoofing efforts. The common patterns include:

• VPN routing to an in-state server, which changes the IP but not the Wi-Fi or GPS signal
• Fake GPS apps, which feed a fabricated coordinate to the operating system
• Relocating a SIM card and using a cellular hotspot
• Using a mobile emulator on a desktop machine to fake the device type

Each of these is caught by the geolocation stack, because no single signal is trusted. The VPN catches out the IP but fails the Wi-Fi scan. The fake GPS app is detected by the SDK, which watches for the known signatures of GPS spoofing software. The SIM relocation works only if the physical device is also relocated, which defeats the purpose for the typical user. The emulator is caught by the device fingerprint.

The professionals I have seen successfully defeat a geolocation stack were usually corporate insiders, people with access to the operator's internal tools, not consumers. The consumer-facing defenses are, in my professional opinion, sound.

The Regulatory Backdrop

Each US state with legal sports betting runs its own approval of the geolocation vendor and sets its own confidence threshold. New Jersey, which served as the template through the Division of Gaming Enforcement's approval process in 2018, requires a minimum confidence level of high 90s percent before a bet may be accepted. Pennsylvania, Michigan, and Colorado followed with similar rules. Tribal-state compacts, in jurisdictions like Arizona and Connecticut, layer additional requirements reflecting the sovereign status of the tribe.

What the Case Tells Us

The Easton incident tells us the system works as designed. A bettor in the wrong state was correctly identified and blocked. The inconvenience to the bettor was real. The inconvenience was also, precisely, the point.

The regulatory system is an engineered friction. It is meant to keep bets inside state lines. In September 2019, at a motel parking lot in Easton, Pennsylvania, it did exactly that. Nothing spectacular about it. That is what a well-designed compliance stack looks like when it is running correctly.