GLI-14 v2.2: What Lottery Suppliers Must Meet for Scratch Ticket and Pull-Tab Certification

GLI Standard #14, Finite Scratch Ticket and Pull-Tab Systems, version 2.2, released September 6, 2011, is Gaming Laboratories International’s primary technical standard for electronic scratch ticket and pull-tab gaming systems operating from finite prize pools. Any supplier seeking entry into a regulated lottery market that mandates GLI certification must demonstrate conformance to this standard across three interconnected domains: the Player Terminal, the Central System, and the reporting and verification infrastructure that ties them together. Understanding what each domain requires, and where the audit-termination and pool-integrity rules create operational constraints, is essential before a supplier enters the certification queue.

What GLI-14 Covers and What It Does Not

GLI-14 v2.2 applies to finite systems: systems in which Electronic Tickets are purchased from a Central System that holds a predetermined, bounded pool of outcomes. The standard defines an Electronic Ticket as “a predetermined winning or losing outcome in electronic form, distributed on-demand from a” finite pool, covering electronic scratch tickets, electronic pull-tabs, and electronic game outcomes. This is structurally distinct from RNG-based online casino games, where each outcome is generated at the moment of play. Under GLI-14, every prize outcome exists before a single ticket is sold, the Central System’s role is randomised distribution, not generation.

The standard explicitly acknowledges adjacent standards. RNG requirements for the Central System cross-reference GLI-11 Gaming Devices in Casinos, adopting its Mechanical and Electro-Mechanical RNG provisions (excluding the Mechanical-Based RNG Games section). Player Terminal metering requirements reference GLI-11 and GLI-12 for progressive device requirements where applicable. Suppliers operating across product lines should map which GLI standards govern which system components before committing to a single certification scope, because a GLI-14 certification of the Central System does not automatically cover a Player Terminal governed by a separate standard.

“Finite systems allow patrons to play at a terminal where Electronic Scratch Tickets, Electronic Pull-Tabs or Game Outcomes, hereinafter ‘Electronic Tickets’, are purchased. The Central System randomly selects the Electronic Ticket from a Game Set and communicates the Electronic Ticket to the Player Terminal.”

What Is the Two-Phase Certification Process Under GLI-14?

GLI-14 v2.2 Section 1.1.2 mandates a two-phase approval process for all finite systems. The standard is explicit: approval requires both phases, and neither alone is sufficient for a complete certification.

Phase one is initial laboratory testing. The testing laboratory assembles the system, with Player Terminals in conjunction with the Central System, and tests integrity in a controlled lab environment. This covers system architecture, software verification, RNG behaviour, physical security controls, metering accuracy, and communications encryption. Suppliers should present a fully operational system, not prototype components, at this stage.

Phase two is on-site certification. The laboratory tests communications, system configuration, and setup at the actual deployment property prior to implementation. This phase verifies that the production environment replicates the conditions tested in the lab and that no configuration drift has occurred between laboratory approval and live deployment. Regulators that mandate GLI-14 typically require phase two sign-off before any Game Set can be activated for patron play.

Game Set Architecture: The Foundation of Pool Integrity

The Game Set is the core structural unit of any GLI-14-compliant system, and its requirements in Section 3.1.4 define the entire pool-integrity model. Each Game Set must comprise a finite number of Electronic Tickets. All Electronic Tickets within a given Game Set must carry the same purchase price. Each Game Set must be assigned a unique serial number. And critically, each Electronic Ticket must have a specific outcome and prize level associated with it before distribution begins.

Once randomisation is complete, Game Sets may be broken into Game Subsets of equal size. If subsets are used, each must carry its own unique serial number. This subdivision is relevant to multi-terminal deployments, where different Player Terminals may be drawing from different subsets of the same parent Game Set.

The standard governs what data must be available and verifiable before a Game Set commences play (Section 3.1.5). This pre-commencement data, which must be maintained and viewable both electronically and in printed reports on demand, establishes the audit baseline against which post-play reporting is reconciled. Suppliers who cannot produce this data on demand at commencement fail this requirement regardless of how accurately their live reporting functions.

The Game Set Auditing Rule: Why Mid-Play Inspection Terminates Play

Section 3.1.8 of GLI-14 v2.2 contains one of the standard’s most operationally consequential provisions. No audit or other determination of the status of a Game Set or Game Subset, including any determination of prizes won or prizes remaining to be won, may be conducted while the Game Set is in play without causing termination of the entire Game Set or Game Subset. Only after Game Set termination may the full details of prizes won and prizes remaining be revealed.

“In order to provide maximum game integrity, no audit or other determination of the status of any Game Set or any Game Subset, including but not limited to a determination of the prizes won or prizes remaining to be won, shall be conducted by anyone while a Game Set or Game Subset is in play without causing termination of the entire Game Set / Game Subset.”

This rule exists to prevent systematic exploitation of prize-distribution knowledge. If prize-remaining data were accessible during active play, an informed actor could use it to time ticket purchases around remaining top-tier prizes. The termination requirement eliminates that possibility by making the cost of inspection equal to the cost of closing the game. In practice, this means lottery operators and their technical teams must design all diagnostic and audit procedures so that they never query live prize-status data without intending to terminate that Game Set. Regulators auditing deployed systems will test whether this control can be circumvented.

Post-completion data requirements are addressed in Section 3.1.7. Once a Game Set closes, the following data must be available, maintained, and viewable on demand: the Game Set and Game Subset serial numbers, the unique name of the Game Set, the total number of Electronic Tickets unsold (if the game was removed from play rather than fully exhausted); the total number of Electronic Tickets purchased, the time and date of completion or removal, the final payout percentage of the Game Set, and the price per Electronic Ticket. This data set forms the evidentiary record for prize payout verification and regulatory reconciliation.

Data Point	Pre-Commencement Required	Post-Completion Required
Game Set and Subset serial numbers	Yes	Yes
Total number of Electronic Tickets in pool	Yes	Yes (sold vs unsold)
Purchase price per ticket	Yes	Yes
Prize distribution structure	Yes	Confirmed final payout %
Time and date of completion or removal	No	Yes
Mid-play prize status (prizes won / remaining)	N/A	Available only after termination

Central System Security: Access Controls and Anti-Tampering Requirements

Chapter 3 of GLI-14 v2.2 sets out the Central System security architecture. Section 3.2.2 requires the Central System to provide a secure physical and electronic means for protecting Game Sets against alteration, tampering, or unauthorised access. Where unopened ticket information has been accessed, the standard requires the system to provide a means of terminating that Game Set, whether triggered automatically or at regulatory discretion.

Data alteration controls are prescribed in Section 3.2.3. The Central System must not permit alteration of any accounting or significant event log information communicated from the Player Terminal without supervised access controls. If financial data is changed, an automated audit log must document the data element altered, its value before and after alteration, the date and time of the change, and the identity of the personnel who performed the alteration by user login. This requirement applies to any retrospective correction, not merely to malicious tampering. Operators who need to correct erroneous accounting entries must do so through the supervised access control path, generating a full audit trail in the process.

Section 3.2.4 requires real-time mirrored backup of Electronic Ticket Game Sets. The Central System must store duplicates of Game Sets already transmitted to Player Terminals, so that a full recovery is possible from the last viable backup point. The standard recommends backup contents include significant events, accounting information, auditing information, and site-specific configuration data including employee files and progressive setup.

Logon Architecture and Password Controls

Section 3.2.8 prescribes the logon architecture for the Central System’s operating system and control programs. The logon must use two-level codes: a personal identification code and a personal special password. The PIN must have a minimum length of six ASCII characters. The special password must also be at least six characters in length and must include at least one non-alphabetic character. Passwords and PINs must be stored in encrypted, non-reversible form (Section 3.2.7). A programme must be available to list all registered users on the Central System together with their privilege level.

Section 3.2.9 governs security levels and access restrictions. The operating system must enforce role-based access such that users can only reach the functions authorised for their privilege level. Important data files must be accessible only by entry of a password known solely to authorised personnel. These requirements align with standard enterprise access control principles, but GLI certification testing will verify them at the system level, not merely as a paper policy.

Encryption Requirements: Communications and Key Management

Section 3.2.6 of GLI-14 v2.2 requires all connections between Central System components to use secure communication protocols employing Data Encryption Standard (DES) or equivalent encryption with changeable seeds or algorithms. All data communication must incorporate an error detection and correction scheme to ensure accurate transmission and receipt. An important exception applies: the same level of encryption is not required between a Player Terminal and its interface component when both are housed within the same physical cabinet or enclosure.

Pay-command communications receive elevated treatment. Section 3.6.1 requires that all communications initiating a Player Terminal pay command employ encryption approved by the regulatory body. The standard specifies minimum key lengths for asymmetric encryption at 1024 bits for public keys (Section 3.6.2). Key exchange must use a secure method. Using the current key set to encrypt the next key set is explicitly prohibited. The standard gives public key encryption techniques as an acceptable method for key transfer (Section 3.6.3). Encryption keys must not be stored without themselves being encrypted (Section 3.6.4).

Player Terminal connections across the entire Finite System must use secure communication protocols employing DES or equivalent encryption with secure seeds or algorithms, as set out in Section 2.2.2. This obligation is not limited to the Central System backbone.

RNG Requirements and Statistical Testing Thresholds

The randomisation requirements for the Central System’s ticket-selection mechanism draw from GLI-11’s Mechanical and Electro-Mechanical RNG Requirements (excluding the Mechanical-Based RNG Games section). The practical testing obligations for GLI-14 finite systems apply the same 99 percent confidence level threshold used throughout the GLI standard family.

Three statistical tests apply. The runs test requires that no card, symbol, number, or position produces predictable patterns, passing at the 99 percent confidence level. Correlation analysis requires that each selection is made independently, without regard to any other selection within the same game play, again at 99 percent confidence. Serial correlation analysis requires that each selection is made without reference to the same position in the previous game play, at 99 percent confidence. These tests apply to the randomisation of Electronic Tickets within a Game Set, which is the mechanism by which the Central System determines the order in which predetermined outcomes are distributed to Player Terminals.

Because outcomes are pre-assigned rather than generated at point of play, the RNG in a GLI-14 system does not create prize levels, it determines distribution order. The testing laboratory’s role is to verify that the shuffling mechanism cannot be predicted or manipulated to control when high-value tickets are distributed.

Player Terminal Requirements: Physical Security and Program Verification

Chapter 2 of GLI-14 v2.2 addresses Player Terminal requirements. Physical security provisions in Chapter 2 require that all control program storage devices, communication controller electronics, and NV memory backup devices be housed within a locked logic area. The logic compartment door must be monitored, and all door open conditions must be recorded in a log with a date and time stamp.

The door requirements provisions of Chapter 2 specify that all external doors must be locked and monitored by door access sensors that detect and report all door openings via audible alarm, on-screen display, or both. The Player Terminal must cease play when any external door is opened. Critically, it must not be possible to insert a device into the Player Terminal that disables a door open sensor when the door is closed without leaving evidence of tampering. The sensor must register an open condition the moment the door moves from its fully closed and locked position.

Nonvolatile backup memory is mandatory. Section 2.2.3 requires each Player Terminal to maintain nonvolatile backup memory, or an equivalent, in a secure compartment for the purpose of storing and preserving a redundant set of critical data that has been error-checked.

Control Program Verification

Section 2.13.1 sets out software integrity verification requirements. For EPROM-based storage, Player Terminals must employ a verification mechanism using at minimum a checksum, though a Cyclic Redundancy Check of at least 16 bits is recommended. For non-EPROM storage, the software must provide a mechanism for detecting unauthorised and corrupt software elements upon any access, preventing execution of those elements. The hashing algorithm must produce a message digest output of at least 128 bits. For alterable media, the system must scan for unintended programs or data and test the media structure for integrity, preventing further play if unexpected data or structural inconsistencies are found. A record of the last ten modifications to any alterable media must be maintained, including the date, time, identity of the component affected, the reason for the modification, and validation information.

Section 2.13.3 requires that Player Terminals have the ability to allow for an independent integrity check of the terminal’s software from an outside source, a requirement applicable to all control programs that may affect terminal integrity. This external verification capability is what enables the testing laboratory to conduct independent software verification during certification.

Reporting Obligations: Electronic Accounting and Prize Reconciliation

Section 3.3 establishes the Electronic Accounting and Reporting framework. One or more Electronic Accounting Systems must be in place to support Finite Game activities. The standard requires Electronic Ticket Game Set reports to be produced, maintained, and viewable on demand, on both a daily and monthly basis.

For active Game Sets, the daily and monthly report must cover all games in play without revealing unused Electronic Tickets or prizes remaining in the Game Set, reinforcing the Section 3.1.8 audit-termination rule at the reporting layer. For completed Game Sets, the report must include: all completed Game Sets, the total number of Electronic Tickets sold and unsold in each completed set, the total prizes paid and remaining to be paid, the Game Set serial numbers, and the total number of Electronic Tickets in each completed set. The standard additionally requires that periodic reports cover amounts of prizes awarded but not yet claimed, prizes for which the redemption period expired during the reporting period, unredeemed game plays and winnings, and expired game plays and winnings.

This reporting structure maps directly to the post-completion data requirements in Section 3.1.7, creating a layered audit trail across three distinct states: the pre-commencement baseline, the active-play period (during which prize status is intentionally withheld), and the post-termination reconciliation. Suppliers building reporting infrastructure for GLI-14 markets must design for all three states distinctly.

Significant Events and Offline Operations

Section 3.6.5 specifies the significant events that must be collected from the Player Terminal and communicated to the Central System for storage. These include power resets or power failures, hand-pay conditions (with the amount communicated to the system); and door openings on any external door accessing a critical area of the Player Terminal.

Offline voucher issuance rules in Section 3.8.2 govern what happens when a Player Terminal loses communication with the Central System. The terminal must not issue more offline vouchers than it can retain and display in its maintained ticket-out log. Before requesting new validation seeds, the terminal must ensure all outstanding offline voucher information has been fully communicated to the validation system. The terminal must request a new set of validation numbers after any power cycle or main door open condition that creates a risk of compromise to the existing seed set. This re-seeding rule prevents replay attacks using validation credentials that may have been exposed during an offline period.

How Jurisdictions Apply GLI-14 in Practice

GLI-14 v2.2 operates as a minimum standard. Regulatory bodies adopting it may, and frequently do, layer additional requirements on top. A jurisdiction may specify minimum and maximum return-to-player percentages for completed Game Sets, a point that GLI-14 itself flags as a regulatory consideration (Section 2.1.3 notes that regulatory bodies should consider key criteria including overall payback percentages for a completed Game Set). The standard deliberately avoids specifying any particular technology, method, or algorithm, explicitly directing readers not to interpret the absence of a technology reference as a prohibition on it.

Lottery markets in North America, including provincial lottery corporations in Canada, have historically required GLI certification for electronic lottery products as a condition of procurement or licensing. The AGCO’s Registrar’s Standards for Internet Gaming and the AGLC’s Standards and Requirements for Internet Gaming both reference accredited testing laboratory certification as a condition of product approval, though the specific GLI standard applied depends on product type. For finite-pool instant game products deployed on terminals, GLI-14 is the directly applicable standard. Suppliers entering markets regulated by the UKGC, MGA, or other European bodies should confirm whether the specific jurisdiction accepts GLI-14 certification as satisfying its own technical standard requirements, or whether a separate approval path applies.

For suppliers building toward multiple regulated markets, the certification strategy question is whether to certify once to GLI-14 and seek mutual recognition, or to pursue parallel certifications where jurisdictions maintain distinct technical requirements. Compliance teams should consult qualified legal counsel and the relevant regulatory body directly before committing to a certification path, as jurisdictional acceptance of GLI certifications is not universal and some regulators impose supplementary requirements not captured in GLI-14 v2.2 itself. The AGCO vs AGLC comparison illustrates how two neighbouring Canadian regulators can diverge on testing laboratory requirements even when both accept GLI-accredited certifications in principle.

The GLI Certification hub provides a broader overview of Gaming Laboratories International’s standard series and how jurisdictional acceptance varies across regulated markets. For suppliers contrasting GLI-14 with standards governing RNG-based online products, the comparison of GLI-19 and GLI-33 sets out the scope boundaries and certification decision framework for interactive and event wagering systems.

Key Resources

GLI Standard #14, Finite Scratch Ticket and Pull-Tab Systems, Version 2.2 (September 6, 2011). Published by Gaming Laboratories International, LLC. The primary technical standard governing all requirements referenced in this article. Available through GLI’s standards library at gaminglabs.com.

GLI Composite Submission Requirements v2.0. Published by Gaming Laboratories International, LLC. Governs the submission process, letterhead requirements, multi-party agreement structures, and jurisdictional approval procedures applicable to GLI-14 certification engagements.

GLI Standard #11, Gaming Devices in Casinos. Cross-referenced by GLI-14 v2.2 for RNG requirements applicable to the Central System’s randomisation mechanism. The Mechanical and Electro-Mechanical RNG Requirements section (excluding Mechanical-Based RNG Games) forms the RNG baseline for GLI-14 systems. To begin your certification journey, contact an accredited testing laboratory that holds GLI-14 approval to schedule a pre-submission consultation and obtain detailed guidance on documentation requirements specific to your system architecture.