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.
Frequently asked questions
Does one certificate cover every RTP variant of a game?
No. Certification is per game version and per math model, so a 96% build and a 92% build are certified separately, and a patched build needs re-testing. Ask for the certificate that matches the exact build and RTP model you intend to deploy, not a general statement that the portfolio is certified.
Is it a red flag when certificates are only shared under NDA?
No, NDA-gated certificates are normal in this industry. The meaningful test is whether the provider will actually produce the matching document for the specific build you are deploying when you ask for it. A provider who cannot map a certificate to your build is the one to worry about.
Does a technical certificate mean the game is legal in my market?
No. Technical certification and jurisdictional approval are separate gates: a GLI-certified game can still be unapproved in a market such as Ontario. Cross-reference every title against your licensed markets, and ask for the provider's jurisdictional approval list alongside the certificate itself.
What should I check when a certificate PDF arrives?
Read five fields before you file it: the game name and version or build ID, the RTP model, the lab and the named standard, the issue date, and the scope statement describing what was tested. If any of them fail to line up with the build you are deploying, go back to the provider before you integrate.
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.
Partner with CROCO Games
A certificate is only useful if a provider can map it to the exact build you deploy. CROCO titles are certified by GLI, BMM, eCOGRA and iTech Labs, and we produce the matching document for the specific build and RTP model you plan to run.
Per-title math documentation — RTP split, hit frequency including below-stake returns, feature cadence and max-win probability — is available under NDA, alongside the jurisdiction list behind 50+ live markets. Start the paperwork before the integration, not during the audit.