iGaming regulations in Ontario.
Ontario is North America’s fastest-maturing regulated iGaming market. Here’s how AGCO and iGaming Ontario registration works.
Online gambling in Ontario is regulated by the Alcohol and Gaming Commission of Ontario (AGCO), with operators contracting through iGaming Ontario (iGO). Operators must register, meet technical and responsible-gambling standards, and certify their platform.
North America’s breakout market
Ontario’s regulated model has made it the template for North American iGaming. We build platforms to AGCO standard for operators entering the market. See the wider regulations guide.
How Ontario works
Operators register with the AGCO and contract with iGaming Ontario (iGO). The model emphasises responsible gambling, data reporting and certified technical standards.
What you need
- AGCO registration and iGO operating agreement
- Certified KYC and AML
- Responsible-gambling controls
- Technical certification and reporting
Ontario is not a licence. It’s a registration plus a contract.
This is the part that catches teams who have already shipped into the UK or Malta. There, you apply to one body, it grants a licence, you trade. Ontario splits the job across two bodies, and you need both halves before a single bet settles.
The Alcohol and Gaming Commission of Ontario (AGCO) is the regulator. It registers operators and suppliers, and it publishes the rules your platform is measured against — the Registrar’s Standards for Internet Gaming.
iGaming Ontario (iGO) is the commercial counterparty. iGO states its mandate as “to conduct and manage igaming in Ontario provided through private igaming Operators”, and says it executes Operating Agreements with private operators “once they have been registered by the AGCO”. Registration first, contract second. The two are sequential, not parallel.
The practical consequence is easy to miss and hard to unwind. The province conducts and manages the gambling; you operate it on the province’s behalf under an agreement. That is a different legal posture from holding your own licence, and it surfaces in the build — in what you report, on what cadence, and in how much of your commercial model is set by a contract rather than chosen by you. Compare that with the UK’s single-licence model or Malta’s before you assume your existing compliance design ports across.
AGCO or iGO?
Two bodies, two relationships, one order of operations.
| Question | AGCO — the regulator | iGaming Ontario — the counterparty |
|---|---|---|
| What it does | Registers operators and gaming-related suppliers | Conducts and manages igaming through private operators |
| What you get from it | Registration under the Gaming Control Act, 1992 | An Operating Agreement |
| Order of play | First — you register | Second — only once the AGCO has registered you |
| Sets the technical rules | Yes — the Registrar’s Standards for Internet Gaming | No — commercial and contractual terms |
| Reaches suppliers | Yes | No — the Operating Agreement is for operators |
| Who owns it internally | Compliance, security, platform engineering | Finance, commercial, reporting |
If you supply the software, registration can reach you
Most Ontario explainers are written for operators. If you are the one building or selling the platform, read this part twice.
The AGCO’s Internet Gaming Operator Application Guide describes gaming-related suppliers as entities that “manufacture, provide, install, test, maintain or repair gaming equipment or who provide consulting or similar services directly related to the playing of a lottery scheme or the operation of a gaming site”. The same guide gives examples — and the first it names is third-party internet gaming platform providers, alongside independent testing laboratories.
The line the AGCO draws is control. Unlike an operator, a supplier has no “measure of control or role in relation to operating the gaming site as a whole”. So you can sit deep in the critical path — running the wallet, the RNG integration, the bonus engine — and still be a supplier rather than an operator. The test is authority over the site, not how important your code is to it.
Two standards make this concrete. Standard 1.18 requires operators and gaming-related suppliers to contract only with reputable suppliers, which pushes diligence down your subcontractor chain. Standard 1.22 requires them to cease all unregulated activities where carrying out those same activities inside Ontario’s regulated scheme would require registration under the Gaming Control Act. In plain terms: you cannot serve the grey market with one hand and Ontario with the other and expect the two to stay in separate boxes.
This reframes the build-or-buy question. Licence a third-party platform and that vendor’s registration status is now on your critical path — their supplier problem becomes your launch problem, on their timetable. Own the platform outright and your registration surface is yours to control. In a registration market that is not an abstract benefit; it is the difference between one entity to answer for and a chain of them you cannot audit.
The constraint isn’t where the data lives
Worth being blunt, because it gets repeated wrongly: the Registrar’s Standards for Internet Gaming do not mandate that your servers or player records sit physically in Canada. There is no data-localisation standard in the published text. If someone tells you Ontario is a data-residency market, ask them for the standard number.
What the Standards impose instead is retention and access — a different engineering problem. Standard 1.13 requires operators to “make available any data, information and documents requested by the Registrar”. Standard 1.09 requires information and logs related to compliance to be retained for a minimum of three years unless otherwise stated. Standard 1.13 also requires reporting of incidents and of non-compliance in line with an established notification matrix.
Read together, the design brief is clear. You are not being asked to move a data centre. You are being asked to produce a specific, complete, three-year-deep answer to a regulator’s question on demand. That means the event log has to be immutable, queryable and complete at the time you write it — not reconstructed afterwards from application logs and best guesses. Teams that treat the ledger as an append-only source of truth from sprint one clear this without drama. Teams that bolt a reporting database on before certification find out their history has holes in it, and by then the holes are permanent.
Geo-fencing to a province, not a country
Standard 3.02 states that games on gaming sites “shall be provided only within Ontario”, unless conducted in conjunction with the government of another province. That one sentence is the most under-costed line in an Ontario build.
Country-level IP lookup — the thing most stacks already do — does not satisfy it. Ontario is a sub-national boundary inside a country whose other provinces run their own regimes; see where iGaming is legal by market for how fragmented that picture is. Standard 3.02 requires mechanisms to detect and dynamically monitor the location of a player attempting to play, to block unverified attempts, and to re-check location at reasonable intervals during play — not only at login. It also requires mechanisms to detect software, virtualisation and other programs capable of circumventing location detection.
Three things follow for the platform. Location becomes a session-lifetime concern with a re-check loop, so it needs a latency budget and a defined failure mode — what happens to an in-flight bet when a check fails mid-session is a product decision you must make on purpose. VPN and virtualisation detection becomes a first-class service in the login and wager path, not a fraud-team afterthought. And because you may later run Ontario alongside other provinces, player pools, wallets and liability need to be segregated by province in the first schema. Partitioning that later, under a second market’s deadline, is how infrastructure debt becomes a launch delay.
What Ontario forces into the build
Standard numbers reflect the AGCO’s published text at the time of writing — confirm the current version.
| Ontario requirement | What it forces in the platform | Where it’s enforced |
|---|---|---|
| Play permitted only within Ontario (Std 3.02) | Province-level geo-fencing with in-session re-checks and a defined fail state | Session service · wager API |
| Detect circumvention tools (Std 3.02) | VPN, proxy and virtualisation detection in the login and wager path | Edge · risk service |
| Centralised Self-Exclusion Program (Std 2.14.1) | External exclusion check gating registration and account access — not just marketing suppression | Registration · auth |
| Only eligible individuals hold accounts (Std 3.01) | Identity gate before play, tied to the account lifecycle | Onboarding · account service |
| Inducements not publicly advertised (Std 2.05) | Consent state on the player record that the bonus engine reads before any send | CRM · bonus engine |
| Responsible for third parties (Std 1.19) | Affiliate attribution you can audit and switch off per partner | Affiliate service |
| Produce records on request (Std 1.13) | Immutable, queryable event log written correctly the first time | Ledger · reporting |
| Retain compliance logs ≥ 3 years (Std 1.09) | Retention policy set at write time, not at archival | Data platform |
Your bonus engine is a regulated surface
In most markets, bonus rules constrain the marketing team. In Ontario they reach into the product.
Ontario does not ban inducements, bonuses and credits. It bans advertising them in public. Under Standard 2.05, advertising and marketing materials that communicate gambling inducements, bonuses and credits are prohibited except on an operator’s gaming site — and, per the AGCO’s published guidance, through direct marketing to players who have actively consented to receive it, with a way to withdraw that consent at any time.
Engineer that honestly and it stops being a policy PDF and becomes three system requirements:
- Consent is a gate, not a flag. Active, withdrawable opt-in state lives on the player record, and every outbound message carrying an offer reads it at send time. A CRM that treats consent as a marketing preference will eventually send a promotion to someone who withdrew it.
- Offer terms travel with the offer. Material conditions and limitations must be disclosed at first presentation, and an offer may not be described as free where the player has to risk or lose their own money. So the bonus engine has to carry structured terms as data, not as ad copy written somewhere else.
- Affiliates sit inside your blast radius. Standard 1.19 makes operators responsible for the actions of third parties they contract with for any aspect of their Ontario gaming business.
That last point has teeth. The AGCO’s own newsroom records $110,000 in penalties issued to BetMGM Canada Inc. after marketing affiliates offered cash to induce new customer sign-ups, cited under Standard 1.19 and Standard 2.05. The operator carried it, not the affiliate. If your affiliate integration cannot attribute a sign-up to a specific partner and campaign, and cannot disable that partner the same day, you are holding an unpriced risk on someone else’s behaviour.
This is why we build KYC, AML and responsible-gambling controls as core services rather than modules bought late. A bonus engine that reads consent, a CRM that respects it, and an affiliate layer you can audit are cheap in sprint one and expensive the week before certification.
Is Ontario worth a custom build?
Honest answer: not always, and rarely first.
A white-label or licensed platform whose vendor is already an AGCO-registered gaming-related supplier will get you into Ontario faster and cheaper than a custom build will. If Ontario is your only market and you are still testing whether the economics work, that is a rational first move and we will say so.
A custom, owned platform earns its cost when the maths changes. When you run Ontario alongside other provinces or markets and provincial segregation becomes permanent architecture rather than a one-off. When your volume makes a revenue share more expensive than engineers. When your product is the differentiator and you cannot ship it on another company’s roadmap. When you intend to sell the company, because owned IP is an asset on the balance sheet and a platform licence is a cost line on it. And in a registration market specifically: every vendor in your critical path is a registration dependency you do not control.
If that sounds like your position, see how we approach platform development, or the wider licensing picture across markets.
Engineering guidance, not legal advice. We are software engineers, not Ontario counsel. The Registrar’s Standards for Internet Gaming are amended from time to time, and the standards cited here reflect the AGCO’s published text at the time of writing. Confirm current requirements with the AGCO and iGaming Ontario, and take Ontario legal advice, before you commit to a registration route or a compliance design.
Frequently asked questions
Who regulates online gambling in Ontario?+
Is Ontario a good iGaming market?+
What does AGCO registration involve?+
Can you build an Ontario-compliant platform?+
What is the difference between the AGCO and iGaming Ontario?+
Do software suppliers need to register with the AGCO?+
Does Ontario require player data to be stored in Canada?+
Can we advertise bonuses and free bets in Ontario?+
Related solutions
Ready to launch your iGaming platform?
Tell us what you're building. We'll come back with a scope, a timeline and a fixed route to go-live — usually within one working day.
Briefs stay private. We never share project details.