RNG certification for casino games typically costs $5K–$25K per game per jurisdiction (4–12 weeks), rising to $40K–$120K+ for full platform RNG plus game suite certification across multiple jurisdictions (16–36+ weeks). Lab fees are separate from $8K–$40K of engineering work audit logs, deterministic replay, version control, math documentation that must be in place before submission.
RNG certification is the review process where an independent testing lab checks whether a casino game's random number generator produces fair, unpredictable, and unbiased outcomes for the target market. In most regulated real-money gambling markets, operators must show that game outcomes are random and technically compliant before launch or during product approval. Gaming Laboratories International (GLI) describes RNG testing as checking for non-predictability and absence of bias across statistically significant output samples.
Certification cost and timeline depend on the game type, number of target markets, source-code review needs, and whether the product is new or an update to an already-certified game. For example, a single-market slot game is usually much simpler to certify than a multi-market live dealer platform.
Who this guide is for
- Game developers preparing a product for lab submission
- Operators planning a real-money launch in one or more regulated markets
- Product and compliance teams estimating cost, timeline, and documentation scope before briefing a lab
RNG Certification: Cost and Timeline at a Glance
These are planning ranges, not fixed lab quotes. Actual certification fees depend on the selected testing laboratory, target jurisdiction, game complexity, documentation quality, and whether source-code review is required.
| Scope | Lab fees (approx.) | Timeline |
|---|---|---|
| Single slot or table game, one jurisdiction | $5K – $15K | 4 – 8 weeks |
| Table game with complex rules, one jurisdiction | $10K – $25K | 6 – 12 weeks |
| Multi-game series, single jurisdiction | $15K – $40K | 8 – 16 weeks |
| Single game, multiple jurisdictions (EU) | $20K – $60K | 10 – 20 weeks |
| Full platform RNG + game suite certification | $40K – $120K+ | 16 – 36+ weeks |
| Variation / update to certified game | $3K – $12K | 2 – 6 weeks |
Lab fees are separate from the engineering work needed to make a game ready for certification - such as audit logs, deterministic replay, version control, testing evidence, and documentation - which can add $8K–$40K before lab submission. See the online casino software development cost guide for full platform cost context.
What Drives RNG Certification Scope?
How Game Type Affects Certification Requirements
| Game type | RNG certification focus | Typical lab effort |
|---|---|---|
| Slot games | Reel outcome distribution, symbol probability, bonus trigger frequency, paytable accuracy | Low–Medium |
| Blackjack / card games | Shuffle algorithm, card dealing sequence, split/double edge cases, payout matrix | Medium |
| Roulette | Pocket distribution, zero handling, bet lockout enforcement, multi-variant payout tables | Medium |
| Baccarat with road maps | Shoe shuffle, third-card drawing matrix, side-bet math, commission logic | Medium–High |
| Poker variants | Deck shuffle, hand evaluation logic, wild card rules, progressive jackpot trigger | Medium–High |
| Live dealer front-end | Result transmission integrity, bet timer enforcement - physical RNG is at the studio level | Varies |
| Instant-win / virtual sports | Pre-generated outcome pools, draw frequency, prize pool distribution | Medium |
Live dealer games typically certify the physical studio RNG and dealing procedures separately from the front-end software. A front-end integration with a certified live dealer provider has different documentation requirements than a full stack certification.
RNG Certification Scope Estimator
Answer four questions to get a planning range for lab fees and timeline, and to identify which factors will have the biggest impact on your certification budget.
RNG Certification Scope Estimator
Four questions - about 60 seconds
What are you certifying?
How many jurisdictions require certification?
Is source code review required?
Is this a new certification or an update to a certified product?
The RNG Certification Process: Step by Step
Pre-submission preparation
Implement audit logging, deterministic QA mode, and version locking before contacting a lab. Labs typically expect a stable, version-locked build for formal review. Submitting while major features are still changing can create re-test cycles and delay certification.
Lab selection and pre-submission meeting
Select an approved lab for the target jurisdiction - GLI, BMM, eCOGRA, iTech Labs, NMi, or QUINEL depending on the market. Most labs offer a pre-submission consultation to identify documentation gaps before the formal submission clock starts.
Technical documentation package
Compile the RNG specification document, math model report, system architecture description, integration documentation, and build instructions. For source-reviewed submissions, add the annotated source code package and test vectors. Missing documents are the single most common cause of timeline delays.
Statistical and functional testing
The lab runs statistical tests (NIST SP 800-22, chi-square, and lab-proprietary suites) across typically 10 million to 1 billion simulated outcomes. Functional testing verifies that every rule branch, payout condition, and edge case in the game engine behaves as documented.
Source code review (if required)
The RNG module - or the full codebase - is reviewed for algorithmic soundness, seed handling, absence of predictability vectors, and correct implementation of the documented logic. Findings are returned as defects requiring resolution before the review closes.
Defect resolution and re-test
Labs return findings. Each defect must be resolved, documented, and re-submitted for verification. Critical findings can extend timelines by several weeks. Teams that address known issues before submission avoid most of this cycle.
Certificate issuance
The lab issues a test certificate (or equivalent) covering the specific build, version, and jurisdiction. The certificate is typically submitted to the regulator as part of a licence application or product approval process.
Ongoing compliance and variation management
Any change to the RNG, payout tables, or rule logic after certification constitutes a variation. Significant variations require re-submission. Operators and developers must maintain a version-locked change log and notify the lab before deploying changes to certified builds.
RNG Documentation Requirements
Incomplete documentation is the leading cause of delayed certifications. Prepare these before engaging a lab.
| Document | What it covers | Required for |
|---|---|---|
| RNG specification | Algorithm description, seed generation, seeding frequency, entropy source, PRNG type | All submissions |
| Math model / game math report | RTP calculation, payout table, probability model, theoretical house edge per bet type | All submissions |
| System architecture document | Server and client component map, data flow, RNG integration point, security controls | All submissions |
| Deterministic replay specification | How any past outcome can be reproduced from the stored RNG seed and game state | All submissions |
| Audit log specification | Structure of game event logs - fields, timestamps, tamper detection, retention policy | All submissions |
| Source code package | Version-locked, annotated source for the RNG module or full codebase | Source-review jurisdictions |
| Test vectors | Known input/output pairs demonstrating correct RNG and game logic behaviour | Source-review submissions |
| Variation report | Delta description, affected components, and testing evidence for post-certification changes | Variation submissions |
| Integration documentation | API contracts, wallet event specifications, session handling, and platform connection details | Platform or aggregator submissions |
Certification Labs and Standards
The right lab depends on the target jurisdiction. Some regulators maintain an approved list; others accept certificates from any ISO 17025-accredited lab. The UKGC approved test houses list is one example of a jurisdiction-maintained approved lab register.
| Lab | Common jurisdictions | Notes |
|---|---|---|
| GLI (Gaming Laboratories International) | US states (NJ, PA, MI), MGA, many others | Largest lab by market coverage; approved across most regulated US states |
| BMM Testlabs | MGA, AGCO, many Asia-Pacific markets | Strong in Australia, Canada, and Asian markets |
| eCOGRA | UKGC, MGA, Gibraltar | Strong in UK and European markets; also offers player dispute resolution |
| iTech Labs | UKGC, MGA, Curacao, many emerging markets | Competitive pricing for single-market certifications |
| NMi Gaming | Netherlands (KSA), Belgium, UKGC | Commonly used in the Netherlands and Western Europe; confirm current KSA-recognized inspection body requirements before submission |
| QUINEL | Italy (ADM), Eastern Europe | Commonly used for Italy and parts of Europe; confirm current ADM-recognized test house requirements before submission |
Key technical standards applied
- NIST SP 800-22 - statistical test suite for RNG output
- ISO/IEC 17025 - lab competence accreditation standard
- GLI-11 - standard for gaming devices (US)
- GLI-19 - standard for internet gaming systems
- MGA/CRP/121 - MGA technical standards
- UKGC Remote Technical Standards (RTS)
- AIS 31 - statistical testing standard (European labs)
- FIPS 140-2/3 - cryptographic module validation (US)
Jurisdiction Requirements and Their Impact on Timeline
| Jurisdiction | Regulator | Key technical requirements | Commonly used / jurisdiction-accepted test houses |
|---|---|---|---|
| New Jersey (US) | DGE | GLI-11/19, source code review, field inspection for some equipment | GLI, BMM |
| Pennsylvania (US) | PGCB | GLI-11/19, full technical standards review | GLI, BMM |
| Michigan (US) | MGCB | Similar to NJ/PA; GLI standards | GLI |
| Malta (MGA) | MGA | MGA technical standards, ISO/IEC 17025-accredited testing, game/RNG/RTP review depending on product scope | eCOGRA, iTech, BMM, GLI |
| United Kingdom | UKGC | Remote Technical Standards, independent audit, LCCP compliance | eCOGRA, iTech, NMi, GLI |
| Netherlands | KSA | Strict RTP and session data rules; confirm current KSA-recognized inspection body requirements before submission | Check current KSA-recognized test house list |
| Gibraltar | GRA | ISO 17025 lab; lighter source review for established operators | eCOGRA, iTech |
| Curacao | Curacao Gaming Authority (CGA) | LOK framework for online gaming licensing and supervision; confirm current technical requirements before submission. | Check CGA requirements |
Jurisdiction requirements change. This table reflects general market conditions and is not legal or regulatory advice. Confirm current approved test house lists and technical standards directly with the regulator and your chosen lab before submission. For example, UKGC Remote Technical Standards (RTS 7) sets out random outcome requirements for UK-licensed remote games.
Multi-jurisdiction certification does not mean running the same test twice. Standards differ at the technical detail level - RTP ranges, log retention periods, session data requirements, and source code obligations vary by market. Budget for jurisdiction-specific documentation even when using the same lab. For a detailed US-specific checklist, see the US iGaming compliance checklist.
What Increases Certification Cost and Timeline?
- Full source code review required
- Multiple jurisdictions with different standards
- Complex rule engine (baccarat, poker variants)
- Multiple side bets with separate math models
- Platform-level certification across a game suite
- Incomplete documentation at submission
- Defects found during lab review (re-test cycles)
- RNG module not separated from game logic
- Deterministic replay not implemented before submission
- Progressive jackpot with cross-game contribution
- No prior certification history with the lab
- Codebase still in active development at submission
Common RNG Certification Mistakes
Submitting before the build is stable. The version submitted to the lab should match the release candidate or be clearly version-controlled against the build intended for launch. Labs typically expect a stable, version-locked build for formal review. Teams that submit while major features are still changing can create unnecessary re-test cycles.
Not implementing deterministic replay before submission. The ability to reproduce any past outcome from stored seed and state is a baseline requirement for most jurisdictions. Adding it after the architecture is finalised is expensive.
Using a non-approved lab for the target jurisdiction. Certificates from labs not on the regulator's approved list are not accepted. Verify the approved lab list for each jurisdiction before engaging a testing partner.
Treating multi-jurisdiction certification as one submission. Each jurisdiction has different technical standards, documentation formats, and potentially different approved labs. A single certificate does not transfer between regulators without separate review.
Incomplete math model documentation. The math model report must cover every bet type, every payout condition, and every edge case - including zero and tie handling in table games. Gaps in the math report are a common cause of lab questions, rework, and submission delays.
Deploying changes to a certified game without variation review. Changing payout tables, adding side bets, or updating the RNG library without notifying the lab and undergoing variation review puts the operator's licence at risk.
Mixing RNG and game logic in a single non-separable module. Labs review the RNG component specifically. If the RNG is tightly coupled to the rest of the game logic with no clear boundary, the scope of the source code review expands significantly.
Not accounting for certification timeline in the launch schedule. Certification is often underestimated during launch planning. If lab review is not scheduled early, it can become a launch blocker. An 8–16 week lab cycle needs to start long before QA finishes.
Questions to Answer Before Certification
- Which jurisdictions require certification at launch?
- Which labs are approved in each target jurisdiction?
- Is source code review required or optional?
- Is this a new submission or a variation?
- Is the RNG module separable from game logic?
- Is deterministic replay implemented?
- Is the math model documented for every bet type?
- Are audit logs structured and version-locked?
- Is the build version-locked and stable?
- Is there a variation management plan post-certification?
- Is certification on the launch project plan with its own timeline?
- Who owns the lab relationship and documentation package?
Building Certification-Ready Games From the Start
Certification planning is easier when RNG separation, audit logging, deterministic replay, and math documentation are considered during architecture and development, rather than added immediately before lab submission.
For RTP design, math validation, and how theoretical return is tested during development, see RTP in casino games. If you are planning a custom casino game that needs RNG documentation, math model validation, audit logging, or lab-review preparation, explore our certification-ready casino game development services.
