Ontario does not admit a game to its regulated igaming market because the game works. It admits a game that has been written down, described to the player, and certified. Three artefacts have to exist before a title can be offered for real money on an Ontario gaming site, and they answer three different questions: an internal specification that says what the game is, a player-facing disclosure that says what the player is committing to, and an independent certification that says both claims have been tested against the Registrar’s standards.
That structure matters most to the party that is not the operator: the studio that built the game, the platform that supplies it, or the aggregator distributing it into an Ontario client. Ontario’s rules are written as outcomes rather than a build checklist, and the Registrar is explicit that accountability can land on a supplier as well as on an operator. This article works through what the Registrar’s Standards for Internet Gaming actually require of a game and of the supplier behind it, and what the accompanying certification policy does to a release calendar.
Ontario regulates outcomes, not a build checklist
The Registrar’s Standards for Internet Gaming came into force on 4 April 2022, when Ontario’s regulated igaming market opened, and they are built on a deliberately indirect model. Under the Gaming Control Act, 1992 the Registrar sets risk-based standards, and the standards document states the intent plainly: the approach was designed to move regulation “from requiring registrants to comply with a specific set of rules or processes, which tend to be prescriptive in nature, towards the broader regulatory outcomes or objectives they are expected to achieve.”
For a supplier, that has two consequences that are easy to read past.
The first is that there is no line in the document that says “your build must contain X”. The document says what outcome has to hold, and leaves the mechanism to the registrant. A studio cannot satisfy it by shipping a feature where a competitor shipped the same feature; it has to be able to show that the outcome holds for its build.
The second is who is on the hook. The standards apply to OLG for its internet gaming site, to iGaming Ontario for its activities, and to registered internet gaming operators — and specific standards also apply to registered gaming-related suppliers. The document then adds the sentence that decides most commercial arguments: “Operators are expected to ensure that the Standards related to the operation of their gaming site are met, regardless of the entity that is carrying out the related activities. Depending on the circumstances, the Registrar may hold an Operator, a gaming-related supplier, or both, accountable for meeting a particular Standard.”
Read that as a supplier and the compliance question stops being the operator’s problem alone. The same section notes that the Registrar may direct any registered supplier to comply with additional standards and requirements, and may add terms specific to a registrant.
The specification the supplier has to be able to produce
The first artefact is a document, and it is not the marketing page. Standard 4.05 requires that “Game specifications must be documented that clearly indicate” five things:
- the objectives of the game;
- the wagers that may be made;
- how the game is operated and played;
- the odds of winning for each prize available to players;
- the advantage of the operator in relation to each wager.
Four of those five are ordinary engineering facts. The fifth — the operator’s advantage in relation to each wager — is the house edge stated as a per-wager property rather than as a headline percentage, and it is the point where the specification stops being a design document and becomes a regulatory one. A game with several bet modes, several stake levels or several prize tiers has one such figure per wager, not one per game. The math model and PAR sheet guide covers the evidence side of that work; Ontario’s contribution is that the specification itself is required to exist.
The specification sits on top of a wider record obligation. Standard 4.01 requires that “All gaming activities and financial transactions shall be conducted fairly and honestly, and must be independently verifiable”, and its requirements call for continuous independent monitoring and recording sufficient to verify adherence to the game rules, confirm outcomes, pay the prize to the proper person and confirm the accuracy of financial transactions, with continuous logs for critical gaming systems that track financial accounting and game state history.
Standard 4.02 then lists what the transaction and game-state records have to support, including “Capturing information needed to continue a partially complete game within a reasonably defined time” and “Tracking of game enabling, disabling and configuration changes”. Two later standards turn those records into a testable property: 4.14 requires mechanisms “to allow a game to be recreated up to and including the last communicated state to the player”, and 4.12 requires game outcomes to be recoverable, “where technically possible, so that player bets can be settled appropriately”.
That is the practical shape of the first artefact. A game that cannot be reconstructed from its own records cannot be defended, and the reconstruction has to reach the last state the player actually saw.
The disclosure the player must have before the first bet
The second artefact is the one a commissioning conversation usually forgets, because it is not part of the build: it is what the player reads. Standard 4.06 is unambiguous about the timing. “Prior to placing a bet or wager, the player shall be provided with sufficient information to make informed decisions about betting or wagering based on chances of winning, the way the game is played, and how prizes and payouts are made.”
Its first requirement describes how the material has to be surfaced: “Comprehensive and accurate information that explains the applicable terms governing play must be easily available to the player prior to the placing of a bet or wager through such supports as “game rules”, “help” or “how to play” pages placed prominently to allow players to easily locate them. All reasonable steps must be taken to ensure the content is understandable.”
The second requirement lists what the content actually has to carry — and it is a longer list than most rules panels ship with:
- how players may participate, with instructions and any terms for each method;
- clear instructions on how to interact with the game;
- clear descriptions of what constitutes a winning outcome;
- any restrictions on play or betting, such as play-duration limits or maximum wins;
- comprehensive, accurate and understandable information on the odds of winning, payout odds, or returns to players;
- the prize value units, such as currency or credits;
- other elements that affect play or results — the number of decks or the frequency of shuffles in a virtual card game, how a progressive jackpot works, how many tokens of which kind enter a bonus round and how that round behaves.
Two further points in the same standard are easy to miss and expensive to retrofit. Where speed of interaction affects the player’s chances of winning, players have to be told that connection or processor speed may affect the game; and where skill or strategy affects the chances of winning, players have to be told that. Neither is true of every game, and the obligation is to say so when it is.
The standard also fixes the units: the denomination of each credit has to be clearly displayed, displayed prizes and payouts have to be clear about their units, and players have to be given the circumstances in which a game can be declared void. A help panel that lists payouts in credits while the balance is shown in currency has answered a different question from the one asked.
What the disclosure may not say
Standard 4.07 is where Ontario’s approach differs most sharply from a generic “be honest” instruction. It states that “Information provided to players prior to and during game play shall not mislead players or misrepresent games”, and then enumerates the failures:
- describing outcomes, prizes or features that are not achievable;
- encouraging play as a means of recovering past gambling or other financial losses;
- making false promises, or presenting winning as the probable outcome;
- implying that chances of winning increase the longer one plays, the more one spends, or through skill where skill is not a factor;
- using language that suggests a particular outcome is more likely than its actual probability — the standard names the examples: “due”, “overdue”, “ready” and “ready to hit”;
- mischaracterising the nature of the game by giving it “a commonly accepted name, such as “European Roulette”, if the game does not operate as a player would reasonably expect.”
The fourth and sixth items are the ones a theme can trip. A game whose headline marketed feature is a streak that “builds” reads as an increasing chance unless the rules panel says what the mechanic actually is, and a wheel game branded with a familiar variant’s name commits the supplier to the rules a player attaches to that name — even if the theme was chosen by a client brand. That is a design-and-copy constraint, not a legal one, and it belongs in the rules specification rather than in a late review of a help screen.
The certification that has to exist before deployment
The third artefact is external. Standard 4.08 requires that “All igaming games, random number generators and components of igaming systems that accept, process, determine outcome of, display, and log details about player bets, including any subsequent modifications, must either be approved by the Registrar or certified by an independent testing laboratory registered by the Registrar, as per the AGCO’s ITL Certification Policy, prior to being provided for any gaming site.”
The appended policy spells out the boundaries that decide a launch plan.
Who may certify. Only independent test laboratories that the AGCO registers. The policy describes an ITL certification as “a form of written assurance that is issued by registered independent test laboratories (“ITLs”) to indicate that they have tested and confirmed that the types of technology captured by this policy meet the relevant AGCO Registrar’s Standards for Internet Gaming”.
What has to be certified. All games, random number generators, and the system components that accept, process, determine the outcome of, display and log player-bet details — explicitly including slot games, table games, sport and event betting, poker and other card games. Live dealer is treated separately: the requirement extends to physical random number generators with electronic elements and similar equipment, including “physical wheels (roulette), physical dice tables, and card shufflers that have electronic components”, and for live dealer games the Casino Electronic Gaming Devices and Gaming Systems Minimum Technical Standards also apply.
What the certification instrument has to contain. The policy lists eight items: the AGCO-registered name of the certifying laboratory; the AGCO-registered name of the registrant that requested it; the date of issue; a unique identifier that lets the AGCO trace the certification; the product name, version number and manufacturer; the list of standards against which the technology was certified; whether any part of the certification relied on previous testing for another jurisdiction’s requirements; and, for a recertification, a high-level description of the key changes that made it necessary. On request the laboratory must also be able to produce the results of previous testing of the same product for the same registrant, including previously identified deficiencies, and information about the testing environment, product configurations and testing methodology.
Two of those eight carry commercial weight. A certification tied to a standard list is a scoped instrument, and the policy confirms the scope is deliberately narrow: “The scope of the certification is not “all” Standards, but rather those standards that are relevant to games, random number generators, remote gaming servers, and sport and event betting systems being tested.” And the jurisdiction-dependency field is the reason a title that is already live elsewhere still needs its own instrument for Ontario.
What a certification may not do. “For regulatory purposes, an ITL may not issue a certification that is contingent on any future changes or modifications to the technology being carried out.” A laboratory may, however, certify a technology while naming features that would have to be turned off or disabled for compliance — which is a useful outcome, but only if the supplier then actually disables them and can show it. And a certification that tries to limit or disclaim the Registrar’s use of it “will not be a recognized certification”.
What counts as a change: the three recertification categories
The policy’s answer to “when do we have to test again?” is a classification, and the supplier owns it. Recertification is required “when any modification or subsequent discovery of an undetected issue impacts critical gaming system integrity, fairness, or security, or compliance with the Gaming Control Act, 1992, its regulation, and/or the Standards”, and the effect of that change is to invalidate the previous certification. The supplier classifies the delta between the previously certified software and the new version into one of three categories and keeps the classification records for the AGCO:
- Non-regulatory modifications — changes unrelated to compliance, such as minor user-experience bugs, cosmetic changes, or “new language added that is not used in Ontario”. These do not require recertification; the supplier relies on the previous certification and confirms the delta is non-regulatory.
- Regulatory modifications — changes related to compliance with the standards, including a design change that could affect one, or changes that address a regulatory concern without requiring immediate action. These must be certified before deployment.
- Emergency regulatory fixes — changes that address a live regulatory problem requiring immediate correction. These may be deployed first and “must be submitted to an ITL for Ontario certification within 5 business days of release.”
That last category is the only route by which uncertified code reaches Ontario players, and it is bounded by a clock, not by intent. The classification is also the point at which a “cosmetic” change is tested: adding a locale that the Ontario site does not serve is non-regulatory, while adding one it does serve is not, because the disclosure obligations attach to the languages the game is provided in.
Where a localized or aggregated title goes wrong
Two requirements interact badly with a cheap localization or re-skin process.
The first is the language-consistency rule inside Standard 4.06. The explanatory content has to “contain the same information and be consistent across all languages it is provided in.” Not equivalent, and not adapted — the same information, consistently. A rules page whose Spanish edition drops the maximum-win restriction, or whose Italian edition describes a bonus round with a different token count, is a defect in the artefact. The localised certification guide makes the certification case for treating each edition as its own build; Ontario adds that the disclosure is shared information with per-language renderings, not per-language content.
The second is the re-skin boundary. Ontario’s standards do not have a per-market artwork exemption. Where a platform distributes one commissioned title to several client brands, the surfaces a client may change are the ones the published disclosure does not depend on. The platform commissioning guide sets out the grant-side questions; the standards set out the consequence, which is that a change to a rules-bound surface is a change to the described artefact and may fall into the regulatory-modification category above. For an operator brief rather than a platform grant, the same boundary is drawn in the branded commissioning brief.
Keep the record, because the Registrar can ask for it
The last obligation is the one that decides whether any of the above can be proved a year later. Standard 4.04 requires that “The gaming system shall be capable of providing custom and on-demand reports to the Registrar”, with the guidance giving the shape of the request — a list of all games hosted by the website, or a list of all active player accounts.
Standard 4.09 adds the operating discipline around it: only games and remote gaming servers approved by the Registrar or certified by a registered laboratory may be used on the gaming site; any problem with the integrity or security of the gaming system must be reported to the Registrar immediately; monitoring and testing have to run throughout the life of the system; and where a supplier identifies a problem it has to “take immediate action, conduct timely investigations, and make any necessary corrections”. Operators separately have to “monitor the payback of their live games to detect any behaviour that may indicate faulty performance”, and Standard 4.10 requires a game to be made unavailable to players while a suspected fault that may affect integrity or fairness is unresolved, with the operator’s decisions “fair, reasonable, and made in good faith”.
For a studio, the practical reading is that the specification, the disclosure and the certification are one pack, versioned together, kept for the release that is live. That is the form the certification submission takes in most markets, and Ontario’s variation is only in what the pack has to name. An operator or platform working through a certification and compliance partner can ask for that pack as a deliverable per release rather than assembling it after a query arrives — and, if the title is being distributed rather than operated, can ask the aggregation partner which version of it each client received.
Questions suppliers ask
Is a game approved once for Ontario, or certified game by game?
Both routes exist and both are per-artefact. Standard 4.08 requires every igaming game, random number generator and relevant system component to be either approved by the Registrar or certified by an AGCO-registered independent testing laboratory before it is provided for any gaming site, and it extends that to “any subsequent modifications”. Certification is issued against a product, version number and manufacturer, with a defined list of standards, so it attaches to the build it describes rather than to the studio’s catalogue.
Does the player-facing rules content have to match across languages?
Yes. Standard 4.06 requires the explanatory content to “contain the same information and be consistent across all languages it is provided in”. The obligation is about the information the game discloses, not about translation quality in the abstract: a localized edition that omits a play restriction, describes a bonus round differently or states different payout units has published inconsistent information. Treat the disclosure as one document with per-language renderings.
Which changes to a certified game force recertification in Ontario?
The supplier classifies the delta between the last certified software and the new version as non-regulatory, regulatory or an emergency regulatory fix. Non-regulatory modifications, including cosmetic changes and a language that is not used in Ontario, can rely on the previous certification. Regulatory modifications must be certified before deployment. Emergency regulatory fixes can be deployed immediately but must go to an ITL for Ontario certification within five business days of release. The classification records have to be kept and produced to the AGCO on request.
Can a laboratory certify a game with conditions attached?
Not as a conditional certification. The policy states that an ITL may not issue a certification that is contingent on future changes to the technology, and that a certification purporting to limit or disclaim the Registrar’s use of it will not be recognised. What a laboratory may do is certify the technology while specifying one or more features that would need to be turned off or disabled for it to be compliant — which shifts the work back to the supplier’s release process, where the feature has to actually be disabled.
What happens if a game is found to have a fault after launch?
Standard 4.10 requires the operator to make the game unavailable to players while a suspected game or system fault that may affect integrity or fairness is unresolved, and Standard 4.09 requires the Registrar to be notified immediately of any problem with the integrity or security of the gaming system, with logs and supporting evidence preserved. A fault that turns out to be a regulatory issue also starts the modification clock: the fix is certified after release, within five business days.
Does any of this apply to a supplier that is not the operator?
It can. The standards state that operators must ensure the standards for their gaming site are met regardless of which entity carries out the activity, and that the Registrar may hold an operator, a gaming-related supplier, or both accountable for a particular standard. Several game-integrity standards — including 4.01, 4.02, 4.05, 4.08 and 4.09 — are also marked as applying to gaming-related suppliers. The clearer reading is that a supplier should hold its own evidence rather than rely on the operator’s.
