Game certification is one of the least glamorous parts of launching an online casino, but it is also one of the fastest ways to separate a serious operator from a risky one. Before a slot, crash game, roulette variant, or casino original goes live, someone must be able to prove that the outcome generation is fair, the math behaves as advertised, and the deployed build matches the certified build.
That proof usually comes down to three pillars: RNG documentation, RTP reports, and evidence packs.
For operators using a game aggregator, much of the certification work may sit with the studio or supplier. For operators launching proprietary casino original games, certification becomes a direct product, engineering, and compliance responsibility. Either way, you need to understand the basics well enough to ask the right questions, store the right artifacts, and avoid launching games that cannot survive a regulator, lab, or partner review.
This guide explains what each artifact means, what auditors typically expect, and how to build a practical game certification workflow for a modern iGaming platform.
What game certification actually proves
Game certification is the process of testing and documenting that a game meets technical, mathematical, and jurisdictional requirements. It is usually performed by an independent testing laboratory, such as GLI, BMM Testlabs, iTech Labs, eCOGRA, or another lab accepted by the relevant regulator or licensing authority.
Certification does not prove that a game will be profitable. It does not replace a gambling licence. It also does not remove the operator's responsibility to deploy the game correctly. What it does prove is that a specific game version, configuration, and technical implementation has been reviewed against defined standards.
At a high level, certification focuses on three questions:
- Is the randomness fair, unpredictable, and protected from manipulation?
- Does the game math match the declared RTP, paytable, feature frequency, and volatility profile?
- Can the operator prove which version was tested, approved, deployed, and later changed?
The third point is often where operators struggle. A game can have a valid certificate, but if the deployed build, game ID, RTP variant, or server configuration does not match the certified scope, the evidence may not be enough.
RNG, RTP reports, and evidence packs at a glance
The easiest way to understand certification is to separate the technical artifacts by purpose.
| Certification item | What it proves | Typical reviewer concern |
|---|---|---|
| RNG documentation | Outcomes are generated using a fair, unpredictable, and controlled randomness source | Can the operator or provider manipulate outcomes, predict results, or bias mappings? |
| RTP report | The game math returns the declared percentage over a large theoretical sample | Does the advertised RTP match the actual paytable, reel weights, features, and configuration? |
| Evidence pack | The certified version, reports, approvals, logs, and deployment records are traceable | Can the operator prove that the live game is the same game that was approved? |
Think of RNG and RTP as the game integrity layer. The evidence pack is the operational layer that makes the integrity proof usable during audits, disputes, licensing reviews, and incident investigations.
RNG basics: what auditors want to see
RNG stands for random number generator. In iGaming, the RNG is responsible for producing unpredictable values that are then mapped to game outcomes, such as reel stops, cards, crash multipliers, wheel segments, dice rolls, or bonus triggers.
Most online casino games use a cryptographically secure pseudo-random number generator, usually called a CSPRNG or PRNG. Some systems may use hardware randomness, quantum randomness, or blockchain-based inputs, but the certification question remains similar: can the system produce unbiased, unpredictable outcomes under controlled operating conditions?
The GLI standards library is one common reference point for gaming technical requirements, although each jurisdiction may apply its own rules. The UK Gambling Commission's remote gambling technical standards also emphasize randomness, fairness, and game outcome integrity for remote gambling systems.
Core RNG evidence
For a standard certification review, operators and suppliers should expect to document:
- RNG algorithm and implementation: The name or class of algorithm, how it is implemented, and where it runs in the stack.
- Seeding and entropy controls: How seeds are created, protected, rotated, and isolated from unauthorized access.
- Outcome mapping: How raw random numbers become game outcomes without modulo bias or hidden weighting errors.
- Access controls: Who can access RNG code, configuration, keys, or seed material.
- Statistical testing: Evidence that the output passes appropriate randomness and distribution checks.
- Version control: The specific source version, binary hash, container image, or release artifact tested by the lab.
Statistical tests alone are not certification. A generator can pass randomness tests while still being poorly governed, weakly seeded, or mapped incorrectly. NIST's SP 800-22 statistical test suite is often referenced in randomness discussions, but gaming certification also looks at implementation, security, repeatability, and operational controls.
The mapping problem operators underestimate
Many RNG failures are not caused by the random number source itself. They happen in the mapping layer.
For example, a slot engine may generate a random integer, then map that value to a virtual reel stop. If the mapping logic uses a shortcut that gives some reel positions slightly more probability than intended, the game can drift from its certified math. The same issue can appear in card shuffling, wheel games, crash games, lotteries, or bonus pick games.
Auditors therefore care about the full chain:
- Random value generated.
- Value transformed or bounded.
- Value mapped to an outcome.
- Outcome applied to certified game rules.
- Result recorded in logs for replay or dispute investigation.
If any step is undocumented, certification becomes harder to defend.
RTP reports: what they contain and how to read them
RTP means return to player. A 96% theoretical RTP means that, over a very large number of wagers, the game math is expected to return 96% of wagered value to players and retain 4% as theoretical house edge before bonuses, fees, and operational costs.
RTP is not a promise for a single player session. It is a long-run mathematical property of the game. A player can win heavily on a high-volatility game with 94% RTP, or lose quickly on a lower-volatility game with 97% RTP. That is why RTP reports usually include more than one number.
A proper RTP report may include:
| RTP report field | Why it matters |
|---|---|
| Theoretical RTP | Main long-run return percentage for the certified configuration |
| Paytable | Confirms prizes, multipliers, symbols, side bets, and feature payouts |
| Reel strips or weight tables | Shows how often symbols, stops, or outcomes can occur |
| Feature frequency | Documents bonus rounds, free spins, jackpots, multipliers, and special mechanics |
| Hit rate | Shows how often a wager produces any payout, even a small one |
| Volatility profile | Helps explain session risk, bankroll swings, and promotional exposure |
| Simulation results | Confirms the theoretical math through large-scale modeled play |
| RTP variants | Lists alternate configurations, such as 96%, 94%, or 92%, if allowed |
| Game version and config ID | Connects the math report to the exact build and live deployment |
If you need a deeper operational explanation of RTP, volatility, and hit rate, Spinlab's guide to slot math basics is a useful companion to this certification-focused article.
Theoretical RTP vs live RTP
Operators often confuse theoretical RTP and live RTP.
Theoretical RTP is the certified mathematical return of the game over a long horizon. Live RTP is what actually happens across real player activity during a specific period. Live RTP can deviate materially in the short term, especially for volatile games, jackpots, and low-volume titles.
This matters because an RTP report should not be treated as a live performance dashboard. The report proves the design. Your analytics dashboard monitors actual performance, variance, suspicious deviations, and commercial impact.
A healthy online gambling platform should track both:
- The certified RTP stored against each game version and jurisdiction.
- The live RTP observed across sessions, brands, markets, currencies, and player segments.
When live RTP deviates, the first question is statistical: is the sample size large enough? The second question is operational: has the correct game version and RTP configuration been deployed? Without a good evidence pack, answering the second question can become painfully slow.
Evidence packs: the audit trail behind the certificate
An evidence pack is a structured collection of documents, files, reports, approvals, and logs that proves a game was certified, configured, launched, and changed correctly.
For a single third-party slot, the evidence pack may be relatively simple. For a custom casino original game, especially one using crypto payments, provably fair verification, or unique math, the evidence pack becomes more detailed.
A practical game certification evidence pack should include:
| Artifact | Purpose | Good evidence looks like |
|---|---|---|
| Game specification | Explains rules, player flow, paytable, features, and edge cases | Versioned PDF or repository document approved by product and compliance |
| Math file | Defines RTP, volatility, hit rate, and probability model | Lab-reviewed math report tied to game and config version |
| RNG specification | Documents algorithm, seeding, mapping, and controls | Technical spec, code references, and lab RNG report |
| Source and build identifiers | Proves what was tested and deployed | Commit hash, build hash, container digest, release tag, checksum |
| Certification letter or report | Confirms independent testing outcome | Lab report naming game, version, jurisdiction, and scope |
| Jurisdiction matrix | Shows where the game can be offered | Market list with allowed RTP variants, content restrictions, and launch status |
| Deployment approval | Shows internal sign-off before go-live | Change ticket with product, engineering, compliance, and release owner approvals |
| QA results | Proves wallet, bonus, session, and game launch behavior | Test scripts, pass or fail results, screenshots if needed, defect closure notes |
| Logs and replay data | Supports dispute resolution and investigations | Immutable or access-controlled gameplay, wallet, and outcome logs |
| Change history | Shows what changed after certification | Release notes, recertification decisions, rollback records, approval chain |
The evidence pack should not live in someone's inbox. It should be stored where compliance, product, engineering, and operations can retrieve it quickly, with access control and retention rules.
Third-party games vs original games
Certification responsibilities depend on your game sourcing model.
If you use a game aggregator, the studio or aggregator usually provides certificates, math sheets, game metadata, launch IDs, and allowed territories. Your job is to validate that those artifacts are current, complete, and applicable to your licence and market.
If you build or commission original games, you need to manage a larger share of the certification journey. That includes the math model, RNG implementation, client and server code, security controls, versioning, lab submissions, and recertification after material changes.
For operators using a white label casino platform, this distinction matters during vendor selection. The platform should make it easy to manage game metadata, jurisdiction availability, RTP variants, and operational reporting. Spinlab's modular iGaming platform combines game aggregation, payments, KYC and AML workflows, fraud prevention, analytics, open APIs, and a customizable backoffice, which helps operators keep certification-adjacent data closer to daily operations instead of scattering it across disconnected tools.
How to build a certification workflow before launch
The best time to think about certification is before the game is finished. The worst time is two days before go-live.
A simple certification workflow can look like this:
- Define the certification scope: Identify game type, jurisdictions, RTP variants, supported currencies, bonus compatibility, mobile behavior, and any crypto or provably fair features.
- Freeze the game specification: Lock rules, paytables, feature behavior, edge cases, error handling, and responsible gambling messaging before final lab submission.
- Prepare the math package: Include theoretical RTP, volatility, hit rate, simulation results, jackpot logic if applicable, and all configurable variants.
- Document the RNG chain: Explain generation, seeding, mapping, access control, logging, and any external randomness inputs.
- Create build traceability: Tie source code, compiled build, container image, configuration, and deployment artifacts to immutable identifiers.
- Run integration QA: Test wallet debits and credits, session launch, reconnection, bonus interactions, jurisdiction blocking, mobile UX, and failure states.
- Submit to the lab: Provide complete files, respond to questions, and avoid making undocumented changes during review.
- Store the evidence pack: Centralize reports, approvals, hashes, QA results, jurisdiction rules, and launch records.
- Monitor after launch: Track live RTP, error rates, game launch failures, player complaints, wallet mismatches, and configuration drift.
This workflow is not just for regulators. It also reduces internal confusion. Product knows which game version is approved. Engineering knows which build is safe to deploy. Compliance knows where the reports live. Support can resolve disputes faster.
Treat certification like an operational drill
Certification is partly a documentation challenge. During an audit or dispute, the question is rarely whether a file exists somewhere. The question is whether your team can retrieve the right file, explain it, and connect it to the live system quickly.
That is why many operators benefit from rehearsing evidence collection the same way they rehearse incident response. Compliance and technical teams can borrow practices from emergency management, where documentation, scenario planning, and after-action reviews are core disciplines. Tools such as Preppr's exercise documentation workflow show how structured preparation can turn a complex response process into a repeatable operating habit.
For iGaming, a useful drill might be simple: choose one live game, then ask your team to produce the RNG report, RTP report, certificate, game version, deployment approval, jurisdiction availability, and last configuration change within a fixed time window. If it takes days, your evidence pack process needs work.
Common certification mistakes that create risk
Most game certification problems are preventable. The issues usually come from weak version control, incomplete supplier artifacts, or operational shortcuts after approval.
The most common mistakes include:
- Launching the wrong RTP variant: The certificate covers one configuration, but the live game runs another.
- Treating supplier certificates as universal: A certificate may apply only to specific jurisdictions, versions, or deployment models.
- Changing game math after approval: Even small changes to reels, weights, feature frequency, or payout tables can trigger recertification.
- Ignoring help-screen consistency: Player-facing rules, RTP text, and paytable content must match the certified design.
- Losing build traceability: A lab report is less useful if you cannot prove the live build matches the tested build.
- Mixing bonus economics with game RTP: Bonuses can change promotional cost and player value, but they do not change the certified game RTP unless they alter game outcomes or payouts.
- Failing to capture logs: Without gameplay, wallet, and outcome logs, dispute resolution becomes guesswork.
- Skipping recertification review: UI, platform, math, RNG, and deployment changes should be classified before release to decide whether lab review is needed.
A strong backoffice process should make these mistakes visible before go-live, not after a complaint or regulator request.
What to ask game providers and aggregators
If you are adding games through a game aggregator, your procurement and integration teams should request evidence before launch. Do not wait until a licensing review.
Ask each provider for:
- Current game certificates and lab reports for your target jurisdictions.
- Game IDs, version numbers, release dates, and config IDs.
- Supported RTP variants and proof of which variant is assigned to your brand.
- Math sheets, paytables, volatility labels, and feature descriptions.
- RNG test reports or confirmation of platform-level RNG certification.
- Change notification procedures for game updates and math changes.
- Jurisdiction restrictions, content restrictions, and language availability.
- Incident contacts for game integrity, live issues, and certification questions.
For more on the operational side of adding suppliers, Spinlab's casino game aggregation guide explains what to check across catalog, session launch, wallet callbacks, reporting, and compliance.
Certification and crypto-ready casino games
Crypto-ready casinos add another layer to game integrity. If the game uses a standard certified RNG and only accepts crypto payments, certification may look similar to fiat casinos, with additional controls around wallet, custody, AML, and transaction monitoring.
If the game uses provably fair mechanics, blockchain seeds, commit-reveal schemes, or player seed verification, auditors may expect a more detailed technical explanation. The system should show how server seeds are generated and committed, how player seeds or nonces are handled, how outcomes are derived, and how players can verify results without exposing future outcomes.
Provably fair does not automatically mean regulator-ready. It is a transparency model, not a substitute for secure implementation, unbiased mapping, version control, or jurisdictional approval. If you are working on crypto-forward game mechanics, see Spinlab's guide to provably fair requirements in iGaming for a more technical breakdown.
A practical evidence pack checklist
Before you launch a new game, run this checklist:
| Question | Pass condition |
|---|---|
| Do we have a valid certificate? | Certificate names the correct game, version, supplier, and jurisdiction scope |
| Do we know the live RTP variant? | RTP config is documented, approved, and visible in the platform or provider settings |
| Can we prove build identity? | Release tag, hash, or deployment artifact matches the tested build or approved provider version |
| Are player-facing rules accurate? | Help screen, paytable, RTP display, and terms match the certified math |
| Is jurisdiction access controlled? | Game is enabled only where allowed under licence, supplier terms, and local rules |
| Are logs sufficient for replay? | Gameplay, wallet, session, and outcome events can be retrieved for investigations |
| Is change control documented? | Updates require approval and recertification review where relevant |
| Can support answer disputes? | Support has access to approved explanations and escalation paths |
This checklist should be part of your launch process for every new slot, live casino game, crash game, table game, and custom original.
How Spinlab helps operators stay audit-ready
Game certification is easier when your platform keeps operational data connected. Operators need to manage game aggregation, payments, KYC and AML, fraud controls, wallet activity, player events, and reporting without creating evidence gaps between systems.
Spinlab provides an all-in-one, modular iGaming platform for building, launching, and scaling online casinos. Its crypto and fiat payment support, seamless game aggregation, real-time analytics dashboard, customizable backoffice, open API integration, and compliance tooling help operators build workflows where certification artifacts, game performance, and operational controls can be managed with less friction.
For teams launching original games, certification should be designed into the roadmap from day one. For teams scaling a white label casino platform, certification evidence should be part of provider onboarding and game release governance.
Frequently Asked Questions
Is RNG certification required for every online casino game? In regulated markets, games generally need independent testing or approval according to the relevant jurisdiction's rules. The exact requirement depends on the licence, regulator, game type, and supplier model.
Is RTP the same as house edge? RTP and house edge are related. A 96% RTP usually implies a 4% theoretical house edge before bonuses, payment costs, and other operational factors. Short-term live results can differ significantly.
Can a certified game have multiple RTP versions? Yes, many games support multiple RTP configurations. Each variant must be documented, approved where required, and correctly assigned in the operator's platform or provider settings.
Does using a game aggregator remove certification responsibility? No. Aggregators and studios may provide the certificates, but operators still need to verify that the certificates apply to their jurisdictions, deployed versions, and RTP settings.
Do provably fair crypto games still need certification? Often, yes. Provably fair verification can improve transparency, but regulators and partners may still require RNG, math, security, and operational evidence.
What should be in a game evidence pack? At minimum, include the game spec, math report, RNG report, certificate, version identifiers, RTP configuration, jurisdiction matrix, QA results, deployment approval, change history, and logs needed for dispute resolution.
Build certification into your casino launch process
Game certification is not a one-time PDF. It is a living control system that connects game design, RNG integrity, RTP reporting, deployment discipline, and audit-ready documentation.
If you are evaluating a casino software provider, launching casino original games, or scaling a white label casino with multiple suppliers, make certification evidence part of your platform requirements from the start.
Spinlab's modular iGaming platform helps operators launch faster while keeping payments, game aggregation, compliance, analytics, and backoffice workflows connected. Book a Spinlab demo to see how a flexible, crypto-ready casino platform can support your next game launch without turning certification into a last-minute scramble.