What games and platforms are required to have RNG certification?

Random outcomes are central to most online casino games, but gambling platforms do not follow a single certification procedure. A laboratory may test an individual game or assess the central RNG, game mathematics and platform integration. Live dealer products, sports betting and skill-based games may fall under different technical requirements. A supplier certificate is therefore insufficient without checking the jurisdiction, tested version and licence conditions. In this article, we explain which games require RNG certification and how to confirm compliance before launch.

What RNG certification actually confirms

RNG certification confirms that a Random Number Generator produces unpredictable and statistically valid results. It is required when software selects cards, symbols, numbers, virtual race results or another outcome affecting player winnings.

A testing laboratory usually checks:

• The random value generation algorithm;
• Seed and entropy quality;
• Absence of predictable patterns;
• Uniformity and independence of results;
• Consistency with stated game mathematics;
• Protection against manipulation and interference;
• Operation after restart or system failure.

The UK Gambling Commission, for example, requires random outcomes to be acceptably random and unpredictable without full knowledge of the algorithm and seed.

The UK Gambling Commission updated its Remote Gambling and Software Technical Standards in June 2026; the core RNG randomness requirements (RTS 7A) were not affected by this update. 

An RNG certificate does not always confirm compliance of the entire game. Separate testing may cover rules, paytables, RTP, bonus rounds, jackpots, error handling and player information. Platform testing covers wallets, player accounts, transaction records and component integration.

A certificate usually applies to a specific RNG build, game version, platform configuration and technical standard. Changes to source code, mathematics or integration may fall outside its scope.

Before relying on a certificate, check:

• The tested product and version;
• The software owner or developer;
• The applied technical standard;
• The relevant jurisdiction;
• Testing scope and exclusions;
• Issue date and updates.

A laboratory logo on a supplier’s website does not prove that a specific game is certified. The operator should obtain the full certificate or test report and match it to the deployed version.

Which games normally require RNG certification

Certification is generally required when software randomly determines a game outcome, prize or access to a bonus feature. The exact scope depends on the regulator and technical standard.

Online casino and instant games

RNG testing commonly covers:

• Online slots and progressive jackpots;
• Video poker;
• Electronic roulette, blackjack and baccarat;
• Dice and crash games;
• Scratch cards and instant-win products;
• Random bonus rounds, multipliers and prize draws.

Testing may cover a central RNG and each game using its output. Even with one generator, the game mathematics, paytable and stated RTP may require separate verification.

Bingo, lotteries and virtual events

Certification may also apply to:

• Electronic bingo and keno;
• Online lotteries and number draws;
• Virtual sports and simulated races;
• Betting on virtual events;
• Randomised tournament and jackpot mechanics.

The UKGC, for example, applies random outcome requirements to casino games, bingo, lotteries and virtual event betting.

Peer-to-peer card games may also use RNG for shuffling and dealing. Although poker outcomes depend on player decisions, card distribution must remain random and unpredictable.

Certification depends on whether software affects the gambling outcome, not the product label. Operators should therefore inventory all random functions, including bonuses and shared jackpots.

Which products may not need conventional RNG certification

Not every gambling product uses software RNG. However, the absence of a generator does not remove other technical testing requirements.

A conventional RNG certificate may not be required for:

• Live dealer games using physical cards, dice or roulette wheels;
• Betting on real sports and events;
• Peer-to-peer competitions based only on participant actions;
• Skill-based games without random outcomes;
• Manual lotteries using physical draws.

For live casino products, regulators may require testing of shuffling machines, optical recognition, video transmission and result records. Any electronic component that randomly selects a card, multiplier or bonus may still need RNG certification.

Sportsbooks also remain subject to technical requirements. Testing may cover bet acceptance, settlement, odds changes and interrupted events, even though the platform does not determine real match results. Virtual sports usually use RNG and require testing.

Demo or play-for-free versions are not automatically exempt. If they promote a real-money game, their odds and rules must not mislead players. Any differences should be documented and assessed under local rules.

Physical gaming machines may require separate equipment certification. The key questions are how the outcome is determined and which technical regime applies.

Which platforms and businesses are responsible for certification?

Responsibility depends on who develops the software, controls the RNG and offers the product to players. One certificate may support the supply chain, but each company must confirm its own duties.

Game developers and B2B suppliers

Developers usually arrange laboratory testing of the game, RNG and mathematics before supplying it to operators. They should retain source code, version history, test reports and change records.

New testing may be required if the supplier:

• Changes the RNG or seeding method;
• Adjusts the RTP or paytable;
• Adds a bonus feature or jackpot;
• Moves the game to another engine;
• Changes critical source code;
• Adapts the product to a new technical standard.

An aggregator that only distributes certified games without changing outcomes may not need to retest the RNG. However, its integration layer, launch process and transaction records may be covered by a platform audit.

Operators and white-label platforms

Operators must ensure that players access the approved game version. They should verify the supplier certificate, laboratory recognition and local compliance.

A white-label operator should establish:

• Who retains certificates and reports?
• Who notifies the regulator about new games?
• Who controls software updates?
• How production versions are verified?
• Who suspends a defective game?

A central RNG may be tested separately, while games using its output may require additional mathematics and gameplay checks. In Great Britain, an approved test house must complete game and RNG testing before launch.

Contracts allocate duties between the operator, platform and supplier but do not remove the licence holder’s regulatory responsibility. Certificates should therefore be available before integration.

When testing must take place

Initial testing must be completed before a game becomes available to players. Launching with a promise to provide the certificate later usually breaches licensing conditions.

Retesting may be required:

• Before entering a new jurisdiction;
• After changing the RNG, seed or entropy source;
• When adjusting RTP, paytables or game mathematics;
• After adding a bonus round, jackpot or multiplier;
• Following changes to critical source code;
• After moving the game to another engine or platform;
• When a defect affects the outcome;
• At the regulator’s request.

Not every software update requires full recertification. An interface change that does not affect gameplay may be a minor update. The supplier should document the change assessment, compare the update with the tested build and determine the required regression testing.

Some jurisdictions also require annual game audits and live RTP monitoring. Operators should maintain a register of game versions, certificates, production releases, integration dates and later changes. This helps confirm that each active product matches the approved build.

How the certification process works

Testing should begin after identifying the target market. Laboratories apply the relevant regulator’s standards, so the same build may require different testing across jurisdictions.

The process usually includes:

1. Identify the applicable standard. Define the target jurisdiction, licence type, game category and functions affecting outcomes.
2. Select a recognised laboratory. The regulator may accept reports only from approved or accredited test houses.
3. Prepare the technical package. Provide the source code, executable build, rules, mathematics, paytable, RTP calculations, RNG specifications and change history.
4. Conduct testing. The laboratory reviews randomness, statistical distribution, game logic, error handling, accounting and displayed information.
5. Correct deviations. The developer resolves issues and submits a new build when required.
6. Obtain the report and certificate. These should identify the product, version, tested components, standard and limitations.
7. Complete the regulatory procedure. The report may need to be filed, uploaded to a games register or retained for audit.
8. Verify the production release. The operator confirms that the deployed build matches the tested version.

The certificate should be retained with the laboratory report, tested file hashes and release records. Without them, proving that the platform uses the approved build may be difficult.

Can one RNG certificate be used in several jurisdictions?

A certificate from a recognised laboratory may reduce repeat testing but does not guarantee approval in another country. Each regulator sets its own accepted standards, laboratories and submission procedure.

Before reusing a certificate, confirm:

• Whether the regulator recognises the test house;
• Whether the technical standards match;
• Whether the report covers the relevant game version;
• Whether the stated RTP meets local requirements;
• Whether jackpots and bonus features were tested;
• Whether separate registration or notification is required.

Where standards partly overlap, the laboratory may conduct a gap analysis and test only the missing elements. This is faster than full recertification, but document sufficiency depends on the regulator or the licence holder under local rules.

Malta, for example, allows new games to be added to an approved RNG through notification. Under MGA requirements, the operator must submit information on the technical setup, gaming system and game sheets, including descriptions and RTP, within five days.

Companies should maintain a jurisdiction matrix showing the accepted laboratory, applicable standard, approved version and filing status for each product. A general “certified RNG” claim does not authorise a game across all licensed markets.

Common RNG certification mistakes

Most breaches result from mismatches between the certificate, production version and target jurisdiction requirements rather than a complete lack of testing.

Common mistakes include:

• Launching before receiving the final test report;
• Using a certificate for another software version;
• Failing to test bonus features and jackpots;
• Changing RTP or mathematics without reassessment;
• Selecting a laboratory not recognised by the regulator;
• Moving a game to a new platform without integration testing;
• Missing change logs or tested build hashes;
• Relying on outdated supplier documents;
• Failing to notify the regulator about a new game;
• Assuming the supplier bears full responsibility for operator compliance.

Operators should verify certificates before integration and after each material update. If the deployed build cannot be matched to the test report, the game should be suspended until compliance is confirmed.

Supplier agreements should require change notifications, test reports, responsibility for defects and support during regulatory inspections. Without these terms, an operator may discover RNG or mathematics changes only after an uncertified version has launched.

How Key2Law supports RNG certification and game approval

Key2Law team advises gaming operators, software suppliers and platform providers on technical compliance and regulated product launches. We determine the applicable requirements based on the game type, target jurisdiction and company role.

Depending on the game type, platform structure and target jurisdiction, Key2Law team can:

• Determine whether RNG or full game certification is required;
• Identify the applicable jurisdiction and technical standard;
• Select a recognised testing laboratory;
• Prepare technical documentation for testing;
• Review existing certificates and software versions;
• Support regulatory notifications and game approval;
• Develop change controls and a certificate register.

If you plan to launch a new game, integrate a supplier or enter another jurisdiction, contact Key2Law. We will help define the required testing scope and avoid releasing a product without valid regulatory approval.

_____________________________________________________________

This material is for informational purposes only and does not constitute legal, tax or investment advice. Licensing, capital and conduct requirements depend on the jurisdiction, financial instruments and the broker’s actual activities. Obtain advice tailored to your business before adopting or changing an execution model.