Slot Certification Explained: What the Labs Actually Test
Guides · 2026-05-23 · 5 min read · By CROCO Games
What RNG and RTP certification covers under GLI-19-style testing, what a certificate does and does not guarantee, and what to demand from a provider.
A slot certificate is a lab's signed statement that a specific build of a specific game meets a defined technical standard — most commonly that its RNG is statistically sound and its measured RTP matches its stated RTP. It is evidence, not a warranty, and knowing exactly what it covers (and what it deliberately does not) is what separates real due diligence from filing a PDF you never read. This article walks through what accredited labs test under GLI-19-style standards, the boundaries of what a certificate guarantees, and the specific documents to demand before you integrate.
What the labs actually test
Independent test houses — GLI, iTech Labs, eCOGRA, BMM and others — evaluate game software against published standards. GLI-19 is the widely referenced standard for interactive gaming systems; the RNG-specific criteria echo across GLI-11 and jurisdiction rules too. The core of what they examine:
- RNG randomness and unpredictability. Batteries of statistical tests (uniform distribution, independence, no serial correlation) run over huge sample sizes to confirm outcomes are not predictable or biased.
- RNG scaling and mapping. That converting raw random numbers into reel stops or card draws does not introduce bias — a correct RNG can still be ruined by a bad mapping.
- RTP verification. That the simulated and/or measured return over millions of rounds matches the declared RTP within tolerance, for the exact math model submitted.
- Game rules integrity. That the paytable, features and max win behave as the rules screen states, and that the game cannot pay outside its defined range.
- Critical-memory and recovery. That a disconnect mid-feature resolves correctly and the player is not cheated — relevant to Hold and Win and crash rounds especially.
A pass means: on this build, the maths is honest and the randomness is real.
What a certificate does NOT guarantee
This is where operators get complacent. A certificate is narrow by design:
- It does not cover a different build. Certification is per game version and per math model. A 96% build and a 92% build are separately certified; a patched build needs re-testing. The certificate you were shown may not match the binary you are about to run.
- It does not guarantee the game is licensed in your market. Technical certification and jurisdictional approval are different gates. A GLI-certified game can still be unapproved in Ontario, for example.
- It says nothing about the integration. The certificate covers the game; your wallet, session flow and reporting are a separate certification concern (see integration testing below).
- It is not a fairness promise to the player in plain language. "Certified" does not mean "generous" — a certified 92% game is certified to keep 8%. Certification is about honesty of the stated maths, not player-friendliness.
- It does not prove the game is running the certified version in production. That requires build-hash matching and platform controls, not just a PDF.
Treat a certificate as necessary and insufficient. It rules out one class of risk (rigged or broken maths) and is silent on several others.
The document set to demand
Do not accept "our games are certified" as an answer. Ask for specifics and check them:
| Ask for | Why it matters |
|---|---|
| Certificate for the exact build + RTP model you will run | Certs are per-version, per-RTP; the general claim is not enough |
| Name of the accredited lab and standard (e.g. GLI-19) | Confirms it is a recognised house, not a self-assessment |
| Certificate date and version/hash reference | Confirms it matches current production, not a superseded build |
| Jurisdictional approval list | Technical cert is not market licensing |
| RNG description and re-test policy on patches | Tells you whether updates get re-certified |
| Integration/platform certification scope | Covers your wallet and session layer, not just the game |
Certificates are frequently shared under NDA in this industry — that is normal and not a red flag by itself. CROCO's RNG is independently tested with certificates available under NDA; the test is whether a provider will actually produce the matching document for the specific build when you ask, not whether they wave the word "certified" around. A provider who cannot map a certificate to the exact build you are deploying is the one to worry about.
Reading a certificate: the fields that matter
When the PDF arrives, do not just file it — read five fields. The game name and version/build ID must match what you are deploying, character for character. The RTP model must match the variant you selected. The lab and standard should be a recognised house and a named standard (GLI-19, GLI-11, or the jurisdiction's own). The issue date should be recent enough to correspond to the current build, not a two-year-old superseded version. And the scope statement tells you what was tested — RNG only, RNG plus RTP, or full game logic. A certificate that covers "RNG" but not the specific game math is a narrower document than it looks. If any of these five do not line up, go back to the provider before you integrate; a mismatch here is exactly what an auditor will find later.
How certification fits your onboarding
Fold certification into a repeatable onboarding gate rather than treating it as a one-off:
- Pre-integration: collect certificates for every title and RTP model, confirm lab and standard, check dates against current builds.
- Jurisdiction check: cross-reference each game against your licensed markets; a certified game you are not approved to offer is still a violation.
- Integration certification: ensure the platform and wallet integration itself is tested — many jurisdictions certify the operator-provider connection, not just the games.
- Change control: get written commitment that patched builds are re-certified and that you will be notified of version changes.
- Production verification: where your platform supports it, verify the running build matches the certified version.
This gate takes an afternoon per provider and saves you from the two worst outcomes: shipping an uncertified build into a regulated market, or discovering during an audit that your paperwork does not match your binaries.
Key takeaways
- Certification proves the RNG is sound and the measured RTP matches the stated RTP for one specific build and math model.
- It does not prove market licensing, integration soundness, player-friendliness, or that production runs the certified version.
- Demand the certificate for the exact build and RTP you deploy, plus the lab, standard, date and jurisdiction list — not a generic "we're certified."
- NDA-gated certificates are normal; the real test is whether a provider maps a cert to your specific build on request.
- Make certification a repeatable onboarding gate covering games, jurisdiction, integration and change control.