GLI Certification Testing Timelines: What Drives Duration by Standard and Game Type

Suppliers and operators entering a new regulated market regularly underestimate how long GLI certification will take. The GLI-19 Standards for Interactive Gaming Systems (v3.0) and GLI-33 Standards for Event Wagering Systems (v1.1) do not publish fixed review windows, and the GLI Composite Submission Requirements v2.0 makes clear that duration depends almost entirely on what is submitted, in what condition, and for how many jurisdictions simultaneously. Understanding the process mechanics that drive timeline is far more useful than asking for a number, because the number changes every time the lab sends a deficiency notice.

How the Certification Process Actually Works

GLI certifications begin when a supplier or operator submits a request letter, on company letterhead, dated within one week of the date the submission is received by GLI. The Composite Submission Requirements v2.0 specifies that the letter must identify the jurisdiction or jurisdictions for which certification is requested, the items requested for certification, and the names of all parties involved in the submission group. GLI then assigns an internal file number in the primary contact company’s name and that company bears all costs incurred throughout the process.

Once the submission is received, GLI engineers begin the formal review. If the submitted materials do not conform to the tested standard or regulatory requirement, GLI notifies the client. This deficiency notice does not result in an automatic re-submission from scratch, but it does pause active review until the client addresses each identified item. Every round-trip between the lab and the development team consumes calendar time the submission timeline does not recover. Incomplete source code, uncommented files, and unresolved RNG compilation issues are the most common triggers for deficiency notices.

Upon successful completion of all testing phases, GLI issues a certificate of compliance evidencing conformance to the relevant standard. The certification is effective as of the date shown in the “Date of Report:” section on the first page of the original GLI-issued report. GLI-19 v3.0 describes this outcome directly: “Upon the successful completion of testing, the independent testing laboratory will provide a certificate of compliance evidencing the certification to this standard.”

What Drives Duration Under GLI-19 (Interactive Gaming Systems)

GLI-19 v3.0 covers the full technical stack of an online gaming platform: server-side game logic, RNG, game client presentation, account management systems, transaction processing, responsible gambling controls, and the specific requirements for live dealer games. The breadth of scope means that a full platform certification under GLI-19 involves multiple distinct testing phases, each of which can run in parallel or in sequence depending on how well the submission is structured.

RNG Testing: The Critical Path

RNG testing under GLI-19 and the Composite Submission Requirements v2.0 is consistently the longest single phase in an interactive gaming certification. The analysis comprises three interdependent components: source code review, statistical data analysis, and software verification. All three must be completed before the conclusion in the final GLI report can be issued.

For source code review, GLI requires the final source code package associated with the RNG and game software. The Composite Submission Requirements v2.0 states that source code must be final and no longer in test or development, delivered in full along with compiled binaries. GLI compiles the source code and takes digital signatures to confirm that the product under test is the final release version. Code that is not fully commented, meaning that a reader without deep knowledge of the platform architecture cannot understand the nature of functions and code sections, will result in a deficiency notice before testing can proceed.

For statistical data analysis, GLI-19 v3.0 section 3.4.2 requires collection of game outcome data for at least 10,000 game outcomes, accomplished “in a fashion reasonably similar to the intended use of the device in the field.” The standard notes that the regulatory body may accept results from a smaller collection on a case-by-case basis, or require a larger sample. In practice, the Composite Submission Requirements v2.0 is explicit: “GLI’s data collection requirements are large. Please expect that GLI may require hundreds of millions of draws, depending on game format. In most cases, the larger the game range, the larger the number of draws required.” For a five-reel game with a large combinatorial range, the data collection tool must be capable of generating data in exactly the same manner as the live production application. Supplying a test application that generates data differently from the production environment will invalidate the statistical analysis.

“GLI’s data collection requirements are large. Please expect that GLI may require hundreds of millions of draws, depending on game format. In most cases, the larger the game range, the larger the number of draws required.”

Software verification is the final RNG phase. GLI records key files and their respective signatures (SHA1, MD5, or SHA256) in the report. Any future submission in which the same RNG is contained must be verified against this archived signature set. A change to a previously certified RNG, even a minor one, triggers re-testing of that component.

Game Type Complexity and Its Effect on Timeline

The table below reflects the relative technical complexity that GLI-19 and the supporting submission requirements impose on different iGaming product types. None of these are GLI-published SLA windows, GLI does not publish fixed timelines. They reflect the testing phases each product type requires and their relative complexity.

Product Type	Key GLI-19 Testing Phases	Primary Timeline Drivers	Relative Complexity
RNG Slots (standard)	RNG source code review, statistical analysis, game maths/RTP, platform integration	RNG draw volume, paytable verification	Moderate
RNG Slots (complex mechanics)	As above, plus proprietary feature evaluation (e.g. linked progressives, multi-feature triggers)	Feature-specific outcome distributions, increased draw requirements	High
Table Games (RNG-based)	RNG review, game rules evaluation, side-bet maths, shuffler standards (GLI-29 where applicable)	Multiple side bet paytable certifications, card shuffle verification	Moderate, High
Live Dealer Games	GLI-19 s.4.18 live game requirements, streaming/video feed audit, third-party service provider review	Service provider operational controls review, real-time data integrity	High
Poker (RNG-based)	RNG review, deck shuffle statistical analysis, hand outcome distribution	Combinatorial range drives high draw volumes	High
Remote Gaming Server (RGS) Platform	Full GLI-19 platform scope: security, account management, transaction integrity, responsible gambling controls	Architecture breadth, number of integrated game suppliers, compliance with RG tool requirements	Very High
Sports Betting Platform (GLI-33)	Wagering system integrity, account management, event data handling, reporting, financial transactions	White-label configuration complexity, operator-specific configuration documentation	Moderate, High

GLI-33 and Event Wagering: Where Duration Differs from GLI-19

GLI-33 v1.1 governs event wagering systems, primarily sports betting platforms. The standard’s introductory text states it is intended as a compliance guideline for technologies and procedures pertaining to event wagering, and it acknowledges that it is not a set of prescriptive requirements to which every operator must conform in identical fashion. That flexibility has a cost in the testing room: the relevant introductory provisions of GLI-33 require that the specific configuration to be used in the production environment be communicated to the independent test laboratory in order to facilitate creating a functionally equivalent test environment. Operators who cannot provide final production configuration detail at submission time extend their own timeline.

Unlike GLI-19, which centres heavily on RNG statistical testing, GLI-33 places its primary burden on wagering transaction integrity, event data management, financial transaction records, and the accuracy of wager lifecycle documentation. The standard requires that the system record, among other items, the date and time the event started and ended, the date and time results were confirmed, all player choices including market and line postings, total amounts wagered and won, and the date and time any winning wager was paid to the player. Verification that these audit records are complete, accurate, and tamper-resistant across the test environment is the core of the GLI-33 review engagement. Platforms with configurable modules that have not been finalised at submission time create gaps in that audit-trail verification.

What Deficiencies Actually Cost

The single most controllable variable in a GLI certification timeline is deficiency avoidance. GLI’s terms and conditions confirm that GLI will notify the client if the submission materials do not conform to the tested standard. The notification requires the client to remediate and resubmit. A deficiency notice does not restart the clock from zero, but every round-trip between the lab and the development team burns two to four weeks of calendar time that no roadmap can recover.

The most common causes of deficiency notices under the Composite Submission Requirements v2.0 are avoidable with pre-submission discipline. Source code that is not fully compiled and verified, RNG data collection tools that generate output differently from the production application, submission letters dated more than one week before the materials arrive, and security documentation that does not address all firewall and encryption requirements specified in GLI-19 Appendix B all produce deficiency notices within the first week of review.

For network security certification, the Composite Submission Requirements v2.0 states that requirements “will be handled on a case-by-case basis between the parties requesting certification and GLI,” because essential phases of certification occur within the gaming property. Operators who do not budget scoping time for network security certification before the formal submission process begins routinely discover that this phase adds weeks to the total engagement independently of how well the rest of the submission is prepared.

Multi-Jurisdiction Composite Submissions

A composite submission allows a single submission group to request certification across multiple jurisdictions simultaneously. The Composite Submission Requirements v2.0 establishes that the company submitting the request must do so on its own letterhead, that all suppliers in the group may need to be licensed in the jurisdictions where the submission is being approved, and that GLI may inquire on behalf of the client as to which parties require jurisdictional licensing. Licensing questions must be handled directly with each jurisdiction, as GLI does not determine licensing status.

The practical timeline implication of composite submissions is that the certification clock does not stop at the lab. If one jurisdiction in the submission group requires additional documentation or a jurisdiction-specific review, the approval letter for the entire submission group waits. The Composite Submission Requirements v2.0 is explicit: “Upon completion, the primary contact company will receive the approval letter, provided the submission meets the jurisdictional requirements.” Meeting requirements in all named jurisdictions simultaneously is the condition precedent. Compliance teams planning composite submissions for markets with materially different technical standards, for example combining a jurisdiction that has adopted GLI-19 wholesale with one that overlays additional requirements, should identify those delta requirements before the submission date, not during the review.

Transfers of approval for existing iGaming certifications are a related mechanism. Where a product holds a valid GLI certification for one jurisdiction and is seeking acceptance in a second, GLI’s transfer process reviews the existing certification against the second jurisdiction’s specific requirements. This process is shorter than a fresh certification engagement when the technical standards are closely aligned, but it is not automatic. Jurisdictions with bespoke overlay requirements, such as the Netherlands KSA’s own Keuringsschema or Denmark’s Spillemyndigheden Technical Requirements, mean that transfer requests effectively become incremental compliance reviews rather than administrative approvals.

Change Management: Post-Certification Timelines

Initial certification is not the end of the timeline obligation. The GLI Change Management Program Guide v1.0 establishes a three-level change classification system that governs how modifications to certified products are handled after deployment. Level 1 changes are minor and carry no mandatory pre-notification requirement. Level 2 and Level 3 changes require at least three business days’ advance notice to both the regulatory bodies and the independent test laboratory that performed the prior certification before deployment.

The regulatory body or the independent test laboratory, if delegated, reserves the right to request testing and potentially certification of platform updates before implementation. If no such request is made within the three-business-day window, passive approval is conveyed and the operator or supplier may introduce the change into production. However, where certification of Level 2 and Level 3 changes is not required before deployment, laboratory testing of those changes must still be completed within 90 days of introduction into the production environment.

The Change Management Program Guide v1.0 also establishes an emergency rule: in emergency situations involving open threats or liabilities, a licensed operator or technology supplier may execute Level 2 or Level 3 changes immediately without prior consent. Notice must be provided to the regulatory bodies as soon as possible, including the necessity for employing the emergency rule and all details known at the time. Regulatory bodies retain the right to conduct analysis following emergency changes. The emergency rule is not a workaround for schedule pressure.

Annual re-certification is a standing obligation under the Change Management Program Guide v1.0. Unless otherwise specified by the regulatory body, at least once annually, each product operating under a Change Management Program must be fully certified to the rules and regulations of all jurisdictions in which it operates, with formal certification documentation from an independent test laboratory. Hardship waivers for extension beyond the annual approval are available but are granted at the sole discretion of the regulatory body.

“Unless otherwise specified by the regulatory body, at least once annually, each product operating under a Change Management Program must be fully certified to the rules and regulations of all jurisdictions operating therein and accompanied by formal certification documentation from an independent test laboratory with knowledge of the product.”

Pre-Compliance Testing: The Most Effective Timeline Tool

GLI identifies pre-compliance testing as one of its most frequently requested services. The purpose is to identify deficiencies before the formal certification submission, removing the deficiency-and-remediation loop that accounts for the majority of timeline overruns. Engaging GLI’s pre-compliance testing service means engineers review the submission materials, RNG implementation, and source code in an advisory capacity before the formal review clock begins.

The commercial case is straightforward. A single round of pre-compliance testing that catches three deficiency items saves the equivalent of six to twelve weeks of calendar time that would otherwise be consumed by formal deficiency notice cycles. For suppliers targeting multiple jurisdictions simultaneously, the savings compound. SB22’s compliance team commented publicly that GLI’s pre-compliance service allowed them to develop a high level of comfort before their GLI-33 platform certification, which represents verified operator experience of the service’s practical value.

Pre-compliance testing does not accelerate the formal testing period itself. The lab still performs the full scope of review required by the applicable standard. What it removes is unplanned time: the elapsed weeks between a deficiency notice and a resolved resubmission, repeated across multiple items, is where certification timelines slip beyond what any product launch roadmap anticipated.

Planning a Certification Schedule Into a Product Launch Roadmap

The question compliance teams consistently ask is how far in advance of a target launch date the certification submission should be lodged. The variable is not “time in the lab” but “number of deficiency cycles before a clean pass.” A well-prepared submission with complete, commented, compilable source code, a fully functional RNG data collection tool, a finalised production configuration, and complete security documentation for all applicable GLI-19 or GLI-33 chapters progresses materially faster than an incomplete one.

For a standard RNG slot game targeting a single jurisdiction under GLI-19, a clean submission with no deficiencies from an experienced supplier can progress through the RNG analysis and game certification phases in a matter of weeks. Adding a complex feature set, such as linked progressives, multi-tier RNG draws, or novel mechanic implementations, extends both the source code review phase and the statistical data collection requirements. For a full RGS platform certification under GLI-19, covering platform security, account management, transaction integrity, responsible gambling tools, and multiple integrated game types, compliance teams should plan for a substantially longer engagement and treat pre-compliance testing as mandatory rather than optional.

For sports betting platforms under GLI-33, the absence of heavy RNG statistical testing removes one duration driver, but the requirement to build and document a functionally equivalent test environment that mirrors the operator’s specific production configuration means that pre-submission preparation carries equal weight. White-label deployments where the operator’s final configuration is not fixed at submission time are a documented source of delay under GLI-33.

Compliance teams building a product launch roadmap should account for the following phases in sequence: pre-compliance testing engagement, formal submission preparation (source code finalisation, RNG data collection tool build, security documentation), submission lodgement, active lab review, deficiency resolution cycles (budget at least one round even for experienced teams), and report issuance. After report issuance, the certification is effective as of the date of the report. Any post-launch changes at Level 2 or Level 3 trigger the three-business-day notice obligation and the 90-day post-deployment testing window.

For suppliers working through the decision that sits upstream of all timeline planning, the choice between GLI-19 and GLI-33 must be resolved before engagement begins. Selecting the wrong standard, applying GLI-19 to a pure event wagering system or GLI-33 to an RNG-based casino game, wastes the entire submission period.

Operators planning entry into the AGCO-regulated Ontario market or Alberta’s AGLC framework should note that both jurisdictions require certified technology suppliers as part of their registration and operating agreement conditions. AGCO and AGLC differ in their specific technical standards, meaning a certification accepted in one province is not automatically accepted in the other without a jurisdiction-specific review. Suppliers entering both markets simultaneously should scope composite submissions carefully.

Operators and suppliers uncertain about the application of any specific GLI standard, the scope of a composite submission, or the jurisdictional acceptance of a certification should consult qualified legal counsel and engage GLI’s jurisdictional consultation services before submitting. Jurisdictional acceptance of a GLI certificate is governed by each regulator, not by GLI, and the lab’s report reflects conformance to the tested standard, not authorisation to operate in any specific market.

Key Resources

GLI-19: Standards for Interactive Gaming Systems, Version 3.0 (revised July 17, 2020), Gaming Laboratories International. Primary technical standard for online and interactive gaming platforms, including RNG requirements, game certification, live dealer, and platform security.

GLI-33: Standards for Event Wagering Systems, Version 1.1 (revised May 14, 2019), Gaming Laboratories International. Primary technical standard for sports betting and event wagering systems.

GLI Composite Submission Requirements, Version 2.0, Gaming Laboratories International. Governs submission format, source code requirements, RNG analysis procedures, and multi-jurisdiction composite submission handling.

GLI Change Management Program Guide, Version 1.0, Gaming Laboratories International. Establishes the three-level change classification system, notification obligations, 90-day post-deployment testing requirement, and annual re-certification obligation.

Gaming Laboratories International, Digital and iGaming Testing, Certification and Standards Advisory, gaminglabs.com. Overview of GLI’s full iGaming testing service portfolio including pre-compliance testing, RTP testing, RNG certification, live dealer evaluation, and transfer of approval services.