Both stages matter. A test certificate is evidence about a build at a point in time. It is not a permanent guarantee that every later configuration, release or delivery route will remain error-free.
Testing and monitoring solve different problems
Before launch, an approved test house can examine the game mathematics, software and implementation against the relevant technical standards. The Gambling Commission publishes its list of approved Test Houses and a testing strategy for remote gambling software.
That work gives the operator and regulator a controlled basis for release. It can confirm that the rules, random outcome process and stated return are consistent with the submitted product. It cannot reproduce the full life of the game in production.
After launch, new risks appear:
a game or remote-game server is configured incorrectly;
the wrong certified version is made available;
a platform integration records stakes or wins incorrectly;
a release changes behaviour outside the tested scope;
a fault affects one channel, currency or group of transactions;
the game performs outside an expected statistical range for long enough to require investigation.
This is one reason the same game can exist in different versions. A familiar title and artwork do not establish which build, rules or return setting is live.
What live RTP monitoring measures
For games with a designed return to player, operators can compare live performance with the theoretical value. The actual RTP for a period is calculated from recorded wins divided by recorded stakes or turnover.
The Commission's current guidance on live return-to-player performance monitoring gives a worked example: £1,085,000 in wins divided by £1,200,000 in turnover produces an actual RTP of 90.42%, compared with a designed RTP of 91.68%.
That difference does not by itself prove a fault. Casino outcomes vary, particularly over smaller samples or for highly volatile games. A monitoring system therefore needs thresholds that reflect game volatility, transaction volume and the confidence level chosen for the test. The question is not whether actual RTP matches theoretical RTP after every session. It will not. The question is whether accumulated results fall far enough outside a justified range to trigger review.
This distinction protects against a common misunderstanding. A game's theoretical RTP is a long-run property of its design, not a promise about one player's session or one evening of activity.
A monitoring alert starts an investigation
The Commission expects operators to have systems that identify significant departures from expected performance. Its testing strategy for live RTP monitoring describes monitoring as part of the ongoing assurance process and calls for responsibilities to be defined where B2C operators and B2B suppliers share the work.
A useful response path looks like this:
The system flags a game, version or transaction set outside the chosen tolerance.
The operator checks data completeness and the calculation itself.
Technical teams compare the deployed configuration with the tested and registered version.
The operator and supplier examine logs, releases and affected customer activity.
If a fault is suspected, the game can be removed or made unavailable while the issue is resolved.
The business records the finding, remediation and any reportable regulatory event.
An alert is therefore a control signal, not a verdict. It can reveal a software problem, a configuration error, bad data or ordinary statistical variance. The investigation determines which explanation fits the evidence.
Complaints are another monitoring channel
Player complaints can expose patterns that aggregate return data does not describe clearly. A report might concern a frozen round, a feature that did not trigger as stated, a displayed balance, an interrupted settlement or a mismatch between the rules and the observed behaviour.
One complaint is not proof that a game's mathematics are wrong. Several consistent reports can still be a valuable operational signal. The Commission's live-monitoring guidance tells licensees to consider complaints and other information when deciding whether a game may be performing incorrectly.
The distinction matters because “the game felt unfair” and “this transaction was processed incorrectly” are not the same claim. The first can arise from volatility or misunderstanding. The second can be tested against logs and rules.
The responsibility can be shared, but it must be named
Modern casino delivery often separates the game studio, remote-game server, aggregator and consumer operator. Our guides to who makes an online casino game and how a game reaches the casino lobby explain those layers.
Monitoring can also be distributed. A B2B supplier may aggregate performance across every operator using a game, which can reveal a product-level anomaly sooner. A B2C operator may be better placed to see a problem limited to its own integration or customers. Contracts should specify who performs the monitoring, who receives alerts and who has authority to suspend the game.
The Commission's strategy says the licensed B2C operator should be informed when a game is outside accepted performance ranges and should take appropriate action, including making the game unavailable where necessary. Delegating the calculation does not remove the need for an operational response.
Annual audits check the system around the games
The assurance cycle does not end with dashboards. The Commission's testing strategy summary combines pre-release testing, live RTP monitoring and annual games testing audits.
The annual audit examines whether games made available during the period were properly tested, whether changes were controlled and whether the operator's records support compliance. The Commission separately sets out gaming machine and remote-games information requirements, including information that may need to be supplied about games and testing.
Together, these controls answer three different questions:
| Control | Main question | Evidence produced |
|---|---|---|
| Pre-release testing | Does the submitted build meet the required standard? | Test-house report for the defined game build |
| Live monitoring | Does production behaviour remain within a defensible expected range? | Transaction data, alerts and investigation records |
| Periodic audit | Did the business test, release, monitor and record its games correctly? | Audit trail covering controls, samples and remediation |
None of the three makes the others redundant.
The certificate is the beginning of the operating record
Casino game assurance is better understood as a chain than as a stamp. A studio develops and tests a version. A licensed business releases it through a particular configuration. Live data and complaints show how that version behaves. Alerts lead to investigation, and audits check whether the whole process worked.
That chain also explains why a player's screenshot cannot establish the long-run RTP of a game, while an aggregate RTP number cannot dismiss a specific transaction fault. The evidence has to match the question.
Pre-release testing establishes the starting point. Monitoring makes sure the starting point still describes the product customers are actually using.
