GLI-12 Progressive Jackpots v3.0: Certification Requirements and Common Failures

GLI-12: Standards for Progressive Jackpots, Version 3.0, revised January 23, 2026, is the primary technical standard that independent test laboratories (ITLs) use to certify progressive jackpot systems for deployment in regulated gaming markets worldwide. Regulatory bodies in North America, Europe, and emerging markets adopt it in whole or in part as a binding requirement. Suppliers and operators who enter certification without a detailed understanding of its chapter-by-chapter obligations routinely encounter scope disputes, test failures, and market-entry delays that are entirely avoidable. This article maps the standard’s core requirements across pool management, triggering, seed and reset mechanics, multi-site linkage, and the software integrity obligations that account for the majority of certification deficiencies in practice.

Scope and Document Architecture

GLI-12 v3.0 applies to all forms of progressive jackpots and their components, whether internal or external to the Gaming Equipment. The standard covers three distinct system types: jackpots embedded in electronic games (which must also comply with GLI-11: Standards for Gaming Devices for game-level requirements), jackpots in live table games via a Live Game Jackpot System, and Multi-Site Jackpot Systems that link Gaming Equipment across one or more venues to a common jackpot pool. Depending on system architecture, GLI-13: Standards for Monitoring and Control Systems and Validation Systems may also apply where interface elements are used to communicate with an External Jackpot Component.

The standard is explicitly technology-neutral. GLI-12 v3.0, Section 1.2.2 states that the document “shall not be read in such a way that limits the use of future technology” and that technology not mentioned is not thereby prohibited. GLI commits to periodic updates to incorporate minimum standards for new and relevant technology. This technology-neutral posture means that certification scope cannot be resolved by a literal reading of the standard alone, and the ITL evaluates each alternative implementation on a case-by-case basis.

Any regulatory body may adopt GLI-12 in whole or in part. Operators targeting jurisdictions that reference GLI-12 should confirm with their regulatory body whether the adoption is full or partial and whether any jurisdiction-specific overlays apply before engaging an ITL. The AGCO Registrar’s Standards for Internet Gaming in Ontario and the AGLC Standards and Requirements for Internet Gaming in Alberta both cross-reference GLI technical standards as applicable certification pathways, making GLI-12 directly relevant to suppliers seeking access to those markets.

Pool Management Integrity: The Accounting Foundation

Pool management is the financial and accounting core of progressive jackpot compliance. GLI-12 v3.0 Section 2.5.1 requires that the jackpot system be capable of reporting a defined set of parameters on demand. Those parameters include the unique jackpot identifier, the current jackpot payoff, the reset value, the startup value, the increment percentage rate, the ceiling, the secondary increment rate that applies once the ceiling is reached, the diversion pool value and its limit, and any applicable time limits for triggering.

Every one of those values must be reportable on demand, not just at scheduled intervals. Certification testing will verify that the system can produce this data accurately at any point during the test cycle. Systems that cannot generate on-demand parameter reporting, or that calculate any of these values inconsistently across different reporting paths, will fail this requirement.

The ceiling is a distinct concept from the overflow pool. Under Section 2.2.4, once the jackpot payoff reaches its ceiling, it must remain at that value until awarded. All additional contributions received after the ceiling is reached must be credited to an overflow or diversion pool unless the regulatory body specifies otherwise. Where the ceiling is disclosed to the player, the displayed amount must be accurate. Operators who truncate overflow contributions rather than crediting them to a pool have failed a fundamental accounting obligation.

“Diversion pools shall not be truncated. Diverted contributions once that diversion pool has reached its upper limit shall be accounted for.”, GLI-12 v3.0, Section 2.4.5

The diversion pool, governed by Section 2.4.5, adds further complexity. A Jackpot Diversion Scheme may be used to redirect a portion of contributions to a secondary pool intended to fund future jackpot reset values or to cover simultaneous wins. The scheme must be designed so that it does not produce a mathematical expectation of infinity, an important constraint that requires mathematical modelling and documentation before submission to an ITL. Where the diversion pool is used to fund the reset value, the reset value calculation for RTP purposes must assume an empty diversion pool. Mixing these two calculation paths is a recurring source of RTP modelling errors during certification.

Jackpot Triggering: Randomisation and Verification Requirements

What does GLI-12 require for jackpot triggering verification?

GLI-12 v3.0 requires that any RNG used by the progressive jackpot comply with applicable jurisdictional RNG requirements referenced in the standard. For electronic games, this means full compliance with the RNG requirements set out in GLI-11. The standard distinguishes between outcome-triggered jackpots, where the jackpot is awarded on the basis of a specific game outcome, and mystery-triggered jackpots, where the award is based on a random event independent of the game outcome.

Mystery-triggered jackpots that use a hidden trigger threshold are subject to the specific requirements of Section 2.4.6. The hidden trigger threshold must be selected randomly upon initial setup and must be re-selected randomly if the jackpot is not awarded before the previous threshold value is superseded. The re-selected threshold must fall within the range of the current jackpot payoff and the ceiling. Critically, the threshold must not result in a trigger without any new contribution having been made after the modification, a requirement designed to prevent a parameter change from producing an immediate and unearned jackpot win.

This re-randomisation obligation extends to any parameter modification that could cause an immediate trigger. Section 2.5.2 makes clear that when modifying progressive jackpot parameters after player contributions have already been made to the current jackpot, the hidden trigger threshold must be re-selected whenever the modification would otherwise permit triggering without additional play. This interplay between the parameter-change controls of Section 2.5.2 and the mystery-trigger rules of Section 2.4.6 is one of the most technically nuanced areas of the standard and a source of repeated certification deficiencies.

Seed and Reset Requirements

What are the GLI-12 v3.0 requirements for jackpot seed values and post-win reset mechanics?

Under Section 2.4.7, following a jackpot win, the jackpot payoff must update to the reset value and continue normal operations. For electronic games, the jackpot payoff may be added to the player’s credit meter provided that the credit meter is maintained in local currency format, or the jackpot is incremented in whole credit amounts, or the payoff in local currency is properly converted to credits without misleading the player. Where the jackpot payoff cannot be automatically credited, for example because it exceeds a jurisdictional taxation threshold, the game must cease play, display an appropriate message, and require authorised personnel intervention before the player is paid.

The startup value and reset value are distinct parameters. The startup value is the initial jackpot amount, the reset value is the amount to which the jackpot returns after a win, which may differ from the startup value. Section 2.5.1 requires both to be separately reportable on demand. Suppliers frequently conflate these two values in system documentation submitted to ITLs, causing reconciliation failures during parameter verification testing.

Section 2.5.3 addresses jackpot transfers, requiring a secure mechanism for transferring or combining contributions from a decommissioned progressive jackpot, including any associated overflow or diversion pools. The process must cover both error corrections and decommissioning scenarios. A jackpot may be disabled or decommissioned concurrently with a win if the game was configured to automatically disable upon triggering, but the system must document this event and the post-win state precisely.

Multi-Site Progressive Linkage: Architecture and Communications

Chapter 4 of GLI-12 v3.0 governs Multi-Site Jackpot Systems, defined as systems where Gaming Equipment at one or more Gaming Venues is interconnected to share a common jackpot pool, potentially including an Interactive Gaming System component. The architecture typically involves a Central Controller, one or more Local Controllers, and the Gaming Equipment itself.

The Central Controller receives contributions from Local Controllers, increments the current jackpot payoff, and communicates the updated payoff back to Local Controllers at each venue. Local Controllers, in turn, receive contributions from connected games, forward them to the Central Controller, receive the updated payoff, and update local Jackpot Displays. This three-tier architecture introduces multiple points where certification testing must verify that data integrity is maintained end-to-end.

Section 4.3.2 establishes the minimum communication frequency: multi-site jackpot data must be communicated at least once every sixty seconds between the Central Controller, Local Controllers, and Gaming Equipment. The data set that must be communicated at this frequency includes current contribution totals, current jackpot payoff values, and trigger status. Systems that communicate less frequently than this threshold, or that cannot demonstrate compliance with this frequency under test conditions simulating realistic network load, will fail certification.

Section 4.3.1 requires that all jackpot data transmitted between system components employ a reasonable level of cryptography. The communication process must be robust and stable enough to ensure that failure events can be identified and logged for subsequent audit and reconciliation, and it must be protected against the capture of authentication data and against manipulation by unauthorised parties. Alternative cryptographic implementations are reviewed on a case-by-case basis by the ITL, and there is no mandatory algorithm specified, but the standard is clear that bare, unencrypted transmission is not acceptable.

System Component	Primary Role under GLI-12 v3.0	Key Compliance Obligation
Central Controller	Aggregates contributions, increments and distributes jackpot payoff	Must receive meter readings from all Local Controllers in real-time on demand, meter readings must match Gaming Equipment meters
Local Controller	Collects contributions from site games, relays payoff updates to Jackpot Displays	Must synchronise time reference with Central Controller, must disable affected jackpots on communication loss
Gaming Equipment	Records contributions, displays jackpot payoff, handles win condition	Must comply with GLI-11 game requirements, must disable jackpot on External Jackpot Controller communication loss
External Jackpot Display	Player-visible display of current jackpot payoff	ESD-resistant to 8kV air discharge / 4kV contact discharge, must recover without data loss after transient disruption

Section 4.3.4 addresses meter reconciliation for multi-site systems. When the Central Controller requests meter readings, it must receive them from all connected Local Controllers in real-time in an automated fashion. Manual meter reading is explicitly not a substitute for automated real-time collection. The Central Controller’s meter readings must be identical to those of the Gaming Equipment connected to each Local Controller. Any discrepancy between these meter sets is a reconciliation failure and must be treated as such in the system’s error handling logic.

Section 4.3.3 addresses the specific scenario of a trigger event occurring during a polling cycle. Contributions received by the system after the trigger occurs in real-time but within the same polling cycle are deemed to have contributed to the winning jackpot payoff. Contributions received after the trigger message is received, or registered after the trigger message arrives even if they were sent before it, are credited to the next jackpot. This contribution-attribution rule must be correctly implemented in the system’s trigger-event handling logic, as it is a common source of reconciliation disputes during certification testing.

External Jackpot Controller: Software Integrity Requirements

Chapter 3 of GLI-12 v3.0 governs the External Jackpot Component, including software validation, hardware security, and error-condition handling. Under Section 3.6.2, the External Jackpot Controller must verify that all critical components are valid each time the software is loaded for use and upon recovery from a program interruption. Critical components include progressive jackpot functionality, communications control elements, and any other components essential to proper jackpot operation.

The authentication mechanism must employ a hash algorithm producing a message digest of at least 128 bits. If authentication fails, whether due to a program mismatch or a signature failure, the External Jackpot Controller must cease operation and satisfy the error-condition requirements set out in Section 3.6.6. Alternative test methodologies for program verification will be reviewed on a case-by-case basis, but submitting an implementation with a sub-128-bit hash without prior regulatory body approval is an automatic certification failure.

“The External Jackpot Controller shall verify that all critical components contained in the External Jackpot Controller are valid each time the software is loaded for use and upon recovery from a program interruption.”, GLI-12 v3.0, Section 3.6.2

Section 3.6.6 enumerates the error conditions that must trigger jackpot disable and player notification. These conditions are: loss of communications with all participating Gaming Equipment, program error or signature mismatch, critical non-volatile (NV) memory error, which must also cause all external communication to cease, jackpot configuration lost or not configured, unreasonable contribution detected, where such detection is supported, and controller meters failing to reconcile against Gaming Equipment meters, where reconciliation is supported. All error conditions must be communicated to a Gaming System where a compatible system and protocol are in use.

Critical non-volatile memory, defined in the standard’s glossary as memory storing all data vital to continued jackpot operation, carries its own layered requirements. Section 3.6.7 requires that after a program interruption, the External Jackpot Controller must be able to recover the last known jackpot values from critical NV memory, restore normal operations from that point, and communicate the recovery event to connected Gaming Equipment. Any system that cannot demonstrate reliable NV memory recovery under simulated power-interruption conditions will not pass certification.

Audit Logging and Reporting Obligations

GLI-12 v3.0 imposes detailed audit-trail requirements that apply both to the jackpot controller level and to Multi-Site Jackpot Systems. Under Section 3.6.8 (jackpot records), the system must maintain a record per jackpot that includes the jackpot identifier, creation date and time, game and paytable identifiers, current parameter values, the full history of trigger events with timestamps and user identifications, current status, and a complete log of every parameter change with before/after values and the identity of the user who performed and authorised each change.

Section 4.4.2 extends these obligations to multi-site systems. The system must be capable of producing summary reports showing the current jackpot payoff and the basis for it, aggregate reports showing contributions and payoff history, and life-to-date reports showing total contributions, total payoffs, and net amounts. Reports must carry the provider name, report title, selected interval, and generation date and time. Where no activity exists for the selected period, the report must indicate “No Activity” or an equivalent message.

Section 4.1 recognises that for Multi-Site Jackpot Systems, the ITL may test components in a controlled lab environment but that the overall integrity of the system depends heavily on production-environment network infrastructure and operational procedures. Regulatory bodies may therefore elect to require periodic operational audits against Minimum Internal Control Standards (MICS) and technical security assessments against the GLI Gaming Security Framework (GLI-GSF). Suppliers must treat initial ITL certification as a necessary but not sufficient condition for ongoing compliance in jurisdictions with MICS or GLI-GSF mandates.

Common Certification Failures: What Goes Wrong

Based on the technical requirements of GLI-12 v3.0, certain failure patterns recur across certification engagements. These are direct consequences of misreading or inadequately implementing specific provisions of the standard.

The most common category of failure involves parameter-change controls in combination with mystery-trigger mechanics. Suppliers implement the hidden trigger threshold correctly at initialisation but do not re-randomise the threshold when subsequent parameter changes are made, or re-randomise it without verifying that the new threshold falls within the range of the current payoff to the ceiling. Section 2.5.2 is explicit on both points, and ITL testing will exercise this scenario directly.

The second common failure area is diversion pool accounting. Systems that truncate contributions once the diversion pool reaches its upper limit, rather than accounting for the excess, fail Section 2.4.5. A related error is the use of a non-zero diversion pool value in RTP calculations when the section requires RTP to assume an empty diversion pool where the diversion pool funds the reset value. Both errors result in mathematical inconsistencies that cannot be resolved without a re-submission.

Audit log incompleteness is a persistent issue. The parameter-change log required by Section 3.6.8 must capture before and after values for every parameter, not just the final state. Systems that overwrite prior values rather than maintaining a full change history cannot demonstrate the audit trail the standard requires. This is frequently discovered only during the record-inspection phase of testing, after functional testing has already passed.

For multi-site systems, the most common failure involves meter reconciliation. The 60-second communication cycle of Section 4.3.2 is rarely the problem, the failure is typically that Central Controller meter totals do not match the sum of Gaming Equipment meters under high-load or network-partition test scenarios. Where the implementation does not support automated real-time meter collection, any manual reconciliation process presented as a substitute will be rejected under Section 4.3.4.

Software authentication failures round out the most frequent deficiency categories. Systems submitted with a hash algorithm producing fewer than 128 bits, or with an authentication routine that does not execute on program recovery as well as on initial load, fail Section 3.6.2. The ITL evaluates the authentication mechanism as part of software approval, and a hash algorithm change post-submission requires a new submission and restarts the testing clock.

“A regulatory body may elect to require the following operational audits and assessments be conducted on a periodic basis: an internal controls audit, against the applicable controls identified in the regulatory body’s Minimum Internal Control Standards, and/or a technical security assessment, against the applicable controls and tests identified in the GLI Gaming Security Framework.”, GLI-12 v3.0, Section 4.1

Jurisdictional Adoption and Regulatory Overlay

GLI-12 v3.0 is adopted by regulatory bodies across multiple regulated markets, but the manner and extent of adoption varies. Suppliers must confirm with each target jurisdiction whether the regulatory body has adopted GLI-12 in full, in part, or with jurisdiction-specific modifications before beginning certification. Common overlays include additional RTP floor requirements for progressive jackpots, mandatory disclosure obligations for jackpot odds or qualifying wager thresholds, and maximum jackpot ceiling values.

The UKGC’s Remote Technical Standards (RTS) impose game fairness and RNG requirements that overlap with GLI-12’s randomisation obligations. Suppliers certified under GLI-12 for markets in North America cannot assume that GLI-12 certification satisfies all UKGC RTS obligations, as the RTS must be independently satisfied. Similarly, jurisdictions accepting MGA licensing under Malta’s Gaming Act (Cap. 583) assess game and jackpot system compliance through the MGA’s own technical review process, which may reference GLI-12 as a benchmark but does not accept GLI certification as a substitute for MGA approval. According to iGaming Business, New Zealand’s recently published online gambling regulations specifically limit network progressive jackpots to licensed platforms, illustrating how jurisdiction-specific restrictions continue to be layered on top of foundational GLI-12 requirements.

For suppliers entering the Ontario market under the AGCO Registrar’s Standards for Internet Gaming, or preparing for the Alberta market opening under the AGLC Standards and Requirements for Internet Gaming, compliance teams should map GLI-12 certification deliverables against those jurisdictions’ specific game integrity and reporting obligations early in the product development cycle. The GLI Certification hub provides additional context on how GLI standards interact with North American regulatory requirements. For a direct comparison of Ontario and Alberta requirements, see AGCO vs AGLC: Key Differences in Ontario and Alberta Internet Gaming Regulation.

Suppliers considering both the GLI-12 certification path and the broader question of which GLI interactive gaming standard governs their platform architecture should also consult GLI-19 vs GLI-33: Choosing the Right Standard for Your Certification Path, which covers how progressive jackpot obligations under GLI-12 interact with GLI-19 system-level requirements for interactive gaming platforms.

Qualified legal counsel familiar with the specific target jurisdiction should be engaged to identify all regulatory overlays before certification scope is finalised with the ITL. GLI-12 v3.0 sets the technical floor, the regulatory body sets the operational ceiling. To begin your compliance journey, download the full GLI-12 v3.0 standard from Gaming Laboratories International or contact an accredited ITL to discuss your system’s certification roadmap.

Key Resources

GLI-12: Standards for Progressive Jackpots, Version 3.0 (January 23, 2026), Gaming Laboratories International, LLC. Available free of charge at gaminglabs.com.

GLI-11: Standards for Gaming Devices, Governs game-level requirements applicable to electronic games offering progressive jackpots, cross-referenced throughout GLI-12 Chapter 2.

GLI-13: Standards for Monitoring and Control Systems and Validation Systems, Governs interface element requirements where Gaming Equipment communicates with External Jackpot Components, referenced in GLI-12 Section 3.4.1.

GLI Gaming Security Framework (GLI-GSF), The technical security assessment framework that regulatory bodies may require for Multi-Site Jackpot System periodic audits, referenced in GLI-12 Section 4.1.