RNG and Fairness: How Online Casinos Are Tested
For informational purposes only. Gambling involves risk. 18+/21+ depending on your jurisdiction.
“That slot feels hot.” Here is what the lab saw weeks before you spun
You sit at home. The reels flash. A neighbor in chat hits a bonus twice. It feels like the game is “hot.” That rush is real. But your feeling is not evidence. The truth lives far from the lobby, inside a test lab, under bright lights, with scripts, logs, and long runs of numbers.
Before a game goes live, an independent lab pulls the random engine apart. It tests the math, the code, and the build. It asks: do the numbers look like fair noise? Does the return to player (RTP) match the model? Is the version locked and traced? Only when the answers are “yes,” a certificate goes out. Only then can a regulator allow the release.
This guide shows what is under test, how labs prove it, and what you can check yourself in minutes.
RNG vs. RTP vs. volatility: the three pillars
An RNG (random number generator) picks numbers to drive game outcomes. RTP is the long-term average payback of a game. Volatility is how bumpy wins feel on the way to that average. These three are related, but they are not the same thing. The RNG must be random. The math model must align with the stated RTP. Volatility is a choice by the game designer, not a sign of trickery.
Labs test several layers. They test the RNG library and its seed rules. They test the compiled build and lock its hash. They read logs. They compare the math model to big sample runs. They also check the game client’s info page. If the client says 96.2% RTP, the math needs to show 96.2% within a tight margin.
All of this sits under rules set by regulators. For example, the UK’s Remote Technical Standards lay out technical standards for randomness, game fairness, display of RTP, and change control.
Inside a test week: what labs do and why it matters
Day one is intake. The supplier sends source or a locked binary. The lab checks signatures, hashes, and a change log. If the build is not the one that math was done on, testing stops. Every piece must match the submission list.
Labs themselves must be held to a high bar. Good labs hold ISO/IEC 17025 accreditation, which covers how they run tests, train staff, and manage tools. This does not test a slot. It tests the testers. It means methods are sound and repeatable.
Next come statistics. The lab runs long streams from the RNG and checks them with suites like the NIST SP 800-22 test suite. These include frequency, runs, serial correlation, and more. The goal is simple: the stream should not show patterns that a fair source would not have. The lab sets a significance level (often 1%). It logs p‑values. If a test fails, the RNG is not okay until the root cause is fixed.
There are also domain standards for iGaming. Many labs and markets use GLI documents. GLI‑11 covers slots and their math, meters, and error states. GLI‑19 covers interactive systems. You can read the scope at the GLI-11 standard page.
Finally, the lab compares the game’s claimed RTP and pay table to a math model. It runs billions of simulated rounds or uses closed-form math where possible. It checks that outcomes match hit rate, feature frequency, and jackpot logic. It writes a report with the version, the test steps, dates, and limits. The report sits behind the seal you see on many casino sites.
Myth vs. Fact
- Myth: “Slots get hot or cold.” Fact: Spins are independent. Streaks are normal noise. A run does not predict the next spin.
- Myth: “Casinos can tweak wins by hand.” Fact: Live builds are under change control. A tweak after cert breaks the seal and can cost the license.
- Myth: “RTP is my chance to win.” Fact: RTP is a long-term average over huge samples. Your session can be far above or below it.
- Myth: “All RNGs are the same.” Fact: Some pass strict tests and audits. Some do not. That is why labs and rules exist.
The table that matters: how fairness is tested and what you can verify
The checks below map lab work to things you can see on your screen or on a public site. Use this as a fast audit when you try a new casino or a new game.
| RNG output randomness | Large samples; NIST SP 800‑22; serial correlation; compression tests | Lab certificate with issuer, date, scope; sometimes linked from the casino footer | No certificate posted; seal without a working link; cert older than ~3 years |
| Implementation integrity | Build hashing; secure intake; change logs; version pinning | Certificate ID and version match the provider’s product page | Cert lists a different version or product name; missing hash/version info |
| RTP claims | Math model vs. long simulations; tolerance bands | RTP in the game’s Help/Info matches provider docs and the cert | RTP hidden or vague; big RTP gaps by region with no notice |
| Game behavior | Feature trigger rates; jackpot logic; error handling; recovery | Clear pay table and rules; no “surprise” side terms in tiny print | Rules contradict the pay table; missing odds for side bets |
| Ongoing compliance | Periodic re‑testing; incident reporting to regulator | Live seals from recognized labs (eCOGRA, GLI, iTech, BMM) | Static images of seals; broken or generic PDFs with no ID |
Many trusted casinos show an eCOGRA seal in the footer with a live link to scope and dates. Some providers list their iTech Labs RNG certification and the exact product version. If the link is dead, treat it as a warning, not proof of fraud, and ask support for the current cert.
From code to certificate: a short timeline
- Dev team builds the game and RNG module and freezes a version.
- Internal QA runs tests and signs off on math and features.
- Supplier submits the package to a lab with notes, hashes, and target markets.
- Lab runs intake, audits the RNG, checks RTP, and writes findings.
- If issues appear, the supplier fixes and resubmits. This can take days or weeks.
- On pass, the lab issues a certificate with scope, IDs, and dates.
- The regulator reviews and, if all good, allows go‑live in that market.
- Future updates repeat parts of this flow. Even small changes can need re‑test.
Want a feel for scope and services? See BMM Testlabs for examples of functional, RNG, and system testing they perform for iGaming and land‑based games.
Edge cases labs still check
Live dealer games use real cards or a wheel. But side bets may still use an RNG. Labs verify that these side RNG calls are independent and do not leak info from the live feed.
Linked jackpots add another layer. The base game RNG picks symbols. The jackpot system has its own math and meters. Labs check that the two systems do not bias each other and that jackpot triggers and contributions follow the rules in the model.
Fast games like crash or plinko need extra care. The clock is tight, and outcomes come fast. Labs check timing, rounding, and that the client shows the right odds before each round. Some states add extra rules. The Nevada Technical Standards are a good example of detailed controls on meters, logs, and error states.
“Provably fair” when the math is public
Some crypto casinos use “provably fair” systems. Here the server gives you a hash of a secret seed before the round. You have a client seed and a nonce that increases each play. After the round, the server reveals its seed. Anyone can check that the hash and seeds match and that the seed pair led to the outcome. This moves trust from an audit to math you can verify.
In other words, trust is split: the game code still needs to be right, but the random draw is tied to seeds you can see. Some projects even use outside oracles to feed random values. If you want a primer, read about verifiable randomness and how a proof can show a number came from a fair draw.
Limits remain. A bad UI can still mislead. A bug in the seed code can still hurt fairness. And most regulators still want lab tests on top. Think of “provably fair” as one more tool, not a full swap for audits and licenses.
How to verify fairness today (and save time)
Here is a short, practical checklist you can use before you deposit or start a long session:
- Find the license. Scroll to the footer. Look for the regulator and number. Cross‑check it at the official site for your market, such as Malta Gaming Authority licensing.
- Open a game and tap “i” or “Help.” Note the RTP. It should be a clear number, not a range, unless ranges are allowed and stated.
- Click the fairness or lab seal in the casino footer. Make sure the link opens to a page with your casino’s name, the lab’s name, the scope, and current dates.
- Search the game provider’s site for a certificate list. Match product names and versions.
- Scan reviews to spot issues like slow updates or broken seals. Independent reviewers can save you time.
If you do not want to dig up IDs and PDFs on your own, independent reviewers like Extra-Betting.com keep simple pages that list a casino’s test lab, certificate IDs, posted RTPs, and any public regulator action. Use that as a shortcut, then still check one or two claims yourself.
Note: some games ship with more than one RTP by region. A 96% version might be 94% in a different market. The game should state which version you are on.
Five-minute self-audit and red flags
- Open one slot you plan to play. Screenshot the RTP from the Info screen.
- Click the site’s fairness or lab seal. Confirm your brand name and a fresh date.
- Open the provider’s site. Find the same game and check if a cert is listed. Match versions.
- Search the regulator’s site for the operator license number. Confirm status is “active.”
- Run a tiny test: 50–100 spins at a low stake. You are not testing RTP with that. You are testing stability: no freezes, no error loops, correct pays per the table.
Red flags: seals that are just images, links that go nowhere, certificates with no ID, RTP hidden behind support chat, or rules in the pay table that contradict on‑screen messages. One flag is not proof of harm, but two or more should make you walk.
Quick FAQ
Do casinos re‑rig games after certification?
They are not allowed to. Builds are version‑locked. Any change needs new tests or formal notice. In strict markets, the regulator also watches production systems. For an example of state oversight, see the NJ Division of Gaming Enforcement pages on technical controls.
Why are RTP values different across countries?
Regulators set rules, taxes, and caps. Providers may ship more than one math model to meet those rules or market needs. The game must show the RTP you get in your region.
Can software RNGs be truly random?
Most casino RNGs are pseudo‑random. They use good algorithms and strong seeds to act like true randomness. With proper seeds, audits, and tests, they are fit for fair play.
How often are tests repeated?
On release and on change. Many markets also require periodic reviews. If code changes, parts of the test cycle run again. The goal is to keep the live version inside the certified scope.
Sources and further reading
- UK Remote gambling and software technical standards (RTS)
- ISO/IEC 17025 (testing labs competence)
- NIST SP 800‑22 statistical tests for randomness
- GLI‑11 and GLI‑19 standards
- eCOGRA, iTech Labs, BMM Testlabs (lab services and seals)
- Nevada Technical Standards
- Chainlink VRF docs (verifiable randomness)
- Malta Gaming Authority, NJ Division of Gaming Enforcement (regulator pages)
Editor’s note: We may receive referral fees from some partners. Reviews and guides do not change test methods or facts cited from regulators and labs. This article is not legal advice. Always play within your limits and follow your local laws.