Explainer
Why the same slot title can have different RTP versions
The short answer
A title and its artwork do not uniquely identify a mathematical model. RTP belongs to a particular set of outcome probabilities and awards. Two versions can look alike while using different parameters.
In this article
Two documents can show the same game name and different return percentages. Before calling one of them wrong, establish what each document identifies. A title is a label for a product; a configuration identifies the rules and mathematics being described. A screenshot of the title screen usually leaves that distinction unresolved.
Separate the title, build and mathematical variation
A useful record has at least three fields: the product name, the software build and the mathematical variation. These fields need not change together. A new interface could leave the probability model untouched; a separate configuration could change the model while retaining its presentation. Those are possibilities to investigate, not conclusions to draw from a different number alone.
The glossary in GLI-11 v3.0 uses paytable or variation for a game’s mathematical behavior, including its return percentage. This 2016 technical reference supplies terminology; it does not establish which configurations a particular US jurisdiction currently authorizes.
An example with the same displayed awards
Illustrative example
| Return | Probability in A | Probability in B |
|---|---|---|
| 0 units | 70% | 71% |
| 1 unit | 20% | 19% |
| 7 units | 10% | 10% |
Model A has an expected return of 0 × 0.70 + 1 × 0.20 + 7 × 0.10 = 0.90 units. Model B has 0 × 0.71 + 1 × 0.19 + 7 × 0.10 = 0.89 units. Relative to the one-unit input, these are 90% and 89%. The visible award values are identical; their probabilities are not.
This is one way two configurations could differ. The example cannot identify how an actual supplier implements variations. It also shows why a list of prizes, without probabilities, cannot reproduce a theoretical return calculation. Our RTP explainer works through the underlying expected-value formula.
What a comparison record should contain
- The exact title, supplier and version identifiers shown by the source.
- The stated mathematical variation or configuration, if supplied.
- The percentage, its definition and any feature-specific scope.
- The document URL and the date it was consulted.
- A note saying “not specified” wherever a field is unavailable.
Keep observations separate from interpretation. “Document A lists 90%; document B lists 89%” is supported by the two documents. “The software was changed yesterday” requires evidence about deployment and timing. A dated marketing page, an undated help screen and a certification record answer different questions, even when they share a product name.
Can recorded outcomes identify the version?
A short series of outcomes is weak evidence for distinguishing nearby theoretical percentages. Sampling variation can be much larger than the difference being investigated. Record-based identification is a documentation task first: an observed percentage does not supply a missing build number, prove a configuration change or establish when a change occurred.
