Seed Value Logging and RNG Audit Trails: What Regulators Actually Inspect

RNG certification is the regulatory threshold for market entry. What regulators inspect after go-live is something different: the ongoing logging infrastructure, seeding procedures, monitoring cadence, and audit-trail integrity that collectively prove the certified RNG is still operating as it did on the day the certificate was issued. Compliance teams that treat certification as the end of the RNG obligation, rather than the beginning, are exposed.

This article maps the post-launch RNG obligations under GLI-19 v3.0 (Standards for Interactive Gaming Systems, revised July 17, 2020), GLI-11 v3.0 (Standards for Gaming Devices), the UKGC’s Remote Technical Standards (RTS 7 and 7A), and the jurisdiction-specific logging requirements from the AGCO Registrar’s Standards for Internet Gaming and the AGLC Standards and Requirements for Internet Gaming (SRIG, dated January 14, 2026).

What Is an RNG Audit Trail, and Why Does It Differ From Certification?

Certification, whether performed by Gaming Laboratories International (GLI), BMM Testlabs, or another accredited independent testing laboratory (ITL), validates that an RNG meets statistical and architectural requirements at a specific point in time. The ITL reviews source code, runs statistical test suites, and verifies that the seeding methods, scaling algorithms, and output distributions conform to the applicable standard. Once the certificate is issued, the certification itself does not repeat unless the RNG implementation changes.

An audit trail is different. It is the continuous operational record that regulators use to verify the RNG has remained in its certified state, that game outcomes have been generated and recorded faithfully, and that any configuration changes have been properly documented and authorised. GLI-19 v3.0 is explicit on this point: the operational audit, covering RNG output monitoring among other gaming procedures, “shall be performed at a frequency specified by the regulatory body” as a separate and ongoing obligation from the initial certification.

“The integrity and accuracy of the operation of an Interactive Gaming System is highly dependent upon operational procedures, configurations, and the production environment’s network infrastructure. As such, an operational audit is an essential addition to the testing and certification of an Interactive Gaming System.”

What Does the GLI-19 Operational Audit Actually Inspect for RNG?

GLI-19’s Appendix A (Operational Audit for Gaming Procedures and Practices) is the primary document that regulators and auditors use when reviewing post-launch RNG compliance. The scope covers establishing gaming rules, managing and monitoring games, monitoring RNG output, and reviewing any other objectives set by the regulatory body. Within that scope, the RNG-specific inspection points cluster around four operational areas.

Theoretical versus actual RTP monitoring. Operators must maintain procedures to periodically compare theoretical and actual RTP percentages and to identify, investigate, and resolve large variances. GLI-19 Appendix A section A.6.2 states that this monitoring must occur “on a defined periodic or volume basis as required by the regulatory body.” The purpose is stated in the standard: early detection of abnormal behaviour enabling timely appropriate remedial action. Any abnormality, including actual RTP falling outside the expected range for the period, must result in an error being logged and escalated for investigation. The escalation path is a required procedural document, not simply a practitioner’s discretion.

Independent RNG-to-symbol mapping. Appendix A identifies best practice as including independent mapping between RNG output and game symbols, verifying game symbol usage. While framed as best practice in GLI-19, several jurisdictions have adopted this as a binding requirement through their Minimum Internal Control Standards. Operators subject to those MICS should treat it as mandatory, not advisory.

Disabling and interruption logging. When a game or gaming activity is disabled, the relevant disabling provision in GLI-19 Appendix A requires that an entry be made in an audit log including the date, time, and reason for the disablement. The same section covers interrupted games: established procedures must exist for handling interrupted game states, and the log entry for any interruption must be preserved.

Significant events and alterations reports. GLI-19 section 2.9.5 defines a specific audit artefact for every significant event or alteration to the system. At minimum, each report must capture the date and time of the event, event or component identification, identification of the user who performed or authorised the change, a description of the reason for the change, the parameter value before the alteration, and the parameter value after the alteration. This before-and-after record is what regulators test for completeness. Missing the pre-change parameter value is a common audit finding.

Seed Value Requirements: What Regulators Inspect Beyond Statistical Testing

Why seeding is the highest-risk area of an RNG inspection

The initial statistical testing pass that underpins an RNG certificate does not tell a regulator what happens to the seed on day 200 of live operations. Seed management is an active, ongoing obligation. GLI-11 v3.0 (Standards for Gaming Devices, September 21, 2016), which informs the seeding standards adopted across interactive gaming contexts, addresses this directly: the RNG must not be seeded from a time value alone. The manufacturer must ensure that games will not have the same initial seed, even when powered on or booted simultaneously. Seeding methods shall not compromise the cryptographic strength of the RNG.

GLI-11 further addresses three attack vectors that seeding methods must resist. A Direct Cryptanalytic Attack means that given a sequence of past RNG output values, it shall be computationally infeasible to predict or estimate future values. A Known Input Attack means that it shall be infeasible to determine or estimate the RNG state after initial seeding, specifically prohibiting time-only seeds. A State Compromise Extension Attack means the RNG must periodically modify its state through external entropy, limiting how long any compromise could remain effective.

GLI-19 v3.0 mirrors this architecture for interactive gaming systems, classifying RNGs by type: software-based RNGs derive randomness from a computer-based algorithm without significant hardware randomness, hardware-based RNGs derive randomness from physical events such as electric circuit feedback, thermal noise, or radioactive decay, and mechanical RNGs generate outcomes via the laws of physics. The seeding obligations vary by type, but the prohibition on predictability applies across all three.

What the UKGC’s RTS 7A requires on seeding

The UKGC’s Remote Technical Standards, RTS 7A, requires that for software RNGs, “it should be computationally infeasible to predict what the next number will be without complete knowledge of the algorithm and seed value.” RTS 7A further requires that any forms of seeding and re-seeding used do not introduce predictability, and that any scaling applied to the RNG output maintains the unpredictability qualities required by the standard. These are not certification-stage requirements. They are operational requirements that must be sustained throughout the licence term. UKGC compliance assessments can examine whether a licensee’s operational procedures maintain seed security, independent of whether the original certification covered this point.

“Any forms of seeding and re-seeding used do not introduce predictability” and “any scaling applied to the output of the random number generator maintains the qualities as detailed.”

A practical consequence of RTS 7A that surfaces regularly in compliance reviews: if a licensee changes its RNG seeding mechanism post-certification, even as a software update rather than an architectural change, the updated mechanism must demonstrably maintain the unpredictability properties. A change to seeding logic that was not independently reviewed and logged as a significant event creates an audit gap under both RTS 7A and GLI-19 section 2.9.5.

Game Outcome Logging: The Record Must Match the Device

Beyond the RNG itself, regulators inspect the integrity of the chain between what the RNG produces and what the system records as a game outcome. GLI-19 sets a clear principle for this: except for human error or an error correctable by manual override, at any time during the game, the game outcome data must match the outcome generated by the physical randomness device. Where a discrepancy exists, the physical randomness device’s outcome is considered correct.

The practical inspection implication is that game logs must record game outcome data in a form that allows an auditor to trace from the RNG output to the displayed result. For online casino products, GLI-19’s player-facing game history provision requires that game outcome data be made available to the player immediately following its generation (subject to system processing delays), and the records must support dispute resolution without ambiguity about which RNG output produced which visible game result.

For virtual event wagering products covered by GLI-33 (Standards for Event Wagering Systems, v1.1, May 14, 2019), where the outcome is based solely on an approved RNG, the same principle applies: the log must connect the wagering record to the RNG output in a way that supports post-event reconstruction. GLI-33 section 4.5 covers virtual event wagering requirements, these are supplemental to, not a replacement of, the base RNG audit-trail obligations.

Jurisdiction-Specific Logging Standards: AGCO and AGLC

Regulators in Ontario and Alberta have codified the logging obligations in detail, providing a concrete benchmark for what “appropriate, accurate and complete records” means in practice.

The AGCO Registrar’s Standards for Internet Gaming require continuous logs to be maintained for critical gaming systems, including tracking financial accounting and game state history. Standard 4.02 expands the purpose: records must be kept and made available for ensuring timely investigations by the Registrar, capturing information to continue a partially complete game within a reasonably defined time, resolving disputes fairly and promptly, tracking individual gaming sessions and play information, tracking significant events, and tracking game enabling, disabling, and configuration changes. Standard 4.03 requires a compensating manual control mechanism if logging is interrupted. Standard 4.04 requires the gaming system to be capable of producing custom and on-demand reports to the Registrar.

The AGLC Standards and Requirements for Internet Gaming (SRIG, issued January 14, 2026) applies equivalent requirements for Alberta’s market, which opens July 13, 2026, and adds specific technical mandates for log integrity that go beyond the AGCO text. Under the AGLC SRIG, continuous logs for critical gaming systems must be protected against alteration by either WORM (Write Once Read Many) storage or cryptographic signing with SHA-256. They must be transmitted and stored over TLS 1.2 or higher. Access must be role-based, with segregation of duties between operations and monitoring personnel. The SRIG further requires implementation of a monitoring function, referencing a Security Information and Event Management (SIEM) capability, to correlate and alert on integrity events, with remediation tracked to closure.

Requirement	AGCO (Ontario)	AGLC (Alberta)
Continuous logs for critical gaming systems	Required	Required (SRIG 2026-03-17)
Game state history logging	Required (Standard 4.02)	Required (SRIG 2026-03-17)
Log tamper-protection method	Not prescriptive	WORM or SHA-256 signing required
Transport/storage encryption	Not prescriptive	TLS 1.2+ required
Role-based log access with segregation of duties	Not prescriptive	Required
SIEM / integrity-event monitoring	Guidance only	Required (SRIG 2026-03-17)
On-demand reports to regulator	Required (Standard 4.04)	Required (SRIG 2026-03-17)
Compensating controls if logging interrupted	Required (Standard 4.03)	Required

Operators registered in Ontario who are preparing for the Alberta market will note that the AGLC SRIG is materially more prescriptive on the technical architecture of log protection. AGCO-compliant implementations that do not already use WORM or cryptographic signing for game logs will require engineering changes before Alberta go-live. For a fuller comparison of how the two Canadian standards diverge across all six risk themes, see AGCO vs AGLC: Key Differences in Ontario and Alberta Internet Gaming Regulation.

Software Verification and the Archived Signature Record

The GLI Composite Submission Requirements (v2.0) establish a verification mechanism that persists after certification: GLI records the key files and their respective cryptographic signatures (SHA1, MD5, or SHA256) in the certification report. These signatures identify all software components that affect the RNG for the certified scope of testing. When a new submission involves the same RNG in a different context, GLI uses the archived signatures to verify that the previously tested RNG is indeed the one present in the new system.

This creates an operational obligation that compliance teams must actively maintain. If a supplier updates any component that touches the RNG chain, whether the RNG library itself, the game executable that calls it, or the test wrapper, the archived signatures will no longer match. That mismatch triggers a re-evaluation obligation. In practice, operators who accept game updates from suppliers without confirming that the RNG-touching components have remained signature-consistent are operating in a gap between their certification record and their live system. A regulatory inspection that compares the certified component signatures against the deployed build can surface this gap directly.

RTP Monitoring Procedures as an Audit Trail Category

Does the operator have documented procedures for detecting RTP drift?

Yes, and GLI-19 Appendix A section A.6.2 requires it explicitly. Operators must have written procedures for monitoring game and RNG output on a defined periodic or volume basis as required by the regulatory body. Any abnormality, defined as the actual RTP percentage for the period falling outside the expected range, must result in an error being logged and escalated for investigation. The monitoring interval must be defined in writing, an open-ended “we review when we notice a problem” process does not satisfy the standard.

Regulators reviewing RTP monitoring procedures typically look for four elements: a defined monitoring frequency or volume trigger, a documented threshold for what constitutes an abnormality, an escalation procedure identifying who receives the alert and within what timeframe, and a remediation record showing the investigation was completed. Compliance teams should maintain these as a standalone internal control document, not buried inside a broader IT operations handbook.

What Regulators Find When Audit Trails Are Inadequate

Regulatory inspections of game logging and RNG audit trails typically surface three categories of deficiency. The first is incomplete significant-event records: the alteration is logged but the pre-change parameter value is absent, making it impossible to reconstruct whether the change was authorised within the approved configuration space. GLI-19 section 2.9.5 requires both before and after values.

The second is monitoring without escalation documentation. An operator can demonstrate that RTP was monitored but cannot show that variances triggered escalation or that the escalation was resolved. The GLI-19 standard requires both the error logging and the escalation, monitoring records without a corresponding escalation trail are incomplete.

The third, increasingly visible in jurisdictions that have adopted prescriptive log integrity requirements, is the absence of tamper-evident log storage. Where the AGLC SRIG requires WORM or cryptographic signing, a conventional relational database log without immutability controls fails the technical requirement regardless of what it contains. For MGA licensees, the MGA Technical Infrastructure guidelines require gaming and financial logs to maintain integrity, availability, and traceability at all times, the MGA compliance audit framework tests this through the system audit process covered in detail in MGA System Audit Requirements: What Your Tech Stack Must Document.

Monitoring records without a corresponding escalation trail are incomplete. GLI-19 requires both the error logging and the escalation as distinct, documentable steps.

Practical Compliance Checklist for Ongoing RNG Audit-Trail Obligations

The following reflects the minimum operational posture required across GLI-19 v3.0, the UKGC RTS, and the AGCO/AGLC Standards. Operators should consult qualified legal counsel for jurisdiction-specific application, particularly where a regulatory body has adopted supplemental MICS that go beyond the baseline standards.

Seeding procedures. Maintain a documented seeding specification that records the entropy source or sources used, the re-seeding trigger conditions, and the method for ensuring no two instances of the RNG share an initial seed. This document should be version-controlled, with changes treated as significant alterations under GLI-19 section 2.9.5.

Component signature registry. Maintain a registry of the SHA signature for every software component that touches the RNG chain, cross-referenced against the GLI certification report. Any update to a listed component must be reviewed for certification impact before deployment.

RTP monitoring schedule. Define in writing the frequency or volume trigger for RTP comparison, the abnormality threshold, and the escalation path. The schedule must satisfy whatever periodic or volume-based frequency your regulatory body requires.

Significant-event log completeness. Configure your logging infrastructure to capture parameter values before and after every configuration change, not only the new value. Test completeness quarterly using a sample of recent change events.

Log integrity controls. For Alberta-registered operators, implement WORM or SHA-256 cryptographic signing for all game state and financial accounting logs, with TLS 1.2 or higher for all log transmission paths. Apply role-based access controls with segregation of duties between operations and monitoring teams, and implement SIEM alerting for log integrity events with tracked remediation.

Interruption compensating controls. Maintain a documented manual control procedure that activates if logging is interrupted, as required by both AGCO Standard 4.03 and the AGLC SRIG. The procedure must identify who is responsible for compensating controls and how the interruption period is reconciled in the audit record.

For a broader view of how certification and ongoing compliance intersect across GLI’s standard family, including the scope boundary between GLI-19 and GLI-33 for virtual event wagering products, see GLI-19 vs GLI-33: Choosing the Right Standard for Your Certification Path.

Key Resources

GLI-19: Standards for Interactive Gaming Systems, Version 3.0 (July 17, 2020), available at gaminglabs.com. Primary authority for interactive gaming RNG requirements, operational audit obligations, significant-event reporting, and game monitoring procedures.

GLI-11: Standards for Gaming Devices, Version 3.0 (September 21, 2016), available at gaminglabs.com. Defines seeding requirements and cryptographic RNG attack resistance criteria that inform the interactive gaming standards.

UKGC Remote Gambling and Software Technical Standards (RTS), available at gamblingcommission.gov.uk. RTS 7 and 7A set the game fairness and RNG unpredictability requirements applicable to all UKGC remote gambling licensees.

AGCO Registrar’s Standards for Internet Gaming, available at agco.ca. Standards 4.02 through 4.04 define the game logging and audit-trail obligations for Ontario-registered operators and Gaming-Related Suppliers.

AGLC Standards and Requirements for Internet Gaming (SRIG), issued January 14, 2026 by AGLC Board Chair authority. Sets the most technically prescriptive log integrity requirements in the Canadian market, including WORM/SHA-256 mandates and SIEM requirements.