Common GLI Certification Failures and How to Avoid Them

Most GLI-19 certification failures are evidence failures, not RNG mathematics failures. The laboratory cannot tie the tested software to the production build, the PAR sheet does not reconcile to the paytable shown to the player, or the system cannot reconstruct who altered a parameter and when. GLI does not publish rejection statistics, so the ranking in this article is analysis. It rests on the text of GLI-19 v3.0 (revision date 17 July 2020), the GLI Composite Submission Requirements v2.0 (23 March 2020), and the GLI Change Management Program Guide v1.0. Suppliers and licensees who engineer their build pipeline, documentation set, and change log to those texts remove most of the failure points before the first test case runs. The final obligations vary by regulator, so confirm jurisdiction-specific application with qualified legal counsel.

Why do GLI certification submissions fail?

Submissions fail or stall when the package does not let the independent test laboratory verify what it is testing. The Composite Submission Requirements state that where information is missing, “the submitting party shall be asked to supply additional information,” and that failure to supply it “can result in denial of the submission and/or lead to testing delays.”

GLI-19 itself frames the engagement as evidence-based. The standard’s introduction says operators and suppliers are expected to provide documentation, credentials, and access to a production equivalent test environment, and that the laboratory issues a certificate of compliance on successful completion. A test environment that differs from production, or documentation that describes a different version from the one submitted, breaks that premise.

A counter-argument deserves weight. GLI standards are not law in most markets. GLI-19 repeatedly defers to “the regulatory body” on thresholds, retention periods, and patching policy, and the Composite Submission Requirements say they do not speak to any particular jurisdiction’s submission rules. A submission can therefore satisfy GLI-19 and still fail against a regulator’s own technical standards. Licensees should read GLI findings against the adopting jurisdiction’s rules, for example the UKGC Remote Technical Standards or the AGCO Registrar’s Standards for Internet Gaming. Our comparison of the two standards that most often anchor an interactive submission is in GLI-19 vs GLI-33: Choosing the Right Standard for Your Certification Path.

The table below collects the numeric thresholds in the GLI documents that most often appear in findings. Figures are as of October 2026 and reflect the document versions named, GLI revises its series periodically, so confirm the current version with the laboratory at scoping.

Control	Figure or rule	Source
RNG statistical evaluation	Tests evaluated collectively at 99% confidence	GLI-19 v3.0, 3.2.2
Minimum theoretical payout, house-banked games	75% over expected lifetime unless the regulator specifies otherwise	GLI-19 v3.0, 4.7.1
Double-up/gamble feature	Theoretical return of 100%	GLI-19 v3.0, double-up/gamble feature requirements
Linked jackpot proportionality	Variance up to 5% on probability, 1% tolerance on expected RTP	GLI-19 v3.0, section 4.13
Backup frequency	At least once every day unless the regulator specifies otherwise	GLI-19 v3.0, B.3.3
Periodic security testing	Annually, or as the regulator requires	GLI-19 v3.0, B.9.1
Advance notice of Level 2 or 3 changes	At least 3 business days	CMP Guide v1.0, 6.1
Laboratory testing where pre-deployment certification is not required	Within 90 days of production introduction	CMP Guide v1.0, 6.2
Submission request letter	Dated within 1 week of receipt by GLI	Composite Submission Requirements v2.0

RNG implementation: scaling bias and software identity

GLI-19 3.2.1 requires the laboratory to review source code for “core randomness algorithms, scaling algorithms, shuffling algorithms, and other algorithms or functions that play a critical role in the final random outcome.” Section 3.2.2 then requires statistical testing of the output after scaling, shuffling, or mapping, which the standard calls the final outcome output. A sound generator feeding a naive modulo reduction produces a biased final outcome, and the chi-square or total distribution test will show it.

All scaling, mapping, and shuffling algorithms used shall be unbiased, as verified by source code review. The discard of RNG values is permissible in this context and may be necessary to eliminate bias. (GLI-19 v3.0, 3.2.3)

The standard names the permitted remedy, rejection sampling by discarding values. Independence under 3.2.4 is the second statistical gate: knowledge of one draw must not reveal information about a future draw, or about other values in the same draw unless the game design provides for it. Seeding, re-seeding, and any state shared between game rounds are the usual places for a dependency to appear.

Game-level logic can also invalidate a clean RNG. GLI-19 requires that events of chance not be influenced by anything other than the values from an approved RNG, and states that the game shall not modify or discard outcomes “due to adaptive behavior.” It also prohibits a game that, after the RNG has selected a losing outcome, substitutes a different losing outcome to create a near miss. A game shall not adjust the likelihood of a bonus based on the history of awards in previous games, and shall not adapt its theoretical return based on past payouts.

The Composite Submission Requirements say the RNG conclusion applies only to the RNG identified through software verification, and “if this identification changes, then the conclusion will no longer be applicable unless the reasons for the changes are examined by GLI.” GLI records key files and their signatures (SHA1, MD5, or SHA256) in the report. It compiles the submitted source and takes digital signatures during compilation, and it requires that the submitted source “shall be final and no longer in test or development.”

The submission must also include the data collection tool and its source, using the same RNG and methods as live game outcomes. GLI warns that it may require hundreds of millions of draws depending on game format, and the document’s worked example calls for a file of 51,000,000 records of five integers drawn from a range of 49. A test harness that calls a different code path from production fails the identity check even when the statistics pass.

Paytable mathematics and RTP discrepancies

The Composite Submission Requirements require calculation sheets (PAR sheets) for each game, determining the theoretical return including base game, double-up options, free games, progressive features, and bonus features. Any feature missing from the sheet is a feature the laboratory cannot reconcile to the artwork. A bonus buy, a gamble feature, or a jackpot contribution added late in development without regenerating the math model leaves exactly that gap.

GLI-19 4.7.1 sets a minimum theoretical payout of 75% for house-banked games during the expected lifetime of the game, unless the regulatory body specifies otherwise. The minimum must be met for all wagering configurations, so a game that clears it at maximum bet but not at minimum bet fails. For games affected by skill, the test applies to optimal play. For progressive jackpots included in the RTP calculation, the minimum must be met “using the lowest available parameters for the jackpot.” Where the regulator specifies a different floor, that figure controls.

Display-side mismatches also fail submissions. Section 4.4.1 requires paytable information and rules of play to be complete and unambiguous and not misleading. The artwork must state how coinciding outcomes are treated, for example whether a straight flush counts as both a flush and a straight. Where a game simulates a live casino game, section 4.6.4 requires the same probabilities as the live game, such as 1 in 38 for any number on a double-zero wheel. If the RTP is displayed, section 4.7.2 requires the artwork to explain how the figure was determined.

GLI-19 Appendix A.6.1 requires the operator to maintain current PAR documentation, to keep records of every change affecting theoretical RTP, and to treat a game as new for all reports and records after any such change. The same provision requires procedures to compare theoretical and actual RTP periodically and to investigate large variances. An operational audit that finds no such comparison process produces a finding independent of the product certificate.

Audit trail and security control gaps

GLI-19 B.3.2 provides that alteration of accounting, reporting, or significant event data “shall not be permitted without supervised access controls,” and requires a log containing a unique alteration ID, the data element altered, the values before and after, the time and date, and the user identification of the person who performed it. Section 2.9.5 requires the system to produce reports for each significant event or alteration with the same before and after values and the identity of the user who performed or authorised it. A database administrator who corrects a record through a back-end script that bypasses the application log creates a gap the laboratory will find.

Section 2.8.8 lists the significant events the system must maintain and back up, including failed account access attempts with IP address, program errors or authentication mismatches, significant periods of unavailability, large wins, adjustments to player balances, changes to personal data, and irrecoverable loss of PII. The record of the game itself carries a unique game cycle ID, the theme and paytable ID, and results of intermediate phases such as gamble or bonus rounds. A paytable ID that is not written into the game record prevents the reconstruction that audit trail requirements exist to enable.

Where reports are stored in an electronic document retention system, GLI-19 requires the system to keep the original and all subsequent versions, a unique signature for each version, and a complete log of who changed a report and when. It must also restrict write access through logical security and provide a full audit trail of administrative user activity.

Security findings come from Appendix B and the service provider assessments in Appendix C. Appendix B.2 requires suspect account handling including administrator notification and lockout or audit trail entry after a maximum of three incorrect authentication attempts. Section B.8.4 requires patching policies agreed with the regulatory body, with patches tested where possible on an environment configured identically to production. Section B.9.1 requires technical security tests on the production environment annually or as the regulator requires, with reports recording scope, assessor name and affiliation, date, findings, recommended corrective action, and the operator’s response. The operator’s response is the element most easily omitted when a penetration test report is filed without management sign-off. Appendix C.2 extends the review to information security management system audits for the operator and its service providers. Teams preparing for those reviews can use our analysis of ISO/IEC 27001 errors in iGaming.

Incomplete submissions and change management lapses

The Composite Submission Requirements require each item submitted for certification to be functionally identical to what will be supplied to the field. Source code must be correct, complete, and able to be compiled, with the compiled result identical to the submitted storage medium or verified as functionally identical by an agreed method. It should be commented in an “informative and useful manner” so a reader without deep platform knowledge can follow it. The submission letter must be on company letterhead and dated within one week of receipt by GLI. System submissions add network design documentation, a list of external and third-party systems with connection methods and controls, and descriptions of player registration, verification, authentication, and protection features.

The Composite Submission Requirements state that “all modifications require re-testing, examination, and re-certification by GLI,” and a modification submission must identify the previously submitted version, describe the change in layman’s terms with test case scenarios, list affected modules, and supply new source code for the entire program. Environmental changes that “in any way change the functionality” of the component under evaluation must be re-certified.

The GLI Change Management Program Guide v1.0 supplies the risk-based alternative where the regulator has adopted it. The Guide classifies changes in section 5.1 as Level 1 (no impact, such as operating system security patches, user changes, and cosmetic front-end updates), Level 2 (low impact, such as firewall rule changes and non-benign changes to non-game-logic components), and Level 3 (high impact on regulated components or reporting). Level 2 and Level 3 changes require at least three business days of advance notice to the regulator and the laboratory that performed the prior certification. If no requirement for additional testing is communicated within that period and the regulator has set no other rules, “passive approval is conveyed.” Testing of changes not certified before deployment must be completed within 90 days of introduction into production, and the regulator alone decides on hardship extensions. The Guide also requires annual full certification of each product operating under a program, unless the regulator specifies otherwise.

The emergency rule in section 6.3 lets a licensee or supplier execute Level 2 or 3 changes immediately to address open threats or liabilities, with notice to the regulator as soon as possible, including the necessity for using the rule. Regulators set their own windows. As of October 2026, the AGLC Internet Gaming Go-Live Compliance Guide (last updated January 2026) requires emergency regulatory fixes to be submitted for ATF certification within five business days of release, and requires regulatory changes to be certified before deployment. Our coverage of the AGLC SRIG framework and the Alberta market opening sets out the wider context for those windows. In practice, a change log that classifies a paytable or RNG-adjacent change as Level 1 or as non-regulatory carries the highest risk, because the GLI Guide’s own Level 1 examples are limited to changes with no impact on regulated components.

GLI-GSF-1 Gaming Information Security Controls Audit v1.1 (copyright 2025) restates the program requirement at the audit level. GIS-9.3 requires version control across software components, source code, and binaries, and a Change Management Log recording the date, nature, and reason for each installation or modification. Section 5 of the CMP Guide specifies that each entry also identify the person authorising the change, the person conducting it, the anticipated release date, and the change level.

What compliance teams should change

Teams should make the following changes before the next submission or release cycle.

Freeze the RNG build and tooling together. Archive the final source, the data collection tool, the compiled binaries, and their SHA256 signatures as a single release artefact, and require a witness build or reproducible build so the laboratory can match the production binary to the tested one. Treat any change to a file listed in the RNG software verification as a Level 3 candidate until the laboratory confirms otherwise.

Generate the PAR sheet from the same configuration that drives the game. Reconcile the sheet, the artwork, the game server paytable ID, and the game record fields on every build, and test the 75% floor, or the regulator’s floor where it differs, at every bet level and line configuration. Add a scheduled theoretical-versus-actual RTP variance review with documented investigation, as Appendix A.6.1 requires.

Route every back-end data correction through a logged, supervised mechanism that captures the B.3.2 fields. Test it by altering a record and attempting to reconstruct the alteration from logs alone. Add management responses to every security test report, and keep the vulnerability assessment, penetration test, and firewall review records together with the patching policy agreed with the regulator.

Map each regulator’s change rules to the Level 1, 2, and 3 classification before go-live. Under the GLI Guide, three business days of silence is passive approval, and under the AGLC guide the same change may need certification before release. Assign classification authority to a named compliance owner rather than the deploying engineer, and record the classification in the change log at the time of the change.

Basis for this article: the author reviewed the relevant provisions of GLI-19 v3.0, the Composite Submission Requirements v2.0, the Change Management Program Guide v1.0, and GLI-GSF-1 v1.1, and compared the change provisions against the AGLC Go-Live Compliance Guide, as of October 2026. No GLI rejection data was available, so frequency rankings are editorial.

Frequently asked questions

What causes a GLI submission to be denied or delayed?

The Composite Submission Requirements state that failure to supply requested information can result in denial of the submission or testing delays. Source code must also be final, complete, compilable, and identical to the submitted media.

Does passing the GLI RNG statistical tests mean the RNG is certified?

No. GLI-19 3.2.1 also requires source code review, and the Composite Submission Requirements say the conclusion applies only to the RNG identified through software verification. A change to a verified file voids the conclusion until GLI examines the reason for the change.

When can a licensee deploy a Level 2 or Level 3 change under the GLI Change Management Program?

Deployment is permitted after at least three business days of notice if neither the regulator nor the laboratory requests testing in that period and no other regulatory rule applies. Testing must then be completed within 90 days of introduction into production. Regulators can impose stricter rules, so confirm the position with the regulator or counsel.

Do audit trail requirements apply after certification?

Yes. GLI-19 Appendix B is reviewed in the operational audit at a frequency set by the regulatory body, and B.3.2 requires logging of every alteration to accounting, reporting, or significant event data in live operation.

Key Resources