RGS vs Aggregator vs Game Provider: What’s the Difference?

Three terms come up in almost every iGaming supply conversation: RGS, aggregator and game provider. They get used interchangeably, and that is where partnership decisions start to drift. Each role does a different job, sells to a different buyer and earns money differently. This article separates the three for studios building games and operators assembling portfolios.

Three roles, three different jobs

The confusion is understandable. All three sit between a game and a player, and one company can wear more than one hat. But the contract you sign, the integration you build and the revenue you share depend on which role you are buying.

Remote gaming server (RGS)

An RGS is the back end that runs a game. It holds the game logic and maths, generates outcomes, handles bets and settles results into the operator’s wallet. It is infrastructure, not content: it decides how games run and how they are certified, not which games exist. In practice it turns a finished build into something an operator can launch.

Casino game aggregator

An aggregator is a distribution layer. It connects many studios’ catalogues to many operators through one integration and handles the plumbing in between: contracts, availability, versioning, reporting. Its product is reach. An operator that integrates once can open dozens of studios; a studio that signs once can reach operators it could never sell to directly.

Game provider

A game provider is the name on the game. It owns or commissions the content, takes responsibility for quality and compliance, and supplies it to operators through licensed channels, often using an RGS for the technical side. Its product is the game itself.

How the three roles compare

The table below is the short version.

From a studio’s point of view

A studio has a game, or a plan for one, and needs three things: somewhere to run it, someone to certify and host it, and a route to operators. It is easy to assume an aggregator solves all three. It does not: an aggregator distributes games that are already runnable.

That is why the RGS decision comes first. It sets your maths architecture, your integration surface and how quickly a new title can go live. Choose it well and distribution becomes a commercial question rather than an engineering one.

Studios that want to own the whole chain can work with a provider platform instead of assembling vendors: development environment, remote gaming server, maths and simulation, QA and certification support, distribution and analytics under one agreement. That is the model on our game provider programme page.

Standalone RGS businesses exist too. Hacksaw Gaming positions OpenRGS as an RGS and development platform for studios; Tequity offers an RGS and publishing platform. Both are useful reference points.

From an operator’s point of view

An operator’s problem is portfolio breadth without integration debt. Every studio added directly is another contract, integration and reporting stream. Aggregators compress that cost, and for a broad catalogue they do it well.

But aggregation does not answer the question of differentiation. If every operator on the same aggregator runs the same catalogue, the portfolio becomes a default rather than a product decision. Operators that want exclusive or creator-led content need a direct route too: an API that brings local studios into the lobby.

That is the operator-side case for a casino game SDK, where a single casino game API and RGS integration let new titles plug in without re-engineering the wallet or the lobby. The integration scope is on the casino game SDK page.

Common mistakes

Treating the terms as synonyms

“We signed an aggregator, so we have a provider” is a shortcut that hides a gap. Aggregation gives you access; it does not give you the RGS, the certification ownership or the game roadmap. Ask which role each counterparty is contracted for.

Choosing the model before the requirement

A studio that signs distribution first and infrastructure second ends up with a catalogue entry it cannot update quickly. An operator that signs an RGS and nothing else gets infrastructure with no content.

Leaving compliance ownership unclear

Certification, jurisdictional requirements and maths verification have an owner in every deal. When roles blur, that owner becomes ambiguous, and ambiguity surfaces at launch.

Where a platform fits

A platform model collapses the three roles into one relationship, but only where that is what you need. For studios it means the RGS, SDK, maths and simulation tooling, QA and certification support, distribution, analytics and revenue share sit with one partner. For operators it means a single API and RGS integration that brings creator-led content into the lobby.

HeronByte is a game provider based in Estonia, operating since 2018, supplying mobile-first casino content through licensed operators and partners. The platform is built around what actually breaks when a game moves from build to launch.

Which model you need depends on which role is missing: reach is aggregation work, content is RGS and platform work.

FAQ

Is an RGS the same as an aggregator?

No. An RGS runs the game: logic, outcomes, wallet integration. An aggregator distributes games that are already runnable. One is infrastructure, the other is reach.

Can a game provider also be an aggregator?

Yes. Companies can hold more than one role. The game provider vs aggregator line is contractual, not philosophical: what matters is which role is written into your deal and priced.

Do studios need an RGS if they already use an aggregator?

In practice, yes. The aggregator needs something to distribute, and the RGS is what makes the game runnable and certifiable.

What does “RGS provider” mean?

It usually means the company supplying the remote gaming server, the platform that hosts and runs the game, rather than the game content itself.

Still unsure which role your project needs? Describe the gap and we will tell you which model fits. Get in touch