How to Get GLI Certified: The Complete Certification Process for Game Studios

GLI certification is a precondition for market access across dozens of regulated jurisdictions, from Ontario and Alberta under the AGCO and AGLC frameworks, to Malta under the MGA’s technical conformity requirements, to the Netherlands KSA’s Keuringsschema. Game studios that arrive at the submission stage without a complete understanding of what the process actually demands face testing delays, deficiency loops, and delayed launches. This guide maps the full certification lifecycle as defined in the GLI Composite Submission Requirements Version 2.0 (revised 23 March 2020), Gaming Laboratories International’s governing document for all submissions.

What the GLI Certification Process Actually Covers

The Composite Submission Requirements document is not a standard in the technical sense. It is GLI’s operational specification for what must be physically and digitally provided by a submitting party before and during evaluation. It does not replace the governing technical standard, which for interactive games and online casino titles is typically GLI-19: Standards for Interactive Gaming Systems (v3.0), but it governs how submission packages must be assembled, labelled, and delivered for that standard to be tested against.

The document applies to all Gaming Equipment, Software, Systems, and elements thereof submitted to GLI for evaluation. It covers prototype submissions (first-time submissions), modification submissions (revisions to previously certified or under-review items), and specialised submission types including RNG-only submissions, game mathematics submissions, interactive gaming system submissions, and network security submissions. Each type carries distinct documentation requirements stacked on top of a common baseline that applies to every submission without exception.

How Long Does GLI Certification Take?

GLI does not publish a fixed public timeline for the certification process, as duration depends on the complexity of the submission, the number of jurisdictions requested, and whether deficiencies are raised during testing. A clean prototype submission for a new RNG-based online slot, targeting a single jurisdiction, typically takes several weeks from complete submission to report issuance. Multi-jurisdiction submissions, novel game mechanics, or submissions that require deficiency resolution add time at each stage. Studios that submit incomplete packages add the longest delays of all: GLI will hold the submission and request additional information, during which time the clock does not run toward certification. Engaging GLI’s pre-submission consultation services before lodging a formal submission is standard industry practice for studios targeting compressed market-entry timelines.

The Submission Structure: Three Tracks

Every submission to GLI falls into one of three primary tracks. Understanding which track applies before preparing documentation prevents the most common pre-submission errors.

A Prototype (Full Submission) is required for any first-time submission of a particular piece of hardware or software. This is the most document-intensive track and triggers the full evaluation scope under the applicable technical standard. Studios certifying a new game title for the first time, or certifying a platform component that has never previously been evaluated, must follow this track.

A Modification Submission applies whenever a change is made to hardware or software that is currently under review, currently certified, or was previously reviewed and not certified. The Composite Submission Requirements v2.0 is explicit: all modifications require re-testing, examination, and re-certification by GLI. There is no partial certification carry-over for a modified component. For software modifications, the submitter must identify the previously submitted software version, describe the software changes in plain language with associated test case scenarios, specify the modules affected, and provide the new source code for the entire program. The exception to full re-documentation applies only where documentation has not changed, for example, if a game program modification does not alter the paytable or mathematics, the submitter may reference previous documentation rather than resubmitting identical documents.

A Math Clone is a distinct submission type applicable where a game shares mathematical parameters with a previously certified submission. This track has a narrower documentation footprint, but the submitter must establish the relationship to the prior submission clearly in the submission letter and accompanying materials.

Mandatory Pre-Submission Checklist

The Composite Submission Requirements v2.0 identifies a baseline set of materials that must accompany every submission regardless of type. Failure to provide any item at the time of submission gives GLI the right to request additional information, failure to supply it can result in denial of the submission or material testing delays.

Item	Requirement
Submission letter	On company letterhead, dated within 1 week of the date GLI receives the submission
Jurisdiction(s) identified	All target jurisdictions listed explicitly in the letter
Items for certification described	Full description of each item being submitted for evaluation
Primary contact named	Name, title, address, phone, and email of the contact for technical questions
Software signatures	Documentation listing official software signatures (SHA1, MD5, or SHA256) of all software provided
Field-identical hardware/software	All submitted items must be functionally identical to what will be deployed in the field
Component list with revision levels	All components must include an ID number and revision level
Jurisdiction-specific media copies	Additional copies of media and labels as required by each jurisdiction requested

The submission letter date requirement deserves special attention. The letter must be dated within one week of the date the submission is physically received by GLI. A letter pre-dated by more than a week, or submitted after the materials arrive, creates an administrative deficiency before a single test has been run.

The submission letter also determines who receives the approval letter at conclusion. GLI registers an internal file number in the name of the submitting company, bills that company for all costs, and issues the approval letter to the primary contact company. In multi-party submissions, where a game studio submits a title that incorporates a third-party RNG provider’s component, all suppliers in the submission group may need to hold licences in the jurisdictions where approval is sought. GLI may assist by inquiring with the relevant regulator, but licensing questions remain the studio’s direct responsibility to resolve with each jurisdiction.

“GLI will delegate an internal file number in this company’s name and will bill this company for all costs incurred throughout the testing and approval process. The primary contact will be called when questions arise. However, GLI engineers will work with all parties involved in order to complete the review.”, GLI Composite Submission Requirements v2.0, section 1.1

Software Submission Requirements in Detail

For game studios, software submissions are the core of the certification package. The Composite Submission Requirements v2.0 sets out specific documentation obligations for software beyond those in the submission letter.

The game software image files must be provided on appropriate media. A documentation list of official software signatures for all software provided is mandatory: these signatures are used to verify that the image files and media received by GLI contain the correct software versions. Any and all additional software tools necessary to perform testing must accompany the submission. Where a studio is referencing a component previously certified under a prior submission, such as a Math Clone relationship, that prior submission must be explicitly identified.

Source code standards are non-negotiable. All source code must be final, no longer in test or development. It must be delivered in full along with the compiled binaries. GLI will compile the source code and take digital signatures during the compile process to confirm that the product being tested is the final release version that will be implemented in the field. Source code must be commented in an informative manner, allowing a reader without deep knowledge of the platform architecture to understand the functions and code sections being examined. The compiled result must be identical to the storage medium submitted for evaluation, or verifiable as functionally identical via a method agreed by all parties. Compilation may be performed at GLI, at the manufacturer’s location using a witness build process, or via another agreed method.

RNG Submissions: The Most Scrutinised Element

The Random Number Generator analysis is consistently the most technically demanding component of any game studio certification. The Composite Submission Requirements v2.0 describes the RNG analysis as containing three primary items: source code review, statistical data analysis, and software verification. The conclusion in the final GLI report is based on results across all three.

Source code review requires submission of the final source code package associated with the RNG and game software. If a test application is created to pull data from the RNG, the source code for that test application must also be submitted, so that GLI can confirm it generates data in the same manner as production software.

Statistical data analysis requires that GLI be able to generate, using the test application, very large volumes of repeatable data in a computer-parsable format. The Composite Submission Requirements v2.0 gives as an example a scenario requiring 51,000,000 records, but notes that GLI’s data collection requirements are large and that hundreds of millions of draws may be required depending on game format and range. The larger the game range, the larger the number of draws GLI may require. Studios that underestimate the computational overhead of producing this data at submission time have encountered timeline failures that pre-submission scoping calls did not anticipate.

Software verification serves a specific purpose: uniquely identifying the RNG that was tested so that future submissions containing the same RNG component can be verified against it. GLI records the key files and their respective cryptographic signatures in the report. GLI works with the manufacturer to identify all key software components that would have an impact on the RNG within the scope of testing, and those components are then archived for reference in future submissions.

RNG source code shall be final and no longer in test or development. Source code shall be delivered in full along with the compiled binaries. Source code will be compiled by GLI and digital signatures will be taken during compile to ensure that the product being tested is the final release version that will be implemented in the field., GLI Composite Submission Requirements v2.0, section 2.2

Game Mathematics and PAR Sheet Requirements

For each game submitted, the manufacturer must supply calculation sheets, commonly called PAR sheets, that determine the theoretical return to player (RTP). Under the Composite Submission Requirements v2.0, PAR sheets must cover the base game, double-up options, free games, progressive features, bonus features, and any other component that contributes to the overall RTP calculation. GLI-19 v3.0 requires that the minimum RTP requirement be met using the play strategy that provides the greatest return to the player over a period of continuous play, and that for progressive jackpots the minimum is met using the lowest available parameters for the jackpot during the expected lifetime of the game.

For each game variant submitted, the documentation must include all game rules with prize tables, the complete description of game features including free games, bonus rounds and special features, all paytable configurations offered, and the theoretical RTP for each paytable. Where progressive jackpots or incrementing jackpots are involved, the submission must additionally specify all jackpot features, the number of levels, the startup value, reset value, and increment rates for each level, any hidden increments or secondary increments, and the rules for winning each level.

Interactive Gaming System Submissions

Studios submitting a full interactive gaming system, rather than individual game titles to sit on an already-certified platform, face a broader documentation scope under the Composite Submission Requirements v2.0 section on Gaming and Wagering System Submissions. This applies to Server Based Gaming Systems, Interactive Gaming Systems, Event Wagering Systems, and Wireless Gaming Systems.

Documentation must describe how the following system functions are supported: player account registration, player identity verification, player account login including username and password mechanics, player interface to player account, player protection features, privacy policy implementation, and player account deactivation. The submission must include a detailed description of how player verification information is protected from unauthorised access, a detailed description of player authentication at each login event, and a description of how player registration and account information, including payment data where applicable, is protected.

Network architecture documentation requirements are substantial. The submission must include network topology diagrams, internal and external IP addresses for all devices, controls preventing unauthorised configuration modification, LAN and VLAN design including all functional subnets and firewalls, details of the gaming platform’s connections to the internet, and details of any remote connections used to support system operations. A list of all non-production systems and third-party systems connecting to the system must be submitted, with details of the connection method, information transferred in each direction, the initiating entity, and controls preventing eavesdropping or unauthorised access for each external connection.

The Testing Sequence and How Deficiencies Are Handled

Once a complete submission is received, GLI assigns engineers to the engagement and begins working through the applicable technical standard: GLI-19 v3.0 for interactive gaming systems, GLI-33 v1.1 for event wagering systems, or another standard as directed by the regulator. The testing sequence follows the structure of the applicable standard, covering source code review, RNG statistical analysis, game mathematics verification, system functionality testing, and security assessment.

Where GLI determines that submitted materials do not conform to a tested standard or requirement, it notifies the client. The GLI Terms and Conditions confirm that GLI shall notify the client if the submission materials do not conform to the tested standard or requirement. The notification identifies the specific non-conformance. The studio then addresses the deficiency, correcting source code, revising documentation, or adjusting configuration, and resubmits the affected component. Each deficiency cycle extends the overall certification timeline.

Where a modification results from the deficiency resolution process, that modification must itself meet the requirements for a modification submission: identification of the previously submitted version, a plain-language description of the change and its associated test case scenarios, identification of the affected modules, and the new source code for the entire program where source code is affected.

The GLI report, once issued, is proprietary to GLI and the client. It may not be reproduced except in full, and only with GLI’s written approval. Reports may only be used within the original, whole context and for the specific scope stated. Any alteration renders the report invalid. Studios seeking to use a GLI report as part of a licensing application in a jurisdiction not named in the original report must engage GLI to extend the scope of evaluation, as a report issued for one jurisdiction cannot be repurposed for another without GLI’s explicit involvement.

Receiving the Certified Mark

Upon successful completion of testing, the primary contact company receives the approval letter confirming that the submission meets the jurisdictional requirements. The certified items are considered certified as of the date shown in the “Date of Report” section on the first page of the original GLI-issued report. The certification remains valid for use until notification is sent that an item is no longer permitted for use within the specified jurisdiction.

Use of the Gaming Labs Certified mark carries ongoing obligations. The client agrees to permit GLI representatives to perform surveillance audits of how the mark is being used. Additionally, the American Association for Laboratory Accreditation (A2LA) holds the right to perform its own surveillance audit at its discretion, to confirm that the mark’s use does not imply A2LA endorsement of the client’s products or services. Studios must not state or imply that GLI has endorsed, approved, or recommended the functional quality or performance of their product in terms beyond what is expressly stated in the report.

Critically, the certification established by a GLI report applies exclusively to the specific items submitted by the manufacturer identified in the scope of evaluation on the report’s first page. It is the manufacturer’s own responsibility to obtain and maintain all necessary gaming licences in each jurisdiction where they do business. A GLI certificate does not confer a licence, it satisfies a technical compliance prerequisite that regulators require as part of the licensing or product approval process.

Jurisdiction-Specific Considerations

The Composite Submission Requirements v2.0 explicitly notes that it does not address any particular jurisdiction’s submission requirements. Additional documentation and materials may be required by GLI for testing in a specific jurisdiction, based on the technical requirements that jurisdiction has adopted. Studios targeting the Ontario iGaming market under the AGCO’s Registrar’s Standards for Internet Gaming, Alberta’s AGLC Standards and Requirements for Internet Gaming, or markets in the MGA’s framework must confirm jurisdiction-specific technical requirements directly with the relevant regulator or with GLI’s regulatory affairs team. Meeting the baseline Composite Submission Requirements v2.0 checklist is not sufficient for every market without that confirmation.

For MGA-regulated products, the relevant MGA technical directives and conformance requirements apply alongside the GLI testing process. For UKGC Remote Technical Standards compliance, the RTS specifies independent testing laboratory requirements that must be addressed in parallel. Compliance teams should map the applicable regulatory framework and the GLI testing requirements together from the outset. Consulting qualified legal counsel familiar with each target jurisdiction is advisable before finalising certification scope for multi-jurisdictional launch programmes. The Ontario and Alberta frameworks in particular diverge in meaningful ways on technical approval obligations, a structured comparison of those two regimes is available for studios planning sequential or simultaneous entry into both markets.

Modification Management After Initial Certification

Certification is not a one-time event. The Composite Submission Requirements v2.0 is unambiguous: all modifications to certified hardware or software require re-testing, examination, and re-certification by GLI. This applies to software modifications that create new functionality, modify existing functionality, or change any module. For hardware, each modification must be re-tested, and the documentation requirement mirrors that of the original hardware submission for the affected components.

The practical implication for game studios is that change management processes must account for the GLI re-certification cycle from the earliest stages of product roadmap planning. A certified game that receives a paytable change, a new bonus feature, or an amended RNG seeding mechanism is no longer certified under its original certificate for those elements. Studios operating in markets where the regulator requires that only currently certified game versions be offered to players must complete re-certification before deploying modified versions to the live environment. Deploying an uncertified modification is a regulatory breach, not merely a technical one.

Where a submitter has provided information to GLI on a prior submission and that information has not changed, duplicate documentation is not required in a modification submission, provided the previous information is explicitly referenced and is easily located by GLI. Studios should maintain their submission records in a structured internal archive to facilitate this reference mechanism and avoid reconstructing prior submission details during a modification cycle. For a detailed look at the technical audit obligations that accompany active system certification in a comparable regulated market, the MGA system audit requirements framework illustrates the ongoing documentation burden operators and studios face post-certification.

Key Resources

GLI Composite Submission Requirements v2.0, Gaming Laboratories International, LLC. Revised 23 March 2020. The primary operational document governing all submission packaging, documentation, and process requirements.

GLI-19: Standards for Interactive Gaming Systems v3.0, Gaming Laboratories International, LLC. Revised 17 July 2020. The governing technical standard for online casino and interactive gaming system certification.

GLI Terms and Conditions, Gaming Laboratories International, LLC. Governs the contractual relationship between the submitting party and GLI, including report use, deficiency notification, and certified mark obligations. Available via gaminglabs.com.

GLI-33: Standards for Event Wagering Systems v1.1, Gaming Laboratories International, LLC. Revised 14 May 2019. The governing technical standard for sports betting and event wagering system certification.

Compliance professionals should obtain current versions of all referenced GLI documents directly from gaminglabs.com, as version numbers and requirements are subject to update. Jurisdiction-specific technical requirements vary materially between regulated markets. Studios targeting multiple jurisdictions should seek qualified legal and regulatory counsel to map GLI certification obligations against each regulator’s specific technical approval requirements before assembling a submission package.