A feature-buy mechanic — also called a bonus buy or feature-buy option — lets a player pay a multiple of their stake to trigger a bonus round directly, bypassing the base game. From an engineering perspective it is a wager option. From a regulatory and design perspective it is a second product embedded in the first one, and the decisions that determine whether it can ship in a given market are not the same as the decisions that govern the base game.
This article maps the minimum set of decisions a studio and operator must settle in the design brief before a feature-buy mechanic enters production: the separate math model and its certification implications, the market-level restrictions that make the mechanic a jurisdiction gate rather than a feature flag, the RTP disclosure requirements that follow from the separate wager, and the platform-level disable mechanism that makes the resulting game distributable across a mixed market set.
The feature-buy mechanic is a separate wager
A base-game spin and a feature-buy activation are not the same wager. They share a game build and a user interface, but they can have different theoretical RTPs, different win-size distributions, different maximum wins, and different contribution profiles to bonuses the operator attaches to them.
That distinction is not merely taxonomic. A casino game math model is scoped to the exact wager options it covers. A model that describes the base game describes the probabilities of the base game. Adding a feature-buy option changes the model’s scope: the studio must define the purchase price as a stake multiple, the outcome distribution of the bonus round entered through that purchase, and the resulting theoretical RTP for the buy itself. If those two RTPs — base game and feature buy — are close, a single combined model may be defensible. If they diverge materially, the certification lab will evaluate them as separate products, and the brief should treat them that way from the start.
GLI-19-style testing evaluates each RTP model against its stated theoretical value. Certification is per build and per math model: a 96% base-game certificate and a 98% feature-buy certificate are separate documents covering the same binary. A studio that adds a feature-buy option to a previously certified game therefore faces a re-certification decision, and the brief should answer whether the buy’s RTP is set before or after the base game goes through certification — because changing it later restarts that clock. A brief that defers this question does not avoid the cost; it moves it to the point at which it is most expensive.
The UK and the RTS basis for the restriction
The UK Gambling Commission prohibited the feature-buy option from UK-facing online slots in 2019. The prohibition was delivered through the UKGC’s Remote Technical Standards: RTS requirement 14A states that gambling products must not actively encourage customers to chase their losses, increase their stake, or increase the amount they have decided to gamble, or continue to gamble after they have indicated that they wish to stop. The Commission’s investigation found that a feature-buy option — which can cost 50 to 100 times the base stake — met that condition by materially increasing the amount a player commits in a single action, with one game in the investigated set charging more than £3,000 to access the bonus.
The UKGC subsequently directed all UKGC-licensed operators to remove feature-buy games or disable the feature for UK-facing players. Operators who had not offered the feature before were unaffected; those who had were required to act. The Commission also issued a public reminder in January 2020 noting that six operators had already complied and directing the remainder of the market.
This history has two practical implications for a studio building a new feature-buy title. First, the mechanic is not distributable on a UKGC-licensed platform in its native form: the build must either be separate from the UK-facing build, or the feature must be disableable at the platform level without altering the base-game certification. Second, the prohibition was made under an existing technical standard, not under a new rule drafted specifically for the feature: an operator facing a similar regulatory challenge in another market can reasonably expect the same framework to apply even without a published specific ruling.
Other jurisdictions: market-by-market, not a single answer
Outside the UK, the feature-buy mechanic is permitted in many regulated markets, subject to the operator’s licence conditions and the platform’s configuration. The Malta Gaming Authority, Curaçao, Gibraltar, Isle of Man and most European regulated markets do not prohibit it by default, although individual operator licences may impose additional conditions. Ontario’s market, regulated through iGAMING ONTARIO and the AGCO, does not prohibit feature buy at the time of writing, but operators in Ontario are subject to AGCO Registrar’s Standards for Internet Gaming, which require clear disclosure of the odds and the rules governing every wager option — including a feature buy, which is a wager option with its own probability profile.
The practical implication for the brief is that market scope and the feature-buy setting cannot be decided independently. If the game is to be distributed across a set that includes the UK and other markets, the brief must define the disable mechanism — the configuration parameter, the operator-level toggle, or the separate RGS build — before the game enters production. Retrofitting a disable switch after certification is a scope change that may require re-testing, and retrofitting it after distribution is a production incident that has happened to several major studios.
The brief should therefore name: the markets the game is intended for, whether the UK or any other market with a blanket restriction is in scope, and the mechanism the studio will use to satisfy that restriction. “We will build a toggle” is insufficient: the brief should specify what the toggle controls, whether toggling it changes the math-model scope, and whether a toggled-off version needs its own certification evidence.
RTP disclosure and the wager option obligation
An operator publishing a feature-buy title in a regulated market has a disclosure obligation that extends to the buy itself. The UKGC’s RTS 3C requires that the information published before a customer commits to gamble includes the return to player percentage or the probability of winning events occurring for each virtual event or game. A feature-buy option is a virtual event with its own outcome distribution: the operator cannot satisfy RTS 3C by disclosing only the base-game RTP.
The studio is the source of that second figure. An operator who integrates without requesting it cannot publish it, and an operator who publishes the base-game figure for both wager options publishes a figure that is inaccurate for at least one of them. The casino game rules specification guide records the obligations each party carries on rules documentation; the feature-buy RTP belongs in that document alongside the base game, with its own figure and its own measurement basis.
The measurement basis matters here as much as in the volatility context covered in the volatility documentation guide. A feature-buy bonus round triggered through the buy may have a different win-size distribution and maximum win than the same round triggered organically. If the studio simulates them together, the combined figure obscures both. The brief should specify whether the feature-buy RTP is measured as the expected return per unit staked on the buy itself — the most defensible measurement — or as a combined return that blends base-game and buy contributions. Either approach is workable; only one of them supports accurate per-wager disclosure.
The platform disable mechanism and the certification boundary
The certification boundary question and the disable mechanism question are related but not identical. A platform-level toggle that prevents players from seeing or using the feature-buy button does not change the certified build: the code is unchanged, only the interface path to the mechanic is removed. That is how most UK-compliant implementations work: a single certified build ships with the button absent for UK-facing sessions and present for other sessions.
The certification implication of this approach is that the math model must account for the buy even when the button is disabled, because the code path exists. A certification lab asked to evaluate the base game only must be told that the build also contains the buy mechanic and that it is disabled by configuration. A lab that is not told this is evaluating an incomplete scope. Whether the lab requires separate evaluation of the inactive mechanic depends on the jurisdiction and the lab’s own standards, but the studio should not make that decision unilaterally: it belongs in the brief, and the brief should identify who is responsible for raising it with the lab.
A separate build approach — two binaries, one with the mechanic and one without — avoids the inactive-code scope question but requires maintaining two certification chains for what is substantially the same game. Studios that choose this path should record in the brief which build is the source of truth for each market set and what the process is when the math model or the base game changes, because a change to the base game changes both builds.
What the brief must contain before production begins
A feature-buy brief is not complete if it answers only the questions the base-game brief answers. The additional decisions are:
- The feature-buy price: a specific stake multiple, not a range, because the price is part of the RTP calculation. If the studio intends to offer multiple buy options at different multiples, each must have its own stated price and its own RTP measurement.
- The feature-buy RTP: a theoretical figure, derived from the same simulation methodology used for the base game, stated separately from the base-game RTP, and with the measurement basis — rounds simulated, confidence interval, whether organic and purchased triggers are measured separately — recorded alongside it.
- The market gate list: the named markets the game is intended for, the status of the mechanic in each (permitted, prohibited, operator-discretion), and the handling for each prohibited or restricted market.
- The disable mechanism: what it is, what it controls technically, whether it touches the certified build or only the interface, and what re-certification is required when it is changed.
- The disclosure artifact: who is responsible for providing the feature-buy RTP figure to the operator, in what form, when in the integration cycle, and what the versioning obligation is if the figure changes.
- The certification scope plan: who raises the inactive-mechanic question with the lab, and what the expected scope of the certificate is — base game only, base game and buy together, or two separate certificates.
None of these decisions are unusual or difficult to reach. What makes them costly when deferred is that each one intersects with a dependency outside the studio: a lab, a regulator, an operator, or a platform. Reaching the wrong answer late in production, or failing to reach an answer at all, converts a design decision into a compliance event. A project quote from a studio experienced with multi-jurisdiction game delivery includes the scope of these decisions as part of the production scope, not as optional additions.
Frequently asked questions
What is a feature-buy or bonus-buy mechanic in a casino game?
A feature-buy or bonus-buy mechanic is a wager option that lets a player pay a multiple of their base stake — typically 50 to 100 times — to trigger a bonus round directly, without playing through the base game to trigger it organically. The buy has its own stake, its own outcome distribution, and its own theoretical RTP, which may differ from the base-game RTP.
Is the feature-buy mechanic permitted in UK-licensed casinos?
No. The UK Gambling Commission prohibited the feature-buy option from UK-facing online slots in 2019, directing UKGC-licensed operators to disable or remove it. The prohibition was based on RTS requirement 14A, which bars products that actively encourage customers to increase the amount they have decided to gamble. A UKGC-licensed operator offering a feature-buy title must either use a build with the mechanic absent or a certified platform toggle that removes the option for UK-facing sessions.
Does a feature-buy option require a separate RTP certification?
Certification is per build and per math model. Whether the feature-buy is certified separately from the base game depends on the jurisdiction and the lab’s scope determination. A studio should inform the certification lab that the build contains a feature-buy mechanic and its current configuration status, and confirm the expected scope before submitting: a lab evaluating the base game only, without knowing the buy mechanic exists in the build, is evaluating an incomplete scope.
What RTP figure does an operator publish for a game with a feature buy?
The operator must publish RTP information for each wager option that a player can commit to. Publishing only the base-game RTP when a feature-buy option is available is inaccurate for at least one wager type. The studio is the source of the feature-buy RTP figure, and the brief should specify when and how that figure is provided to the operator for publication.
