Age-aware offer design: what 2026 compliance requires

Until recently, the player's age was a piece of information most mobile studios didn't have. The major storefronts knew it — they had to, for parental controls and rating filters — but they didn't pass it through to publishers. Studios designed offers as if every player was equivalent, with at most some self-declared age input on first launch.

That's changing fast. Apple and Google announced they will pass age information through to publishers as US state-level age verification rolls out, with Texas, Utah, and Louisiana already live since the start of 2026 and more states expected through the year. PEGI's 2026 reforms in Europe tie age ratings to monetisation mechanics. Brazil's digital protection law mandates age verification at the purchase point for paid random rewards. South Korea's enforcement actions on disclosure compliance are active.

The result is that mobile studios are about to have age data in a form they can actually use — and a regulatory environment that increasingly expects them to use it. Designing offers as if every player is the same will become both commercially suboptimal and increasingly non-compliant.

What "age info from the storefront" actually delivers

The age data that flows through from the platforms is not necessarily a player's exact age. It's typically an age tier or band, sufficient for the platform's own filtering needs. A studio receives a signal that the player is under 13, 13-17, or 18+ — not the player's birthday.

That granularity is enough for the major compliance decisions. Whether to show paid random-reward offers, whether to enable certain monetisation mechanics, whether to apply parental control language, and whether to surface specific marketing — these decisions operate on tier boundaries, not on individual ages.

The data is also more reliable than the self-declared age input on first launch. A player who taps through an age gate quickly to start playing isn't engaging with that information honestly. A platform-level age signal, where the player or their guardian set their account up with their real birthday, is much closer to accurate. For the first time, studios can act on age with reasonable confidence that the signal is real.

What changes about offer design

The most direct change is that offers can be filtered or substituted based on the player's age tier, without the studio having to ask.

For under-13 players, the right defaults are conservative across the board. No paid random-reward mechanics. No time-pressure offers that trip the PEGI 12 threshold. Simplified pricing. Restricted personalisation. The set of offers visible to this segment should be a deliberate subset of the full catalog — not a "we'll figure it out later" assumption that no one in this segment buys anyway.

For 13-17 players, the picture is more nuanced. Some markets allow paid random rewards in this tier with disclosure; others (Brazil, increasingly) restrict them. The right approach is to design the catalog so that the offers visible to teenage players are jurisdiction-aware — what's permitted in one market may be prohibited in another, and the right line is set by the market the player is in, not by a global studio default.

For 18+ players, the catalog can operate under standard market rules. But even here, the signal is useful — it removes ambiguity about whether the player can be shown certain offers, and it provides a defensible audit trail if a question is raised later.

The offer system needs to handle three independent inputs at the moment an offer is built: the player's age tier, the player's market jurisdiction, and the offer's category. The combination of these three determines what's eligible to show. Studios that haven't structured their offer pipeline to handle this kind of three-way filter will find themselves either over-restricting (showing the most conservative offer everywhere) or under-restricting (missing compliance edges in specific markets).

The four-regime problem

The reason age-aware design is becoming necessary now is that the compliance picture has fragmented into multiple regimes that need to be handled in parallel.

In Europe, PEGI 2026 ties ratings to monetisation mechanics from June 2026. Loot boxes push a game to PEGI 16 minimum; time-limited offers to PEGI 12; return-reward mechanics to PEGI 7 with a new descriptor. The ratings don't directly prohibit purchases, but they affect addressable audience, parental control filtering, and store featuring.

In Brazil, paid loot boxes in games reaching minors are banned outright as of March 2026, with strong age verification and parental control mandates, fines up to 10% of revenue, and the threat of service suspension for non-compliance.

In the US, state-level age verification is rolling out — three states live since January 2026, more expected. The mechanism varies by state, but the direction is consistent: platforms will know player ages and pass that info to publishers, and publishers will be expected to act on it.

In South Korea (and China and Taiwan), odds disclosure for random-reward purchases has been actively enforced since 2024, with real fines for non-compliance. Disclosures must be accurate, prominent, and accessible at the purchase point — not buried.

A single global build now needs to handle all four. A single age tier interacts with these regimes differently — a 13-year-old in Brazil cannot see paid random rewards at all; a 13-year-old in the US sees them but the studio must respect the platform's age signal; a 13-year-old in Korea sees them with mandatory odds disclosure; a 13-year-old in the EU sees them only in PEGI 16+ rated games. The same mechanic, applied to a similar-aged player, lands differently in each region.

What this looks like in the offer pipeline

The architecture implication is that age and jurisdiction need to be first-class inputs to every offer decision, not optional filters applied at the end.

Concretely, the offer-building step needs the player's age tier and the player's market jurisdiction before it builds the offer, not after. A pipeline that picks the offer first and then asks "is this allowed" risks routing computational effort into offers that can't be shown — and in the worst case, occasionally showing one anyway because the compliance check didn't catch every path.

The cleaner pattern is to use age tier and jurisdiction as inputs to the offer catalog filter that runs first. The offer engine then operates on a pre-filtered set that's already known to be eligible for this player. The compliance check becomes a final defence-in-depth pass, not the primary gate.

This also means the offer catalog needs to be tagged with the regulatory metadata — which markets the offer can run in, which age tiers it can be shown to, whether it contains random-reward mechanics, whether it carries time pressure. Catalog entries without this metadata can't be safely served in a multi-jurisdiction build. Adding it retroactively to an existing catalog is unpleasant work; building it in from the start is much easier.

What to do now

A short list of practical steps for studios who haven't started:

Tag every entry in your offer catalog with two pieces of metadata: the markets it's eligible for, and the minimum age tier it can be shown to. If you can't fill this in for a catalog entry, that entry isn't safe to serve in a multi-jurisdiction build.

Build the offer pipeline to accept age tier and jurisdiction as inputs and to filter the catalog accordingly before any other decision. If your current pipeline picks an offer first and checks compliance second, restructure it. The order matters.

Update your testing to cover the four-regime matrix. A test that confirms an offer works for an 18+ US player tells you nothing about whether it's appropriate for a 13-year-old in Brazil. Each regime needs explicit coverage.

Treat the age signal from the platform as the authoritative one — not a self-declared age stored in your own database. The platform's signal is what regulators will eventually inspect.

See how we handle age and jurisdiction in offer rules →

The studios that build age-aware offer design into their pipeline now will adapt to the next jurisdiction that acts with a configuration change. The studios that treat each regime as a one-off patch will be reworking the offer flow every time a state or country moves. The pace of regulatory change suggests that's a recurring cost worth designing out at the architecture level rather than absorbing in product cycles.

Talk to us about age-aware and jurisdiction-aware offer design →