Retrofitting a live game for odds disclosure compliance

The disclosure laws that are reshaping how mobile games sell random-reward purchases — South Korea's since 2024, Brazil's tightening through 2026, and others on the way — don't grandfather in existing games. A game that's been live for years still has to comply if it's selling random-reward content in those markets. The compliance work isn't a one-time setup at submission; it's ongoing maintenance over the life of the game.

Studios who built their game without disclosure in mind, and who are now trying to retrofit it without breaking the existing live experience, run into the same set of problems in the same order. The technical challenge isn't usually displaying the odds. It's keeping them accurate, surfacing them in a way that's both compliant and unobtrusive, and managing the changes over time as game balance evolves.

Done well, retrofitting is a few weeks of focused engineering work that produces a system the team is happy to maintain. Done badly, it produces a compliance theatre that satisfies neither regulators looking carefully nor players who notice when the numbers don't quite match what they see.

What the laws actually demand

The technical requirements vary by jurisdiction but converge on a small set of properties.

The odds must be accurate. Whatever number is shown to the player has to match the actual probability of receiving that outcome from the drop table. This is the most basic requirement and the one most retrofit attempts fail. A snapshot of odds captured at one point in the game's life drifts out of sync the moment a balance patch changes the underlying drop table. Six months later, the displayed odds are no longer what the game is actually doing.

The odds must be accessible at the purchase decision. Not three screens away, not in a legal page no one visits, not in a help section. The player making the decision has to encounter the odds in the natural purchase flow. Korean enforcement specifically calls out disclosures that exist technically but are not prominent or accessible enough to be considered real.

The odds must be granular enough to be meaningful. Aggregating items into broad categories ("rare items: 5%") may not be enough if the player would reasonably want to know the probability of specific items within the category. The bar for granularity is set per jurisdiction and is generally tightening over time.

The odds must be presented in the player's language and units. A disclosure that defaults to English in a Korean market, or that uses percentage formats the local audience doesn't read naturally, is technically present and functionally inaccessible.

The drop-table-to-display pipeline

The architectural problem is that the displayed odds need to be derived from the actual drop table at the moment of display, not from a hand-maintained legal text. A few patterns produce a working system.

The drop tables themselves need to be machine-readable. Many older games have drop tables that exist as scattered config files, code-level constants, or even hard-coded values inside the random selection logic. Pulling these into a single canonical representation is the first piece of work. Without it, you can't compute odds programmatically — which means any disclosure has to be hand-maintained, which means it will drift.

The probability computation needs to handle the actual selection logic. Most random reward systems are more complex than a single weighted draw. There may be guaranteed slots, cooldowns on specific items, pity timers, conditional drops, or multiple draws per pull. The disclosed odds need to account for all of this. A naive "weight divided by total weight" computation is often wrong for the actual experience the player will have.

The display layer needs to pull the computed odds at the moment of purchase. The most common shortcut is to compute the odds once at build time and ship them as static text. This works until the next balance patch changes the table. The correct architecture computes the odds live (or close to it) from the same canonical drop table the game's random selection uses. When the drop table changes, the displayed odds change automatically.

This single-source-of-truth pattern is the meaningful difference between a system that stays compliant over time and a system that requires manual maintenance forever. Studios who get this right do it once and don't think about it again. Studios who don't will be issuing odds corrections every patch cycle.

The granularity question

How granular the odds need to be is jurisdiction-specific and evolving. The safe default is per-item where the table is small enough to make that meaningful, and per-tier where it isn't.

A loot box that contains exactly 50 possible items can probably disclose each one's probability. A loot box that contains thousands of cosmetic variants probably can't — the disclosure would be unreadable. In that case, per-tier disclosure (legendary: X%, epic: Y%, etc.) is the more honest answer, with the option to show the full per-item table on request.

The trap is over-aggregating. A studio that's used to disclosing "rare item: 5%" without specifying what's in the rare pool faces increasing pressure as regulators look more carefully. The disclosure is technically present but functionally insufficient. Migrating from aggregate to granular disclosure later is more painful than starting with appropriate granularity from the outset.

Presenting odds in the purchase flow

The display question is where retrofits most often go wrong. The odds get added to the game in a defensible technical sense, but in a location no player will actually find them during a purchase. This is the kind of compliance that enforcement is increasingly catching — the law requires the player to be informed at the decision moment, not just that the information exists somewhere in the app.

The pattern that holds up to scrutiny is a clearly visible "details" or "odds" affordance on the purchase screen itself, with the actual odds one tap away (or inline if space permits). The affordance has to be prominent enough that a player not specifically looking for it would still notice. The contents have to be the real probabilities, presented in the player's language and a readable format.

Studios who do this well make the disclosure feel like a feature rather than a legal requirement. The same information that satisfies the regulator also serves the player who wants to make an informed purchase. Studios who do it badly hide the link, use legal language no player will read, or split the disclosure across multiple screens in ways that satisfy nothing.

Managing changes over time

A live game's drop tables change. Seasonal events introduce new items. Balance patches adjust drop rates. New mechanics layer onto existing ones. Each of these needs the disclosure to update accordingly, and the update has to happen at the same moment the change goes live to players — not three days later when the legal team confirms the new copy.

The single-source-of-truth pattern handles this automatically: the disclosure is computed from the live drop table, so it updates when the table updates. The teams that don't have this pattern have to remember to update the disclosure every time the table changes, and the disclosure inevitably drifts behind reality.

A useful supplementary practice is automated checks that compare the disclosed odds to the actual drop rates observed in production data. A discrepancy beyond a small statistical tolerance suggests the disclosure has drifted from the implementation, even with the single-source-of-truth in place — usually because of a code path that bypasses the canonical drop table. These checks catch bugs before regulators do.

The retrofit timeline

For a game with a meaningful random-reward catalog and no current disclosure system, a realistic retrofit takes a few weeks of focused engineering work. The major pieces: consolidate drop tables into a single canonical representation (usually the largest piece, because older games have these scattered); build the probability computation layer that correctly handles your selection logic (guaranteed slots, cooldowns, pity timers); add the display affordance on every purchase surface that touches a random-reward item; add automated checks comparing disclosed odds to observed drops; and add per-region presentation rules for language, format, and granularity.

The work isn't conceptually hard. It's mostly the discipline of treating disclosure as a system rather than a one-off legal text.

See how we handle compliance rules in the offer pipeline →

Studios who treat disclosure retrofits as a checkbox exercise produce compliance that fails inspection a year later. Studios who treat them as an engineering investment in a maintainable system are done after the initial work and don't think about it again — the only sustainable end state in a market where the underlying laws keep tightening.

Talk to us about compliance retrofitting →