An actual public document makes that boundary easier to see. On 28 May 2024, iTech Labs certified a generator supplied by Formulaspin OÜ. Its one-page certificate describes statistical tests, scaling for slots and a fingerprint of the tested code. It does not name a casino operator or list a catalogue of certified games. iTech Labs, Formulaspin RNG certificate, May 2024
We read that document and the laboratory and regulatory materials below on 3 October 2026. It is a historical example of how to read a certificate, not our verification of any casino's current software or recommendation to use it.
Read what the laboratory actually tested
The Formulaspin document says the generator passed Marsaglia's diehard statistical tests and underwent slot scaling tests with samples sufficient for statistical power. It also says the code was fingerprinted. The PDF does not print a software version or the fingerprint itself. Nor does it identify the algorithm beyond describing it as well known, or disclose the numerical sample size. Its standards references are dated February 2021.
Those omissions limit what a reader can establish from this page. They do not prove that the laboratory's fuller records lack those details or that the supplier's software is defective. The certificate itself cautions that laboratory testing cannot cover every possible scenario.
The distinction between deliverables is visible in iTech Labs' own resources: an RNG and scaling certificate, an RNG-and-game certificate, an audit using server logs, platform certification and integration certification are separate services. The company describes source-code evaluation and tests of raw, scaled or shuffled outputs. Reading “RNG” as shorthand for all those services would erase the scope the lab took care to separate.
Random numbers still need a game around them
An RNG supplies values. Software then converts those values into outcomes: reel positions, cards or another game's possible results. That conversion is often called scaling or mapping. The paytable determines what those results pay. Each step can raise a different testing question.
Great Britain's RTS 7 randomness standard requires statistical randomness to a high degree of confidence, unpredictability and scaling that preserves the required properties. It separately requires the game to implement its published rules and payouts. Adaptive behaviour that changes outcome probabilities during play is prohibited within this standard's scope.
Uniformly distributed raw numbers do not mean every prize must be equally likely. The same standard distinguishes the generator's output from game outcomes, which should follow their expected theoretical probabilities. A rare prize can be part of a correctly implemented game. A failed payout calculation cannot be dismissed just because the underlying generator passed a randomness test.
The Commission's testing strategy, Approach, assigns distinct checks to the RNG, game mathematics and software, and live performance. The following is our reading guide to those layers, not a reproduction of the Formulaspin certificate or a claim that it covers every row.
| Object being checked | Method or evidence | Version boundary | What the result cannot establish alone |
|---|---|---|---|
| Raw RNG output | Statistical analysis of generated values | The identified RNG implementation | Correct prizes in every game |
| Scaled or mapped values | Tests of the conversion into game inputs, where included in scope | The tested mapping and use | A different conversion not examined |
| Game rules and payouts | Mathematics, source-code and gameplay checks | The specified game and configuration | Continued correct operation after deployment |
| Live game performance | Monitoring of actual play records | The operating game and observed period | A particular player's expected result |
For the third and fourth rows, our separate account of casino games monitored after launch follows the operational work. Here the narrower task is to establish which row a particular certificate supports.
The missing link is often software identity
The Commission's testing procedure expects an RNG report to identify the test house, date and certificate reference, describe the RNG and its use, record the software or hardware version and digital signature, and set out the scope, tests, limitations and results. Its game-report requirements separately include the game, RTP, software version and signature, platform and channel.
A digital signature in this context helps identify the tested files. The attractive design of a certificate cannot perform that matching job. Our report on casino-game version differences describes the identifiers a familiar lobby title leaves out.
GLI makes the software-identity boundary explicit in its Composite Submission Requirements, version 2.0. The document is dated 23 March 2020; the 2022 folder in its URL is not its revision date. Its RNG section combines code review, statistical analysis and software verification. Pages 9–10 say the conclusion applies to the RNG identified through verification, with key files and their signatures recorded. A changed identity needs examination before that conclusion can be carried over. This is GLI's submission guidance, not a GLI certificate for the Formulaspin product tested by iTech Labs.
From a public summary alone, we cannot match an unprinted fingerprint to a casino's deployed software. That is an evidence gap for the reader, rather than a finding about what the operator has or has not done.
An update does not have one automatic consequence
Neither “the certificate is old” nor “the game still has the same name” resolves the status of a changed product. What changed matters.
The Commission's major and minor update guidance requires external retesting for changes that may affect fairness, including RNG, mapping or underlying game rules. It contrasts these with updates that do not affect fairness, such as certain sound or artwork changes. Its examples also warn that apparently visual fixes can cross that boundary; doubtful cases should be discussed with the original lab.
An old date therefore invites a version question, not an invented universal expiry period. A new graphic does not necessarily require the whole mathematical product to be certified again. A changed prize calculation should not inherit assurance merely because its artwork stayed familiar.
For covered British licence holders, the Commission's games test-report guidance requires satisfactory testing and submission before release, and an up-to-date games register. Consumer operators using a supplier still have to maintain their own register. A public certificate linked by a website is not a substitute for that release record. These British requirements should not be presented as identical rules for every casino jurisdiction.
Ask a question the certificate can answer
If a casino points to a lab document, begin with its issuer, date and named subject. Is it an RNG component, a game, an integration or something else? Follow the reference to the original source where possible. Then look for the version, intended use, test scope and any limitations. A summary may leave questions that require the operator or supplier's fuller records; this does not mean those records are publicly accessible on demand.
For a disputed payment, identify the game, round and amount instead of relying on a general fairness badge. Our reporting on online-slot underpayments and player refunds addresses confirmed faults and the British remediation process. Losing play alone does not establish such a fault.
The documents examined here assess software and testing duties. They do not establish an operator's financial position, predict a customer's winnings or confirm how a named casino will handle a withdrawal. For a specific game or round, a report is useful only once its subject can be matched to the software involved.
