Do you really have an RGS?
Many game studios that say "we have an RGS" actually have a game server: game math and a client that can play rounds in a test environment. A complete Remote Gaming Server is everything a regulated market requires around that server: a laboratory-certified RNG, a certified platform, operator wallet integration, immutable round records, live operator and aggregator integrations, a backoffice, reporting, and per-market compliance configuration. Until those layers exist and are certified, the games cannot legally earn money in a regulated market.
This page is the checklist that separates the two. It exists because the gap is real, common, and expensive to discover late: a studio can be a year into development, convinced the platform work is behind it, and still be missing most of what an operator, an aggregator, or a regulator will ask for on day one.
Where "we have an RGS" usually ends
A server that runs game logic and returns results is the visible part of an RGS. It is also the part studios enjoy building, because it is where the games live. Everything below the line is what makes those games sellable in a regulated market:
None of the layers below the line are optional, and most of them cannot be added quietly later: the RNG and the platform must pass laboratory certification before games can go live, wallet handling must survive interrupted rounds with real money in flight, and every integration is engineering work on both sides of the connection.
The completeness checklist
The table below compares a typical self-built game server with what a complete RGS contains. Nothing in it is hypothetical: every row in the right-hand column is a documented capability of a production RGS platform, not a wish list. "Varies" means some in-house builds have it in some form; the certified, market-ready version is usually still missing. Every ✗ is a build project of its own, and most rows also carry a certification, integration, or audit dependency that sits outside your codebase and outside your control.
| Capability | Game server | Complete RGS |
|---|---|---|
| Running games | ||
| Game logic and math execution | ✓ | ✓ |
| Game client delivery | ✓ | ✓ |
| Round resume after a disconnect, back to the exact same spot | varies | ✓ |
| Round history the player can open in the game | varies | ✓ |
| Replay of a round the player already played | ✗ | ✓ |
| Every ISO-4217 currency, custom currencies, and crypto sub-units | ✗ | ✓ |
| Game configuration | ||
| RTP, volatility, and paytable configuration per market | varies | ✓ |
| Multiple certified RTP variants of the same game | ✗ | ✓ |
| 60+ launch-time settings: autoplay, turbo, spin timing, stake limits | ✗ | ✓ |
| Defaults that layer across platform, operator, jurisdiction, and game | ✗ | ✓ |
| Demo play configured separately from real-money play | ✗ | ✓ |
| Custom stake ladders per currency, operator, and market | ✗ | ✓ |
| Live-linked settings templates: edit once, update every brand | ✗ | ✓ |
| Bonus features and paytables changed without an engine release | ✗ | ✓ |
| New game variants launched without platform re-engineering | ✗ | ✓ |
| Fairness | ||
| Random number generation | ✓ | ✓ |
| RNG certified by an accredited testing laboratory | ✗ | ✓ |
| Every random value persisted with its sequence number | ✗ | ✓ |
| Provably fair mode the player can verify in their own browser | ✗ | ✓ |
| Outcome forcing with ready-made rig values for lab testing | ✗ | ✓ |
| Certification | ||
| Platform certification for regulated markets | ✗ | ✓ |
| Certification workflow for each individual game | ✗ | ✓ |
| Certification maths documents generated per game version | ✗ | ✓ |
| Byte-identical builds, so certified hashes never drift | ✗ | ✓ |
| An engine that refuses to load content it is not certified for | ✗ | ✓ |
| Real money handling | ||
| Seamless wallet API against operator wallets | ✗ | ✓ |
| Dozens of wallet and aggregator protocols out of the box | ✗ | ✓ |
| Idempotent transaction keys that can never settle twice | varies | ✓ |
| Every wallet call HMAC-signed and HTTPS-only | varies | ✓ |
| Automatic retries and voids when a wallet call fails | ✗ | ✓ |
| Stranded rounds detected, aged, and settled automatically | ✗ | ✓ |
| A read-only ledger with balance before and after every call | varies | ✓ |
| Per-brand exposure caps that automatically limit stakes | ✗ | ✓ |
| Free plays and promotions | ||
| Free plays at a fixed stake, spent with no wallet debit | ✗ | ✓ |
| Grants with a count, an expiry, and an optional feature lock | ✗ | ✓ |
| A ticket ledger of every free play used or won | ✗ | ✓ |
| Spin counters so a game can never overspend a grant | ✗ | ✓ |
| Promotional discounts that debit less than the stake played | ✗ | ✓ |
| Distribution | ||
| Live operator integrations | ✗ | ✓ |
| Aggregator connectivity | ✗ | ✓ |
| Game access closed by default, opened per partner and brand | ✗ | ✓ |
| Per-operator game code aliasing | ✗ | ✓ |
| Single-use, signed launch URLs | ✗ | ✓ |
| Geo rules down to a single province or state | ✗ | ✓ |
| Scripted wallet test suites with exportable PDF reports | ✗ | ✓ |
| One client protocol that behaves correctly in every lobby | ✗ | ✓ |
| Operations | ||
| Backoffice for configuration and reporting | ✗ | ✓ |
| Fine-grained roles, with partner logins scoped to their own data | ✗ | ✓ |
| Forensic round reconstruction: bets, wins, transactions, visuals | varies | ✓ |
| Any round rendered as an HTML or PDF document for a dispute | ✗ | ✓ |
| An audit trail with actor and before/after values on every change | ✗ | ✓ |
| Log search across every site, scoped to your own workspace | ✗ | ✓ |
| Monitoring and live reporting | ||
| Health checks on every game engine and the RNG, per site | ✗ | ✓ |
| Statistics pulled live from each site, not from a stale copy | ✗ | ✓ |
| KPI dashboards filterable by brand, game, currency, and stake | ✗ | ✓ |
| Measured RTP reported next to bet and win totals | ✗ | ✓ |
| EUR-normalised figures aligned to UTC billing days | ✗ | ✓ |
| Watchdogs that flag stuck imports and stranded rounds | varies | ✓ |
| A stats API operators can pull into their own reporting | ✗ | ✓ |
| Compliance and hosting | ||
| Ready-made jurisdiction profiles per regulator | ✗ | ✓ |
| Distribution blocked outside a game's approved jurisdictions | ✗ | ✓ |
| RTP, win odds, and net position disclosed where a market requires it | ✗ | ✓ |
| Regional deployments matched to latency and data residency | ✗ | ✓ |
| Isolated staging and production estates, provisioned as code | ✗ | ✓ |
| Information security certification (ISO 27001) | ✗ | ✓ |
Count the checkmarks. A typical game server holds three of the 65 rows outright: it runs math, serves a client, and generates random numbers. A handful more land on "varies". Everything else is open, and none of it is polish: no row on this list is optional in a regulated market, and no operator, aggregator, or laboratory will waive one because the games are good.
To be clear about what this does not mean: a game server is genuinely valuable. It is the creative core of a studio, the part that makes players choose your games over anyone else's. But three rows out of 65 is not an RGS. It is the start of one.
Ten questions that settle it
If the table feels abstract, these questions are not. A studio with a complete RGS answers all ten without hesitation:
- Is your RNG certified by an accredited testing laboratory, and can you produce the certificate?
- Has the platform itself passed laboratory certification, not only individual games?
- Can you settle a real money bet against an operator's wallet today, including rollbacks for interrupted rounds?
- How many live operator or aggregator integrations do you have?
- Can you reproduce any historical round, bet by bet, for a player dispute or a regulator?
- Can your team change RTP variants or paytables per market without a developer touching code?
- Does your backoffice show you rounds, sessions, and revenue live, in the reporting an operator expects?
- Who responds when the platform goes down at 3 a.m. on a Saturday, and within what SLA?
- Which regulated markets is the platform configured and certified for, specifically?
- When did the platform last pass an independent security audit?
Several answers of "not yet" mean the honest description is: you have a game server, and the RGS is still ahead of you. That is a normal place for a young studio to be. The mistake is not the gap; the mistake is planning, pitching, and budgeting as if the gap were already closed.
Closing the gap
There are two ways to close it. Building the remaining rows in-house means engineering the wallet layer, logging, backoffice, and integrations, then taking the whole platform through laboratory certification, which for a new studio typically means a year or more before the first game earns money; the full numbers are in How much does an RGS cost in 2026? and the decision framework in Should you build or rent an RGS?. Renting closes every row at once, because the platform, its certifications, and its integrations already exist.
How hizi.io closes it
hizi.io rents the complete checklist as a Game-Studio Operating System: seven modules covering backoffice, a no-code game-engine builder, aggregation, billing, hosting, compliance, and integrations, month to month under online T&Cs with public pricing from EUR 500 per month. The platform runs a certified RGS and certified RNG, tested by BMM Testlabs, Gaming Associates, Risk Cherry, and iTech Labs, is ISO 27001:2022 certified, and connects to around 100 aggregators, operators, and studios, with every operator integration built by hizi free of charge. A live sandbox RGS is available about 3 minutes after signup, and production setup happens within one business day. Your game server, meanwhile, stays exactly what it should be: the place where your games are made.
Live sandbox in about 3 minutes. Full platform access, online T&Cs, cancel anytime.
Start your 28-day trial →