Return to player, or RTP, is a mathematical property of a specified model, while an observed return is a statistic from a finite dataset. Software assurance asks whether the implemented rules match that model and whether monitoring can reveal faults. This article explains that verification problem. It provides no advice about selecting games, placing wagers or predicting personal outcomes.
Define the model before comparing percentages
The official testing procedure distinguishes mathematical design from software implementation. For a technical review, begin with a complete description of outcomes, their probabilities, returns and any state-dependent transitions. A percentage without those definitions is insufficient to reproduce the calculation. In a simple fixed model, expected return is formed by weighting each return by its probability and relating the total to the defined input unit. More complex stateful designs need their own explicit model. The reviewer should document the assumptions rather than treating a label in an interface as the mathematical specification.
A verification matrix for the implementation
| Item | Evidence or distinction | Review question |
|---|---|---|
| Outcome model | Probabilities and returns for the specified configuration | Do probabilities and units use consistent definitions? |
| Mapping layer | Conversion from generator output to model outcomes | Does the implemented mapping match the design? |
| State transitions | Rules for entering and leaving each state | Are transitions and accumulated values handled consistently? |
| Accounting output | Recorded inputs, returns and corrections | Can the observed statistic be reproduced from the records? |
| Release configuration | Version and enabled parameters | Is this the same configuration described by the report? |
This matrix is a practical review structure. It does not assert that a single set of checks covers every product. The purpose is to expose the connections that must be evidenced before the model, executable and monitoring data can be meaningfully compared.
Use source review to inspect the translation
Trace the calculation from the model document to the implementation that chooses outcomes and records returns. Check the handling of boundaries, data types, rounding and configuration values. Where the system delegates part of the process to a library, identify that dependency and the assumptions made at its interface. Review error paths as well as normal execution: a repeated request or interrupted operation should not silently produce inconsistent accounting. Work on authorised source and test builds. The goal is to verify faithful implementation, not to discover a way to manipulate a live service.
Choose experiments that answer defined questions
Exact enumeration may be practical for a small model, while a larger design may need simulation or other analytical methods. State which method was used and what it can establish. Record the test configuration, input generation, duration or sample size, and the criteria chosen before inspecting the result. A simulation close to the theoretical value is supporting evidence, not proof that every branch of the implementation is correct. Targeted tests for unusual state transitions can address a different risk from a long aggregate run. Keep both kinds of evidence attached to the model version.
Explain observed return and uncertainty
The Commission’s live-monitoring guidance compares actual and expected return, emphasises volatility and warns against aggregation that hides lower-level errors. In a review dataset, define the numerator, denominator, time window and included transactions. A finite sample can differ from the model expectation without establishing a software defect; a close aggregate can also conceal opposing errors in separate configurations. Investigate by relevant version or channel where the evidence supports that separation. Do not use this analysis to promise a future individual result or to suggest that a prior shortfall must be repaid by subsequent outcomes.
Keep corrections separate from original observations
When a fault is suspected, preserve the original data and document any later correction. Distinguish a reporting error from an implementation error and from an unsupported assumption in the mathematical model. Reconcile totals before drawing a conclusion from a dashboard. A corrected build should have a new identity and a record of the tests addressing the defect. If a report or register is updated, retain the link to the previous version. This history allows reviewers to see what changed and prevents a later clean dataset from obscuring an earlier unresolved discrepancy.
Implementation-assurance checklist
- Identify the model, configuration and units behind the theoretical value.
- Trace mapping, state transitions and accounting through the authorised implementation.
- Separate exact calculations, simulations and targeted tests.
- Define observed-return windows and uncertainty before interpreting differences.
- Preserve original data, corrections and release-specific evidence.
A useful final statement says whether the specified implementation was consistent with the documented model under the examined conditions. It should name exclusions and unresolved questions. That is a technical assurance conclusion, not a guarantee about a person’s experience and not a recommendation to use a particular service.
Frequently asked questions
Does theoretical RTP describe what one person will receive?
No. It describes the expectation of a specified model. A finite sequence can differ, and the percentage does not predict an individual outcome.
Is a close simulation result sufficient to verify all code?
No. It supports the tested configuration and sample. Source review, targeted cases and accounting checks address additional questions.
Can aggregate monitoring hide a defect?
Yes. Combining different versions or channels can obscure local discrepancies. Use a documented level of detail appropriate to the investigated issue.
Sources and verification
- Procedure for software and RNG testing — UK Gambling Commission — 2026-10-23
- Live RTP monitoring — UK Gambling Commission — 2026-10-23
- Games and RNG test reports — UK Gambling Commission — 2026-10-23
- SP 800-218: Secure Software Development Framework 1.1 — NIST — 2026-10-23