Random number generator (RNG)

A random number generator decides which outcome a game produces. It does not decide what that outcome pays, and the separation between those two questions runs through every technical standard covering both.

What an RNG does in a casino game

An RNG produces the unpredictable value a game converts into a reel stop, a card, a dice face or a roulette pocket. Everything downstream — the paytable, the theoretical return, how often a bonus round triggers — is game design applied to that value.

Two families are in use. A pseudo-random number generator is a deterministic algorithm: given the same internal state it produces the same sequence, so its unpredictability rests on the state staying secret and the algorithm being computationally infeasible to invert. A hardware RNG derives values from a physical process, and often supplies entropy to a software generator rather than serving outcomes directly.

Seeding, reseeding and why the source matters

Because a PRNG is deterministic, its seed and running state are the attack surface. GLI-19, the Gaming Laboratories International standard for interactive gaming systems, requires the RNG determining game outcomes to be cryptographically strong — resistant to an attacker with modern computational resources who may know the source code. It requires that the RNG “shall not be seeded from a time value alone”, that games not share an initial seed, and that the RNG “periodically modify its state, through the use of external entropy” to limit the duration of any state compromise.

RTS 7, the UK Gambling Commission’s standard for random outcomes, states the same properties in outcome terms: uniform distribution across the entire output range; unpredictability such that it is “computationally infeasible to predict what the next number will be without complete knowledge of the algorithm and seed value”. No repeated output stream and no synchronisation between two instances; and no seeding or reseeding that introduces predictability.

Hardware generators carry a failure mode software ones do not. Because a physical source can deteriorate independently of the platform, GLI-19 requires dynamic monitoring of hardware RNG output by statistical testing, and requires that monitoring to disable game play when malfunction or degradation is detected.

Mapping a number to an outcome

Raw generator output is rarely in the form a game needs, so it is scaled, shuffled or mapped onto the set of possible results. That step is certified alongside the generator itself. GLI-19 requires all scaling, mapping and shuffling algorithms to be unbiased as verified by source code review, and requires the final outcome to be tested against the intended distribution. The Commission’s testing strategy treats a mapping fault as a consumer-harm risk distinct from a faulty generator.

Independence and the ban on compensated games

RTS 7A states that adaptive behaviour — a compensated game — is not permitted, ruling out automatic or manual interventions that change outcome probabilities during play. RTS 7B follows through on the game side: numbers are to be used in the order received and may not be discarded because of adaptive behaviour, with discards permitted only where a number falls outside the expected range and only with an error logged and investigated. RTS 7C carries the principle into presentation, prohibiting designs that may reasonably be expected to mislead a customer about the likelihood of results, including substituting a losing event with a near-miss losing event.

GLI-19 sets the equivalent requirement on the generator: knowledge of numbers chosen in one draw shall not provide information on numbers chosen in a future draw, the RNG shall not discard or modify selections based on previous selections except where the game design provides for it, and the final outcome shall be tested for independence between draws.

How RNGs are certified

Certification happens before release and is carried out by an approved third party rather than declared by the supplier. The UK Gambling Commission requires:

• remote licence holders to submit game and RNG test results through its games register;
• testing by an approved test house;
• satisfactory testing and report submission before a game is released for play.

Its testing strategy sets the scope: review of RNG documentation, research into publicly known weaknesses in the algorithm or hardware, source code review against that documentation, and statistical testing of both raw output and scaled or shuffled data.

GLI-19 names the tests a laboratory may draw on — total distribution or chi-square, overlaps, coupon collector’s, runs, interplay correlation, serial correlation and duplicates. GLI-19 requires the applied tests to be evaluated collectively at a 99% confidence level, with the laboratory selecting appropriate tests case by case.

RNG, RTP and volatility

The RNG supplies the outcome. Return to player is the theoretical percentage of stakes a game returns across a very large number of rounds, set by the paytable and the outcome probabilities a designer configures. Volatility describes the shape of that return — frequent small wins against rare large ones.

A certified RNG says nothing about how generous a paytable is, and a high RTP says nothing about the generator beneath it. Two slots can run on the same RNG, publish the same RTP and behave entirely differently. Gross gaming revenue is what the configuration produces across actual play, converging on the theoretical hold over volume rather than matching it in any single period.

Provably fair is a different guarantee

Provably fair systems answer a different question from certification and do not replace it.

The mechanism is commit-reveal. The operator generates a secret server seed and publishes its SHA-256 hash before play. The player contributes a client seed, and a nonce increments with each bet on that seed pair. Outcomes derive from hashing those inputs together, commonly HMAC-SHA256 keyed with the server seed over a client seed and nonce message. Once the seed cycle closes the server seed is revealed, and anyone holding the original hash can confirm the match and recompute every outcome in the cycle. Provably fair covers the verification steps.

What that proves is narrow. It shows the server did not change its seed after seeing the bets, and says nothing about whether the seed came from a sound entropy source or whether the mapping from digest to result is unbiased — the questions source code review and statistical testing exist to answer.

FAQ

Bottom line

Every property an RNG is required to have — uniform distribution, unpredictability, independence, unbiased mapping, no adaptive behaviour — is a testable claim, and the testing happens before release rather than in production monitoring. What certification does not reach is the paytable that turns those outcomes into a return, which is why RNG questions and RTP questions have separate answers.