GLI-13 v3.0: Casino Management System Certification and Monitoring Control Requirements Explained

GLI-13: Standards for Monitoring and Control Systems and Validation Systems, Version 3.0, revised July 31, 2024, is the primary technical standard governing casino management system (CMS) certification across regulated gaming markets worldwide. Compliance teams preparing a CMS for submission to an independent test laboratory (ITL) must satisfy requirements across five substantive chapters: system architecture, control program integrity, real-time monitoring, validation system obligations, and interface element specifications. This article maps those obligations to the operational decisions that determine whether a certification engagement succeeds or stalls.

Scope and Purpose of GLI-13 v3.0

GLI-13 applies to Monitoring and Control Systems, Validation Systems, and the Interface Elements that connect Gaming Equipment to those systems. The standard defines a Monitoring and Control System as the hardware, software, firmware, communications technology, and associated operator procedures used to continuously monitor Gaming Equipment via a secure communication protocol, primarily tasked with logging, searching, and reporting of significant events, financial data collection, and meter reconciliation.

The standard’s stated objectives, articulated in Chapter 1, set the analytical frame for every subsequent requirement. GLI-13 v3.0 aims to ensure that gaming is fair, secure, auditable, and able to be operated correctly. It explicitly distinguishes between laboratory testing obligations and operational internal controls, noting that the evaluation of internal controls such as anti-money laundering, financial, and business processes is not incorporated into laboratory testing. Those controls are addressed through jurisdiction-specific Minimum Internal Control Standards (MICS) audits conducted separately.

“To establish a standard that will ensure gaming is fair, secure, auditable, and able to be operated correctly… [and] to recognize that the evaluation of internal controls (such as anti-money laundering, financial, and business processes) employed by operators should not be incorporated into the laboratory testing of the standard. Instead, these should be addressed within operational audits performed for local jurisdictions.”, GLI-13 v3.0, Section 1.2.1

This demarcation matters operationally. CMS suppliers frequently receive audit findings on AML transaction monitoring or source-of-funds controls that properly belong in the MICS review, not the GLI-13 certification. Understanding the boundary prevents scope disputes with the ITL and ensures compliance teams route findings to the correct remediation workstream.

What Does GLI-13 Certification Actually Cover?

GLI-13 certification applies to the Monitoring and Control System and Validation System components submitted to the ITL. Where a supplier uses a previously certified Modified Off-The-Shelf (MOTS) component, certification is required only for the modifications made to that component, unless the regulatory body requires otherwise. The ITL may also conduct on-site testing, at its discretion or at the regulatory body’s request, where Gaming Equipment and communications are set up prior to or during implementation.

Beyond component certification, regulatory bodies may require periodic operational audits. Section 1.5.2 identifies two types: an internal controls audit against the jurisdiction’s MICS, and a technical security assessment against the GLI Gaming Security Framework (GLI-GSF). Adherence to the GLI-GSF, which covers vulnerability and penetration testing of external and internal infrastructure, is strongly recommended for all Monitoring and Control Systems and Validation Systems. The GLI-GSF is available free of charge from GLI’s website.

For a broader overview of the GLI certification landscape and how individual standards fit into the certification process, the GLI Certification hub provides context on jurisdictional acceptance and submission pathways.

Gaming System Architecture: The Data Integrity Foundation

Chapter 2 of GLI-13 v3.0 establishes the foundational architecture requirements for any Gaming System submitted under the standard. The requirements govern the relationship between servers, front-end processors, data collectors, and the Gaming Equipment they serve.

Section 2.4.2 sets the core data integrity rule: each database must maintain a user audit trail that is safeguarded against unauthorised access, ensuring the integrity and security of data across all levels of the system. The requirement applies not only to the system’s front end but also to any underlying database, a point that catches suppliers who harden the application layer but leave the database tier inadequately protected.

Section 2.4.3 addresses the Front-End Processor and Data Collectors. Where the Front-End Processor maintains buffered or logged information, a secure mechanism must be in place to prevent loss of critical data. All received data must be stored on the databases before the system may purge data from the Front-End Processor, the connected Data Collectors, and the connected Gaming Equipment. This sequencing rule prevents data loss during a purge cycle and is one of the most commonly misconfigured aspects of CMS architecture in pre-submission testing.

Control Program Verification and Authentication

Section 2.3 addresses verification of critical control program components. The CMS must be capable of verifying that all critical control program components are authentic copies of the approved versions on demand. The verification mechanism must employ a cryptographic hash algorithm producing a message digest of at least 128 bits. All critical control program components that may affect gaming operations are within scope, including executables, libraries, gaming and system configurations, operating system files, components controlling required system reporting, and database elements affecting system operations. Where verification fails, the system must provide an indication of the failure.

Section 2.3.2 adds a further layer: each critical control program component must also support an independent third-party verification procedure. This third-party process must operate independently from the system’s own verification mechanism. The certification evidence pack must document both the internal hash-verification mechanism and the external third-party pathway, and both must be demonstrably functional in the production-equivalent test environment presented to the ITL.

Interface Elements carry the same requirements at Section 5.3. Where authentication fails at the interface, the Interface Element software must cease operation and, where possible, display an appropriate error message. That error condition must also be communicated to the connected system where a compatible system and protocol exist.

User Access Controls and Session Management

Section 2.4.4 specifies user access control requirements for Gaming System workstations. Sessions must time out or lock up after a period of inactivity, requiring the user to re-establish their login. For mobile workstations, the inactivity period must not exceed two minutes unless the regulatory body specifies otherwise. User accounts are automatically locked out after three successive failed active access attempts in a thirty-minute period, or a period set by the regulatory body. Where supported, the system may automatically release a locked-out account after thirty minutes.

Section 2.4.5 requires the Gaming System to uniquely identify each connected instance of Gaming Equipment. The unique identification number must be used to log and track all essential information pertaining to that equipment. The system must also prevent duplication of these identification numbers to preserve the integrity and accuracy of equipment tracking. Section 2.4.6 requires the system to generate alerts for any communication loss with connected Gaming Equipment.

Control Area	GLI-13 v3.0 Requirement	Minimum Threshold
Cryptographic verification	Section 2.3.1	128-bit message digest minimum
Mobile workstation timeout	Section 2.4.4	2 minutes (unless regulator varies)
Account lockout trigger	Section 2.4.4	3 failed attempts within 30 minutes
Data sequencing	Section 2.4.3	Data stored to DB before buffer purge
Equipment ID uniqueness	Section 2.4.5	No duplication permitted
NV memory backup	Section 5.4.2	Recovery capability required

Significant Event Logging and the Audit Trail

Section 2.5 defines what must be captured in system significant event logs. The categories cover failed user account access attempts including location information, program error or signature mismatch, significant periods of unavailability of any critical component, system voids, overrides and corrections, changes to live data files occurring outside normal program execution, changes to policies and parameters for operating systems, databases, networks, and applications, changes to the date and time on the master time server, and irrecoverable loss of sensitive information. Regulatory bodies retain the discretion to expand this list.

Section 2.5.3 governs user account information to be maintained and backed up for each account, including the unique user account ID and username, sufficient to support regulatory review of who did what and when.

Significant Events and Alterations Reports under Section 2.6.2 require a specific data structure for each event: date and time of the event, event or component identification, identification of the individual who performed or authorised the change, reason and description, the data or parameter value before alteration, and the data or parameter value after alteration. This before-and-after structure is the operational backbone of regulatory traceability for CMS configuration changes.

Reporting Requirements: What the System Must Produce

Section 2.6.1 establishes general reporting requirements. Reports must be producible on demand and for intervals required by the regulatory body, including day-to-date (DTD), month-to-date (MTD), year-to-date (YTD), and life-to-date (LTD). Each required report must contain the operator’s name or identifier, the report title, the selected interval, and the date and time the report was generated. Where no activity exists for the specified period, the report must display an explicit “No Activity” or equivalent message, rather than simply returning a blank output.

The Gaming Equipment Asset Registry (GEAR)

Section 3.4.2 requires the Monitoring and Control System to include a Gaming Equipment Asset Registry (GEAR), which maintains a database record for each piece of Gaming Equipment in operation. The required fields include the unique Interface Element or asset ID, the unique Gaming Equipment ID or description including serial number and manufacturer, the date and time the equipment was made available for use, the gaming venue name and site identifier for multi-venue deployments, equipment location description, type of Gaming Equipment, and equipment configuration data covering peripherals, communications, and progressive jackpots.

For Electronic Games specifically, the GEAR must also record game configuration data including game themes, paytables, and denominations, and the theoretical return to player (RTP) for each game theme and paytable. This RTP field is directly relevant to regulatory reporting obligations: in jurisdictions where the regulator requires reporting against an approved paytable schedule, the GEAR is the system of record that links individual device activity back to the approved configuration.

Machine Entry Authorization Logs (MEAL)

Section 3.4.4 addresses the Machine Entry Authorization Log. Where a Monitoring and Control System supports automated recording of Gaming Equipment entry, the MEAL must capture the unique Gaming Equipment ID of the equipment entered, identification of the individual who entered, date and time of entry, duration of entry, reason for entry, and activity while entered including any changes made. The MEAL provides the audit chain that supports regulatory investigation of physical access events at the device level, complementing the electronic audit trail in the database tier.

Validation System Obligations

Chapter 4 covers Validation Systems, which handle wagering instrument issuance and redemption. The standard establishes detailed requirements for wagering instrument information, issuance conditions, redemption validation, and cashier session reporting.

Section 4.5.2 requires the Validation System to identify and notify the Cashier Station of invalid or unredeemable wagering instruments, covering three specific conditions: the instrument cannot be found on file or has expired, it has already been paid or voided, or the value differs from the amount on file. Each of these conditions must generate a notification rather than a silent failure.

Section 4.7 covers Validation System reporting. For meter reconciliation under Section 4.7.2, the system must be capable of producing reports reconciling each Gaming Equipment’s metered voucher-in, voucher-out, coupon promotion-in, and coupon promotion-out figures against the Validation System’s recorded amounts. This reconciliation capability is a direct prerequisite for satisfying the financial reporting and revenue verification requirements imposed by regulatory bodies in jurisdictions that mandate GLI-13 compliance.

The cashier summary and detail report requirement under Section 4.7.4 is equally detailed. For each cashier session, the report must capture the unique Cashier Station ID, the user account ID or cashier name, session start and end times, cashier balances at session start and end, and for each wagering instrument transaction within the session: a unique transaction ID, transaction type, wagering instrument type, transaction value in local monetary units, and date and time of the transaction.

“Each database shall maintain a user audit trail that is safeguarded against unauthorized access, ensuring the integrity and security of data across all levels of the system.”, GLI-13 v3.0, Section 2.4.2

Interface Element Requirements: Non-Volatile Memory and Communications

Chapter 5 governs Interface Elements, the devices or facilities connecting Gaming Equipment to the broader Gaming System. Section 5.4 addresses critical Non-Volatile (NV) memory. Where an Interface Element relies on locally stored critical NV memory, it must include a backup or archive capability allowing recovery after a failure. The system must not have any mechanism by which an error or unauthorised user can cause loss of locally stored critical NV memory. NV memory errors must be identifiable through the storage methodology implemented.

GLI-13 v3.0 explicitly notes that alternate storage media, including hard disk drives, are not precluded by these requirements, but they must maintain critical data integrity in a manner consistent with the NV memory requirements as applicable to the specific storage technology.

How CMS Certification Connects to Regulatory Reporting Obligations

The relationship between GLI-13 certification and a jurisdiction’s regulatory reporting framework is direct but layered. Certification confirms that the system architecture can produce the required data in the required formats. The regulatory reporting obligation itself is set by the regulatory body’s rules, which reference the certified system as the source of truth. Where regulators require real-time or near-real-time reporting of gaming activity, the communication loss alert requirements of Section 2.4.6 and the data sequencing rules of Section 2.4.3 are the technical backbone of that reporting chain’s reliability.

Operators entering Ontario under the AGCO Registrar’s Standards for Internet Gaming, or those subject to MGA technical infrastructure requirements, will find that the GLI-13-certified system sits at the intersection of multiple regulatory requirements. The CMS provides the financial metering data that flows into regulatory financial reporting, the audit trail that supports AML-related internal control reviews, and the equipment configuration records that support responsible gambling controls such as verified RTP disclosure. Compliance teams building their pre-go-live evidence packs should treat the GLI-13 certification scope as the first layer, then map the jurisdiction’s specific reporting mandates on top of it.

The GLI-GSF: The Security Layer That Sits Alongside Certification

Section 1.3.3 of GLI-13 v3.0 addresses the GLI Gaming Security Framework as a strongly recommended complement to CMS certification. The GLI-GSF defines technical security controls including operational process reviews, vulnerability and penetration testing of external and internal infrastructure, and testing of applications handling sensitive information. Where a regulatory body elects to require a technical security assessment, it will typically run this against the GLI-GSF controls.

Suppliers and operators who defer GLI-GSF alignment until after initial certification frequently encounter it as an unplanned requirement in their first post-certification regulatory audit. Conducting a GLI-GSF gap assessment during the certification preparation phase is more cost-efficient than retrofitting controls after the fact.

Configurable Features and the Operator-Supplier Interface

Section 1.4.2 addresses the practical tension between configurable system features and certification scope. Monitoring and Control Systems may be developed with configurable features, the final configuration depends on options chosen by the operator. Because it may not be possible to test all configurable features in the absence of the operator’s final configuration, the configuration to be used in the gaming production environment must be communicated to the ITL to allow creation of a functionally equivalent test environment.

Suppliers who submit a system for certification before the operator has finalised its configuration risk a partial certification that does not cover the live deployment. The operator’s chosen configuration, including progressive jackpot settings, promotional parameters, and cashless integration, must be confirmed and communicated before the test environment is constituted. Delays at this handover stage are among the most common causes of extended certification timelines. Compliance professionals overseeing multi-jurisdiction rollouts should factor configuration lock-down as a formal milestone in the certification project plan, timed before ITL submission rather than concurrently with it.

“The configuration that will be utilized in the gaming production environment shall be communicated to the independent test laboratory to facilitate creating a functionally equivalent test environment.”, GLI-13 v3.0, Section 1.4.2

Relationship to Adjacent Standards: GLI-12, GLI-16, and GLI-18

GLI-13 does not operate in isolation within the GLI standard series. GLI-16: Standards for Cashless Systems and Technologies v3.0 explicitly requires cashless systems to meet the general reporting requirements within GLI-13 as a baseline, with additional cashless-specific requirements layered on top. Operators integrating a cashless wallet or electronic funds transfer capability into their CMS must certify both the GLI-13 Monitoring and Control System layer and the GLI-16 Cashless System, with the GLI-13 general requirements forming the foundation of both.

GLI-12: Standards for Progressive Jackpots v3.0 similarly sits adjacent to GLI-13, with the External Jackpot Controller subject to its own authentication requirements and the jackpot balancing and status reporting requirements feeding into the broader CMS reporting framework. GLI-18: Standards for Promotional Systems in Casinos v2.1 references GLI-13 directly for its audit trail requirements, requiring Gaming Devices with promotional features to recall audit information for at least the last twenty-five promotional transactions received from the system.

For compliance professionals choosing a certification path for a new gaming platform, the GLI-13 scope is typically the starting point for land-based and hybrid casino deployments, while GLI-19 governs pure online and interactive gaming systems. The relationship between those two standards, and the decision criteria for choosing between them, is covered in detail in our analysis of GLI-19 vs GLI-33: Choosing the Right Standard for Your Certification Path.

Operational Checklist: Pre-Submission Readiness Under GLI-13 v3.0

The following obligations represent the technical and procedural items most frequently raised in pre-submission gap assessments. Each traces directly to a numbered provision of GLI-13 v3.0.

The cryptographic verification mechanism must employ a hash algorithm producing a minimum 128-bit message digest, and must cover all critical control program components including executables, libraries, configurations, OS files, reporting components, and database elements (Section 2.3.1).

An independent third-party verification pathway must exist for every critical control program component, operating independently from the system’s own verification mechanism (Section 2.3.2).

All received data must be stored to the database before the system purges data from the Front-End Processor or Data Collectors. The buffering mechanism must be secured against critical data loss (Section 2.4.3).

Each database must maintain a user audit trail safeguarded against unauthorised access, covering all levels of the system (Section 2.4.2).

Mobile workstation sessions must time out within two minutes of inactivity, and accounts must lock after three failed attempts within thirty minutes (Section 2.4.4).

The GEAR must record the unique ID, RTP configuration, equipment type, location, and significant event history for every connected Gaming Equipment instance (Section 3.4.2).

Significant event and alteration records must capture before-and-after parameter values, the identity of the person who made or authorised the change, and the date and time (Section 2.6.2).

Reports must be producible on demand and at all required intervals (DTD, MTD, YTD, LTD), with explicit “No Activity” notation for empty periods (Section 2.6.1).

Interface Element NV memory must have backup and recovery capability, must resist loss from errors or unauthorised access, and must support error identification in storage (Section 5.4).

Operators and suppliers who have aligned their MGA-licensed platforms against the MGA system audit requirements will find significant overlap in the audit trail and data integrity principles, but GLI-13 is a laboratory-certification standard rather than a licensee-audit framework, and the two processes must be managed as distinct workstreams. Qualified legal and regulatory counsel with jurisdiction-specific expertise should be engaged before finalising the certification scope and regulatory reporting architecture for any new market entry.

Key Resources

GLI-13: Standards for Monitoring and Control Systems and Validation Systems, Version 3.0 (revision date July 31, 2024), the primary document governing CMS certification. Available free of charge at www.gaminglabs.com.

GLI Gaming Security Framework (GLI-GSF), strongly recommended companion framework covering technical security controls, vulnerability testing, and penetration testing. Available free of charge at www.gaminglabs.com.

GLI-16: Standards for Cashless Systems and Technologies, Version 3.0, applies alongside GLI-13 for operators integrating cashless functionality. Available at www.gaminglabs.com.

GLI-12: Standards for Progressive Jackpots, Version 3.0, applies alongside GLI-13 for progressive jackpot controllers and reporting. Available at www.gaminglabs.com.

GLI-18: Standards for Promotional Systems in Casinos, Version 2.1, references GLI-13 for audit trail requirements covering promotional transactions. Available at www.gaminglabs.com.