An online casino game update needs independent retesting in Great Britain when the software change may affect the fairness of the game. That includes changes to the random-number generator (RNG), the conversion of random numbers into outcomes, game maths or the code that implements game rules. A change that does not affect fairness can be handled as a minor update, but it still needs documented classification, internal testing and release control.
This guide is for casino product, engineering, compliance and procurement teams reviewing a release under a British Gambling Commission licence. It explains the regulator's testing strategy as checked on 29 September 2026. Other markets can set different requirements; the GLI-19 technical standard is discussed as a comparison framework, not as a law that applies everywhere.
Start with the tested version, not the patch name
The British testing strategy's procedure requires independent testing and a report before a new game or RNG is released. The game's report identifies the name, theoretical return to player (RTP), software number, digital signature, platform and version, client channels and any version superseded. For a changed game that receives limited-scope testing, the updated report must reference the original report, describe the change and testing, and give new digital signatures.
Those identifiers matter because a certificate is evidence about a particular build and scope, not a permanent promise about every future deployment of a similarly named game. The game-testing explainer covers the original laboratory workflow; this article follows what happens after a tested game changes. The RGS guide explains the shared server layer that can affect many titles at once.
The Commission says British B2C licensees using B2B gaming content must still keep an up-to-date games register for games they offer. Where the B2B has submitted a report, the B2C may use the B2B's games-register reference rather than resubmitting the same report. That does not make the operator's own list of live games optional. Source: testing procedure.
What makes a game update major or minor?
The Commission's Annex A on major and minor updates defines a major update by possible impact on fairness. It names RNG, scaling and mapping, and game rules—including software processing of those rules—as fairness elements. The examples are explicitly non-exhaustive, so a team cannot classify every future change by matching a single example.
| Proposed change | British testing implication | Why the label alone is not enough |
|---|---|---|
| Alter RNG, outcome mapping, paytable maths or bonus-round calculation | Treat as fairness-affecting and obtain independent retesting before release. | Even a rare outcome or small code diff can change winnings. |
| Optimise game code that implements existing rules | May still be major; assess with the approved test house. | Annex A treats a performance fix affecting implementation of symbol arrays as requiring independent testing. |
| Replace sound or background art without changing logic, maths, payouts or truthful presentation | May be minor, with documented internal testing and release control. | An apparently visual change becomes material if it misstates rules or results. |
| Port an existing game to a new client channel | The new channel must be tested by an approved test house; scope can focus on interface and display when the backend is unchanged. | A new app or interface is not automatically covered by the old channel's report. |
| Update a shared RGS or RNG | Retest a representative sample of affected games before launch when fairness can be affected. | The shared component may change many games even if their individual files are untouched. |
The table is a decision aid, not a substitute for the licensee and test house deciding the actual scope. In the Commission's example, changing code that constructs symbol arrays to fix a performance problem required independent testing despite unchanged written rules. By contrast, changing a sound format or non-functional artwork can be minor. Annex A cautions that an apparently minor bundle of display fixes could become major where players might be misled or payouts or maths are affected. Source: Annex A.
A minor classification is not a no-test classification. The testing procedure says changes that do not affect fairness may be released without external retesting, but all updates must meet minimum change controls, be recorded for inspection and have a responsible relevant personal management licence (PML) holder or qualified person. The in-house release guidance calls for a minor-change record to confirm internal testing and document the result.
Four questions for a release decision
The practical review starts with the full dependency chain, not just the ticket text. This is an editorial checklist derived from the Commission's testing and change-control documents, not a regulator-issued form.
- What exact component and version change? Identify the game, RNG, server, client channel, configuration, paytable and digital signature where relevant. A shared platform change needs a wider impact assessment than a single title's artwork update.
- Can the change alter a stake, outcome, prize or player understanding? Trace both direct maths changes and indirect code paths. A result-display defect may matter even when the underlying outcome was calculated correctly. The paytable guide explains why a mapping or award rule can change the theoretical result.
- What independent testing and report submission are required? In Great Britain, new games and fairness-affecting changes require approved-test-house testing and report submission before release. A new channel also has its own external-testing rule. Do not assume a supplier's historical certificate covers a changed production build.
- Can the team prove what went live? Preserve the classification, rationale, internal and external results, release authorisation, version identifiers and rollback method. If a later dispute or audit occurs, the evidence must identify the actual deployed version.
The UK Gambling Commission's technical-standards introduction links compliance with the Remote Gambling and Software Technical Standards (RTS) and testing strategy to a licence condition. The software standards guidance also limits the British requirement to software made available in reliance on a Commission licence. Do not transplant this procedure unchanged into a different jurisdiction.
Shared RGS and RNG releases can widen the blast radius
A remote gaming server can host many games, while one RNG can feed multiple outcomes. The Commission's testing procedure addresses the situation where an RGS or RNG update may affect the functionality and fairness of hundreds of games. It expects a representative sample to be retested before launch, covering each game type and generation rather than only a cluster of similar games. The licensee and approved test house decide the sample and integration scope; the evidence can be captured in a single report retained by the licensee. Source: testing procedure.
This is different from claiming that every title always needs a full new test. It is also different from saying a shared platform patch never affects game certification. The release owner needs to map the affected games and explain why the tested sample covers the relevant types and generations. The casino game aggregation guide shows why the catalogue, hosting layer and operator account systems should not be treated as one undifferentiated platform.
Client changes are another separate case. An existing game ported to a new channel—such as a native mobile app after an HTML5 launch—requires approved-test-house testing of the new channel. If its backend has not changed, the Commission says the subset can generally focus on interface and player-display behaviour. Routine updates to a third-party browser or operating system generally do not demand external retesting, although the licensee should test existing games internally; this is not a blanket exemption for changes to the game engine, RGS or RNG. Source: testing procedure.
What should be in a change-control record?
The Commission's in-house development, testing and release guidance specifies a unique change ID, game or RNG identifier, delivery channels, change description, major/minor classification and justification. It also calls for confirmation of internal testing for minor changes or adequate external-test-house assessment for major changes, plus management authorisation. Secure source-code history, independent review of critical modules, separated development and test environments and a documented migration plan are part of the broader controls.
An operator-facing evidence pack can therefore link one change ID to the old and new build identifiers, affected products, test report or internal test results, approval, launch time and any rollback. That suggested packaging is BETTIMES's synthesis of the cited controls, not a claim that the regulator mandates a particular spreadsheet or software tool. It is especially useful where supplier, aggregator and operator each hold different parts of the record. The operator-versus-supplier licence analysis separates those legal roles.
GLI-19 version 3.0, Appendix B.8 offers another technical lens: a regulator selects the change-management policy, and its program-change controls cover authorised versions, installation records, sign-off, emergency changes and rollback planning. GLI-19 is a laboratory standard and framework; its wording is not, by itself, evidence that every market has adopted the same procedures. The local regulator, licence conditions and approved implementation remain decisive.
How the annual audit closes the loop
For British licensees within its specified scope, the annual games testing audit is carried out by a Commission-approved test house. Its minimum scope includes a randomly selected sample of major and minor updates, adherence to change controls, the list of games available to consumers and live RTP monitoring. The Commission says licensees outside that annual-audit requirement should still seek assurance that games and updates were tested as the strategy requires before release.
The audit is retrospective. It does not replace a required pre-release test or report. Nor does a prior laboratory result eliminate the need to monitor the live product: the RTP explainer distinguishes theoretical game design from actual observed returns. In a release review, the best evidence is a continuous chain from tested build to deployed build to monitored operation, with reasons recorded for each intervening change.
Bottom line
For a British online casino game update, the release decision is a fairness-impact assessment backed by evidence. If the change may affect outcomes, maths, rules processing or RNG behaviour, independent retesting is the safe regulatory path before release. If it cannot affect fairness, it can be classified minor—but still needs a documented rationale, internal test, approval and traceable deployment. Teams should check the current market-specific rule and match the live build to the relevant report, rather than treating a certificate or a patch label as self-explanatory.
Frequently asked questions
Does every online casino software update need a new certificate?
No. Under the British testing strategy, an update that does not affect game fairness can be classified as minor and released without external retesting. It still needs documented change control and internal testing. New games, fairness-affecting changes and new client channels have separate external-testing requirements. The classification depends on what the code actually changes, not its size or release name.
Can a visual-only change be treated as minor?
It may be, if it does not change game logic, maths, payouts or how players understand the result and rules. The Commission gives non-functional sound and artwork changes as minor examples, but warns that some display fixes can cross the fairness boundary. Document what changed, test the player-facing display and consult the test house where the impact is uncertain.
What if an RNG or remote gaming server changes but game files do not?
The shared component can still alter how many games operate. The British Commission expects a representative sample of affected games to be retested before a fairness-relevant RGS or RNG update launches. The sample should span game types and generations, with scope agreed by the licensee and an approved test house. Untouched game files alone do not resolve that risk.
Does moving an existing casino game to a mobile app require testing?
In Great Britain, adding a new client channel to an existing game requires approved-test-house testing. If the backend design and functionality remain unchanged, the scope can generally focus on the interface and how results appear to players. A normal third-party operating-system or browser update is different: internal compatibility testing is expected, but external retesting is not generally required solely for that update.
Who checks whether a 'minor' update was classified correctly?
The licensee and its test house must use judgement at release time, and the relevant responsible person oversees the process. For licensees within the British annual games testing audit, an approved test house later checks a random sample of major and minor updates and the change controls. That retrospective check is not permission to defer required independent testing until after launch.