When iGaming Ontario launched in April 2022, it became the largest regulated online gaming market in Canada — and one of the most significant new regulated markets to open anywhere in the English-speaking world in years. The Alcohol and Gaming Commission of Ontario (AGCO) built a regulatory framework that is detailed, technically specific, and actively enforced.
For operators entering the Ontario market, geolocation compliance is not optional and not simple. AGCO Standard 3.02 sets out requirements that go well beyond IP address checks or basic browser location prompts. It mandates dynamic, ongoing location monitoring, explicit detection of circumvention tools, and documented validation of controls. Many operators launching in Ontario underestimate the technical depth of what's required.
This article walks through exactly what Standard 3.02 requires, where operators commonly fall short, and what a compliant technical implementation looks like.
The Ontario Market: Scale and Stakes
Ontario has a population of approximately 15 million people and represents the largest single iGaming jurisdiction in Canada by a significant margin. Since launching in April 2022, iGaming Ontario (iGO) — a subsidiary of AGCO — has signed agreements with dozens of operators including global brands already familiar with regulated markets in New Jersey, Pennsylvania, the UK, and Malta.
The market is structured around operator agreements with iGO rather than individual game or software licenses. Operators sign a Revenue Sharing Agreement with iGO and are then bound by AGCO's Registrar's Standards for Internet Gaming. Those standards carry real enforcement weight — operators who fail an audit can lose their ability to operate.
AGCO Standard 3.02: What It Actually Says
Standard 3.02 — Player Location — is the core geolocation requirement in the AGCO Registrar's Standards for Internet Gaming. It is worth reading carefully because it is more technically specific than most operators expect.
Standard 3.02 — Key Requirements
- 1. Games shall be provided only within Ontario unless conducted in conjunction with another Canadian province.
- 2. Operators must implement mechanisms to detect and dynamically monitor the location of players attempting to access games.
- 3. Operators must block unverified attempts to play games — passive monitoring without enforcement is not compliant.
- 4. Subsequent location checks must occur at reasonable intervals that minimize the risk of play outside Ontario, with timing justified by the operator's risk assessment.
- 5. Operators must implement mechanisms to detect software and programs capable of circumventing location detection — specifically including VPNs, proxy servers, and virtualization software.
- 6. Operators must document and validate how their location verification controls have been implemented and tested for accuracy and effectiveness.
Points 2, 4, and 5 are where most operators run into compliance gaps. Each deserves detailed attention.
Where Operators Fall Short
Static verification at login only
Standard 3.02 explicitly requires dynamic monitoring — not a one-time check at session start. A player who crosses the Ontario border mid-session, or who activates a VPN after the initial location check, must be detected and blocked. Operators who verify once at login and rely on that for the duration of the session are not meeting the standard.
IP-only geolocation
IP address geolocation is trivially bypassed by VPNs and proxy servers — and Standard 3.02 specifically requires detection of those tools. An operator relying solely on IP-based location checks has both a geolocation gap and a circumvention detection gap simultaneously. IP geolocation may pass a first-look review but will not withstand a detailed audit.
No virtualization detection
The standard explicitly calls out virtualization software alongside VPNs and proxies. A player running a virtual machine with a spoofed location — or using a location-faking application — must be detected. Browser-based location verification has no access to the OS environment needed to detect these tools. A native desktop agent is the only reliable mechanism for virtualization and process-level detection.
What a Compliant Implementation Looks Like
Meeting Standard 3.02 in full requires a layered approach combining hardware-level signals, OS-level integrity checks, and network analysis. No single signal is sufficient on its own.
Hardware-Backed Location Verification
On mobile, GPS combined with WiFi BSSID triangulation and cell tower data produces accurate, tamper-resistant location signals. On desktop, WiFi BSSID scanning via a native agent provides comparable accuracy without GPS hardware. These signals are independent of the device's IP address and cannot be spoofed by a VPN or proxy — a user in Manitoba cannot fake a WiFi environment that places them in Toronto.
OS-Level VPN Detection
VPN tunnels create named network interfaces at the OS level — tun0, wg0, utun on macOS, WireGuard adapters on Windows, and equivalents on Linux. A native agent can enumerate these interfaces directly. On mobile, the VPN API exposes active tunnel state. Browser-based checks cannot access this information — only a native application can perform reliable VPN detection.
Virtual Machine and Emulator Detection
Virtual machines are detectable through hardware identifiers (DMI strings, hypervisor CPU flags, MAC address OUI prefixes), system calls (systemd-detect-virt on Linux), and process enumeration. A player running an Ubuntu VM inside VirtualBox to spoof location can be identified with high reliability through multiple independent signals. Emulated Android environments on desktop are similarly detectable.
Continuous Monitoring with Risk Scoring
The "subsequent location checks at reasonable intervals" requirement means verification cannot be a one-time event. A compliant implementation re-verifies location periodically throughout a session and flags anomalies — a sudden IP address change, a VPN interface appearing mid-session, or a location signal that conflicts with the original verified position. Each signal contributes to a risk score that operators can configure against their own threshold policy.
Audit Logging and Documented Validation
Standard 3.02 requires operators to document how their controls work and demonstrate they have been validated for accuracy. This means maintaining structured audit logs — timestamped records of each location verification event, the signals used, the risk score assigned, and the action taken. These logs must be available to AGCO on request and must demonstrate a coherent, defensible methodology.
The Desktop Compliance Gap in Ontario
Ontario's iGaming market is primarily accessed through web browsers on desktop and mobile, unlike the US market where native apps dominate. This creates a specific compliance challenge: browser-based verification cannot satisfy the virtualization detection requirement of Standard 3.02, and it cannot perform reliable VPN detection.
Operators who rely entirely on mobile SDKs and browser location APIs are leaving a compliance gap on desktop that is specifically called out in the standard. Desktop players represent a significant share of Ontario iGaming sessions — and the circumvention tools most commonly used by sophisticated bad actors (VMs, VPNs, location spoofers) are primarily desktop-based.
The Audit Risk
Standard 3.02 requires operators to provide documentation showing how their location verification controls have been validated for accuracy and effectiveness. An operator relying on IP geolocation and browser location APIs cannot credibly document that their controls detect VPNs and virtualization software — because they don't. This is a documented gap that will surface in any serious compliance audit.
How Peabody Addresses Standard 3.02
Peabody's compliance stack was built around exactly the requirements AGCO Standard 3.02 codifies — hardware-backed location signals, OS-level integrity checks, and structured audit logging. The platform supports Windows, Mac, iOS, Android, and Linux including Steam Deck.
WiFi BSSID Triangulation
Native desktop agents scan surrounding WiFi access points and submit BSSIDs to the Google Geolocation API for meter-accurate location verification independent of IP address. Available on Windows, Mac, and Linux.
OS-Level VPN Detection
Native agents enumerate all active network interfaces at the OS level, identifying VPN tunnel types (WireGuard, OpenVPN, IPSec, tun/tap) on Windows, Mac, and Linux. Mobile SDKs use platform VPN APIs for equivalent detection on iOS and Android.
Virtual Machine Detection
Multi-signal VM detection covering DMI hardware identifiers, CPU hypervisor flags, MAC address OUI prefixes, device tree analysis, and systemd-detect-virt. Detects VirtualBox, VMware, KVM, Hyper-V, Xen, and QEMU across x86-64 and ARM64 architectures.
Structured Audit Logs
Every verification event is logged with a full signal breakdown, risk score, and outcome. Logs are queryable and exportable — giving operators the documented validation evidence Standard 3.02 requires for audit purposes.
Serving Ontario iGaming Operators Today
Peabody is available to Ontario operators now — no vendor registration required. If you're evaluating geolocation compliance solutions for the Ontario market, we're ready to talk.