RTP Configuration Model

RTP (Return To Player) - the percentage of theoretical return over a long distance, specified by the mathematics of the game/variant. In production, RTP turns into a set of controlled restrictions and signals: where, to whom and under what conditions one or another version of mathematics is allowed (97/96/94/92 etc.), how to count the actual return, how to respond to deviations and how to document changes for compliance.

1) Terms and levels

Theoretical RTP (tRTP) - declared mathematics of the variant (certified).
Effective RTP (eRTP) - expected return in sales, taking into account options (jackpot bonus, bonus buy, side-bets, provider commissions).
Realized RTP (rRTP) - actual return by time window/rounds (empirical).
RTP Variant - specific build/profile of the game (e.g. 96. 5%).
RTP Band/Policy - allowed ranges for jurisdictions/tenants.

The purpose of the model is to bind the allowed tRTP to the launch context (tenant, region, currency, channel) and be able to verify eRTP/rRTP over SLO.

2) Configuration measurements (where we set the rules)

1. Provider/Game/Variant - what is supported at all.
2. Tenant/Brand - commercial and UX solutions (which RTP to show).
3. Region/Jurisdiction - Licenses and Regulatory Frameworks.
4. Channel - web/native/retail/terminal (sometimes pools/parameters are distinguished).
5. Currency - overlaps with jackpots and commissions (affect eRTP).
6. Time windows - promotional periods, canary calculations.

3) Hierarchy, priorities, merge

GLOBAL_DEFAULT < PROVIDER < GAME < VARIANT < TENANT < REGION < CHANNEL < CURRENCY < WINDOW

Where there is no concretization, we inherit from the parent. Any explicit deny overlaps allow at underlying levels.

4) Configuration diagram (YAML, example)

yaml rtp_config:
schema_version: 1 global_defaults:
allowed_bands: [96, 95, 94] # percentages rounded to whole min_band: 92 show_rtp_label: true # show RTP in the providers directory/card:
prag_play:
games:
gates_of_:
variants:
"96. 5": { status: "allow", label: "96. 5%" }
"94. 0": { status: "allow", label: "94%" }
"92. 0": { status: "deny" }
jackpot_uplift_bps: 35       # +0. 35% to eRTP with tenant pool active:
brand_eu:
regions:
EE:
bands_allow: [96, 94]
default_band: 96 channel:
web:  { bands_allow: [96], default_band: 96 }
retail:{ bands_allow: [94], default_band: 94 }
DE:
bands_allow: [94]
default_band: 94 compliance:
mandate_rtp_label: true currencies:
EUR:
fee_bps: 0 # impact on eRTP
TRY:
fee_bps: 10           # -0. 10% eRTP on paid rollout features:
canary:
brand_eu: { region: "EE", game: "gates_of_", variant: "96. 5", traffic_pct: 10, ends_at: "2025-11-07T00:00:00Z" }
sla:
monitoring_windows:
- { name: "daily",  duration_h: 24, min_rounds: 1_000 }
- { name: "weekly", duration_h: 168, min_rounds: 10_000 }
ertp_tolerance_bps: 50  # eRTP vs tRTP, ±0. 50% for information alerts rrtp_tolerance_bps: 150 # rRTP vs tRTP, ± 1. 50% on weekly window

5) Pre-publication validation

Option certification: the option has a valid certificate/build ID.
Jurisdictional framework: the band chosen is allowed in the region.
Compatibility feature: bonus buy/jackpot/side-bets do not take eRTP out of bounds.
UI contracts: 'show _ rtp _ label' flag/mandatory label for some markets.
Consistency: there is a default band for each context (so that there are no "holes").
Dry-run: calculation of eRTP using formulas and comparison with SLO/tolerances.

6) How to read eRTP

eRTP = tRTP
+ jackpot_uplift
+ side_bet_uplift
- provider_fee
- platform_fee
- bonus_buy_friction

• jackpot_uplift - progressive pool surcharge (bps, depends on pool size and rate).
• side_bet_uplift - expected share of side-beta (if applicable).
• provider/platform_fee - fixed/interest per round/bet, sometimes tied to currency.
• bonus_buy_friction - "friction" from the mechanics of buying a bonus (if the cost is higher than the fair value).

All terms and sources are considered deterministic and are logged in the configuration event.

7) Effect of feature on RTP

Bonus Buy: can change the distribution of outcomes; Fix eRTP for buy mode separately.
Jackpot: eRTP depends on accumulation; allow eRTP range, but keep checkpoints (for example, when the pool grows every N% - recalculation).
Side Bets/Feature Bets: separate RTP profiles; prohibit them in restricted regions.
Volatility profile: RTP is the same, but the variance is different; store the profile (low/med/high) next to the band.

8) Directory, startup and adapters

Directory/Read Model: store 'tRTP _ band', 'eRTP _ range', 'label', feature flags.
Game Launch: when starting a session, the adapter checks the allowed band for context; disables start if incompatible.
Round Events: In 'Round. Started/Resulted 'add' rtp _ context '(variant_id, band, flags) - this will simplify auditing and metrics.

9) Monitoring, SLO and drift

• 'rRTP _ window _ daily/weekly '- actual return by windows.
• `rounds_count`, `stake_sum`, `win_sum`, `jackpot_contrib`.
• `deviation_bps = rRTP - tRTP` и `rRTP - eRTP`.
• 'bonus _ buy _ share ',' side _ bet _ share '- to understand the reason for the drift.
• 'jackpot _ level'and the firing rate.

10) Anti-abuse and protection

Anomalies: sharp bursts of winnings, feature buy sequences → verification by device/account/IP/segment.
Limit policies: temporarily disable bonus buy/side bets for anomalies.
Vendor-feed: check the probability of fatal outcomes with the provider's reference feed.
Hand review sampling: for games with high variance and frequent complaints.

11) Compliance and transparency

Jurisdictions: List of band and mandatory markings allowed (e.g. RTP/age warning mapping).
Certification/build ID: keep a link to the report, version math profile.
Reporting: Issue regulatory reports with 'tRTP', 'eRTP', 'rRTP' and change events.
UI/Content: in the game card - the correct RTP label and notes (if eRTP depends on the jackpot).

12) Canary releases and A/B

Canary: turn on the new band for 5-10% of traffic in one jurisdiction → monitor 'rRTP', 'rounds _ count', complaints.
A/B: compare conversion/engagement/ARPU under different band business, not only by RTP.
Auto rollback: when rRTP goes beyond critical thresholds, the configuration is rolled back.

13) Audit and Change Management

json
{
"event_type":"RTPConfigChanged",
"changed_by":"user@company",
"tenant_id":"brand_eu",
"scope":"regions. EE. games. gates_of_",
"old":{"default_band":94},
"new":{"default_band":96},
"reason":"licence_update_2025Q4",
"occurred_at":"2025-10-31T12:00:00Z"
}

Maintaining an immutable log makes it easier to resolve disputes and meet compliance requirements.

14) Testing

Contract tests: scheme validity, presence of defaults, deny/allow logic.
Property-based: 'eRTP' is within reasonable bounds for any feature combinations.
Replay - run historical rounds over new configuration (offline) → check reports.
Chaos: adapter restarts, jackpot feed lags, feature flag skips.
Golden set: a set of games/variants with reference eRTP calculations.

15) Playbooks (runbooks)

1. rRTP left below tRTP in week

Check the selection, the share of bonus buy/side bets, the relevance of the jackpot and feed.
Turn off controversial features (flag), notify the provider, turn on the enhanced log.
If necessary, temporarily switch band/variant.

2. Players' complaints about 'dishonest RTP'

Give'as _ of'configuration, build ID, weekly rRTP and calculation methodology.
Check player segment for limits/limits/responsible play.

3. UI markings mismatch

Compare'rtp _ label'with the config for the context, roll back the showcase, run e2e validation.

4. Jackpot failure

Disable uplift/labels, record separate accounting, keep the player informed of the status.

16) Typical errors

Mix tRTP and eRTP: Show theory where practice depends on jackpot/feature.
No defaults → the game starts with a "leaky" context.
Config "to the provider as a whole" without specifics on options/jurisdictions.
No sampling thresholds → false alerts on rRTP on small data.
Changes without audits and canaries → incidents in all markets at once.
Ignoring fees/fees in eRTP → discrepancy between expectations and facts.

17) Pre-sale checklist

• Each Variant has a certificate/ID and a committed tRTP.
• Each combination (tenant/region/channel) has a default_band.
• Calculated eRTP (jackpot, features, fees) and passes tolerances.
• RTP labels and jurisdictional requirements are correctly reflected in the UI.
• rRTP/eRTP monitoring and sampling thresholds are enabled; alerts are set up.
• Canary displays for new bands; auto-rollback.
• Audit changes and export reports for the regulator.
• Drift playbooks, controversial winnings, jackpot failure.
• Tests: Contract/Threshold/Property/Replay.

Conclusion

The RTP configuration model is not a "percentage in the game card," but a risk and trust management system. A clear rule hierarchy, deterministic eRTP calculation, rRTP observability, canary releases, and rigorous auditing turn a controversial topic into a predictable engineering process - product-friendly, player-friendly, and compliance-safe.