Almost every commissioned slot is asked for more than one return figure before it goes live. An operator wants the version its competitors run. A second operator in a different market wants a different number on the game rules page. A platform wants one build it can offer to both.
The request looks like a setting. It is not. A return-to-player figure is a property of a math model, and a math model is a document that a laboratory tests, an authority recognises and a rules page describes. When a brief asks for “the same game at 94% and at 96%”, what it is actually buying is two certified builds that must be kept in step with each other for the life of the title.
This article sets out what the disclosure rules require, why a variant is a build rather than a switch, and how to write the variant set into a commissioning brief so that the second market does not arrive as a change request after the first launch.
What the rules actually require to be shown
The clearest statement of the obligation is in the British remote gambling and software technical standards, and it applies to gaming, bingo, lotteries and betting on virtual events. RTS requirement 3C says that for each game, information that may reasonably be expected to enable the customer to make an informed decision about their chances of winning must be easily available before they commit to gamble. The required content is specific:
- a description of the way the game works and the way in which winners are determined and prizes allocated;
- the house edge, or margin;
- the return to player percentage, or the probability of winning events occurring.
Two neighbouring requirements matter just as much for a variant set. RTS 3A requires an explanation of the applicable rules to be easily available before the customer commits, accurate and sufficient to explain all of the applicable rules, with reasonable steps taken to make the content understandable. RTS 3D requires content describing the potential prizes and payouts to be available before the customer commits.
Neither requirement says “display a number somewhere”. Both attach to the session the customer is about to play. A game that shows 96% on its rules page while the operator has configured the session at 94% has not disclosed anything; it has published a different product’s specification.
The progressive case sharpens the same point. RTS requirement 9A requires the jackpot rules to be clearly available before the customer commits, and the implementation guidance is explicit about what those rules must contain: how the jackpot is funded, the start-up seed and any ceiling values, and the jackpot’s return to player percentage displayed as set out in RTS 3C — either one combined figure for game and jackpot or a breakdown into base game and jackpot component. It adds a consequence that variant design routinely misses: if a player is not eligible for a game’s progressive jackpot prize, that must be made clear along with their own theoretical return.
That is the same problem in a different place. A game whose jackpot eligibility is set per operator, per market or per configuration has more than one true return figure at any given moment, and the disclosure has to follow the session rather than the title.
A variant is a build, not a setting
In Malta, the Gaming Authorisations Regulations (subsidiary legislation 583.05) provide that no person shall offer a licensable game, whether as part of a gaming service, critical gaming supply or otherwise, unless the game is approved or otherwise recognised by the Authority. A game is approved as a described article: a math model, a paytable, a set of reel strips, a feature set and a stated return. Change the math model and you have a different article, which needs its own approval evidence.
That is why variant count is a scope decision rather than a configuration detail. Two return figures mean two math models, two sets of simulation and verification evidence, two entries in whatever approval process each market runs, and two rule texts whose figures must match the build they describe. The bill arrives in triplicate: once in math design, once in test and certification, and once in the ongoing obligation to keep both builds identical everywhere except the return.
There is a cheaper shape, and it is worth naming because it is often what the requester actually wants. If the operator’s real requirement is a single approved game offered to several operators, that is one build with per-operator branding and a per-operator bet ladder, and the return figure does not move. If the requirement is genuinely two return figures, the brief should say so in the first paragraph and budget for two models.
The build has to know which return it is paying
On the platform this studio builds against, the game does not own its betting configuration. Authentication returns the session’s currency, language, device class and a bet ladder with a minimum, a maximum and a step, and a game with several modes carries a cost multiplier and a maximum per mode. The same shape of handshake is where a variant identifier belongs.
Three design consequences follow.
The figure is a parameter, not a constant. A hardcoded 96% in the rules component is a defect in market two even when the maths behind it is correct. The number rendered to the player has to come from the configuration the session is running, and it has to be the number the model actually produces.
A mismatch has to fail closed. If the platform asks for a variant the build does not carry, the correct behaviour is to refuse to open the game rather than to fall back to the default model. Falling back silently is how an operator ends up running 96% while its rules page, its certificate and its marketing copy all say 94% — a disclosure failure that no amount of correct math design repairs.
The rules text is part of the deliverable, in every language. The obligation sits with the licensee, but the studio supplies the paytable, the how-to-play panel and the feature descriptions that the licensee will publish. A variant set therefore ships with a variant matrix — one row per configuration, with its return figure, its volatility descriptors, its maximum win and the markets it is approved for — and a rules text per locale that names the figure rather than a placeholder.
Two maths, not one maths with a knob
The most expensive misunderstanding in a variant request is that raising the return means paying a little more out of the same game. It does not. The return figure is an output of the outcome distribution, so a variant is a different distribution: different reel weights, a different paytable, or both. Hit frequency, the shape of the win distribution, the frequency of the top award and the maximum win all move with it, because they are the same arithmetic.
That has commercial consequences that belong in the brief rather than in the post-launch review. A title that reads as moderately volatile at 94% can read as noticeably tighter or looser at 96%, depending on where the extra return was placed — spread across small wins, or concentrated in the top band. If the variant was built by lifting the top award, the median session looks almost identical and the tail changes; if it was built by lifting low wins, the opposite happens. Neither is wrong, but they are different products, and the description that goes to the operator should say which one it is buying.
It also changes the test plan. A variant set needs a simulation run per model, with the return, the hit rate, the volatility measures and the maximum-win behaviour reported separately, and it needs a parity check that the two models differ only where the brief says they differ. A test record that shows one simulation and one certificate for two models is the evidence a reviewer will ask about first.
The variant matrix in the brief
The cheapest way to settle this before the math is frozen is a table with one row per configuration and one column per question the operator will ask later:
- the return figure and the volatility descriptors that go with it;
- which markets and which operators the variant is approved for;
- the maximum win, expressed against the ladder the variant ships with;
- whether any feature — a buy, an ante, a jackpot contribution — behaves differently between variants;
- the rule text version that describes it, per language;
- the change-control rule when a market moves its requirement.
That last column is the one that decides the five-year cost of the variant set. Markets do move: stake ceilings get inserted into licences, jackpot disclosure expectations get clarified, and a game offered in a new market sometimes needs a return band it was never built for. A studio that shipped variants as data changes a parameter and re-runs the affected evidence. A studio that shipped them as branches maintains two diverging codebases until one of them is retired.
Where this sits in a commissioning decision
The variant question is not the first one in a brief. The market set comes first, because it determines which requirements exist at all, and the mechanics come second, because they determine what has to be disclosed. The variant set is the third decision, and it is the one that most often arrives late — after the art is approved and the launch date is booked — which is precisely when it costs the most.
If you are scoping a slot for more than one operator or more than one market, the Engine game-development service covers math design, variant configuration and the disclosure evidence that goes with them as a project-specific scope. Request a project quote with the markets, the variants and the figures you need. The market-level sequencing is set out in the multi-jurisdiction release plan, the evidence a localised build needs is in the localised certification guide, and the disclosure obligations that attach to a progressive component are covered in the progressive jackpot commissioning guide. Where a market caps stake rather than return, the British stake-cap analysis explains why that limit is counted per cycle.
Frequently asked questions
Is a different RTP a setting on the same game?
No. The return figure is an output of the outcome distribution, so a variant is a different math model — different reel weights, a different paytable, or both — with its own simulation and certification evidence. It can be delivered as one codebase driven by configuration, which is the cheaper long-term shape, but it is still two described articles for approval purposes.
What has to be shown to the player before they play?
Under the British technical standards, RTS 3C requires information enabling an informed decision about the chances of winning to be easily available before the customer commits, including a description of how the game works, the house edge or margin, and the return to player percentage or the probability of winning events. RTS 3A requires the applicable rules themselves to be accurate, sufficient and understandable. Other markets impose their own versions; check the current rule for each market rather than assuming one figure serves all of them.
How is a progressive jackpot’s return disclosed?
RTS implementation guidance for requirement 9A says the jackpot rules must describe how the jackpot is funded, its start-up seed and any ceiling, and its return to player percentage displayed as set out in RTS 3C — as one combined game-and-jackpot figure or as a breakdown of base game and jackpot component. If a player is not eligible for the jackpot, that has to be made clear along with their own theoretical return.
Does raising the return change volatility?
It usually does, because the return is produced by the same distribution that produces volatility. Where the extra return is placed decides the effect: lifting the top award changes the tail while leaving a typical session almost untouched, while lifting small wins changes the body of the distribution. The variant matrix should state which one was built, and the simulation evidence should show it.
What happens if the platform asks for a variant the build does not have?
The correct behaviour is to refuse to start the game. Falling back to a default model means the session can run at a return figure that the certificate, the rules page and the operator’s own disclosure do not describe. The configuration handshake should treat an unknown variant as an error, not as a reason to pick one.
