RGS, aggregator, platform, and operator: what each does

What is the short answer?

An RGS commonly runs game logic and game-session services, an aggregator commonly connects many content sources through one commercial or technical layer, a platform commonly coordinates player and operational capabilities, and an operator presents the regulated service to customers. These are procurement labels, not universal legal definitions.

One vendor may provide several layers, and different markets can assign responsibilities differently. Replace the labels with a written map of systems, entities, data, controls, and contracts before making a decision.

What does a remote game server own?

A remote game server, or RGS, commonly hosts or coordinates server-side game functions and exposes interfaces used to launch and operate games. Its actual boundary may include game logic, outcome generation, session state, configuration, reporting, content delivery, or only a subset.

Ask whether the RGS owns the authoritative outcome and transaction records, how it reconciles with wallets, how game versions and configurations are controlled, and which testing evidence applies to the exact deployed components.

What does an aggregator own?

An aggregator commonly provides a normalized route to multiple studios or game systems. The layer may cover one integration, a content catalog, commercial settlement, certification coordination, monitoring, reporting, or promotion tooling—but the included responsibilities vary widely.

Ask which relationships and interfaces the aggregator truly owns. A single API does not automatically create one incident owner, one approval, one data controller, or one consistent service level across every underlying supplier.

What does a platform own?

A platform commonly coordinates customer accounts, wallets or transaction ledgers, product configuration, reporting, back-office workflows, integrations, and operational controls. Some products are broad turnkey systems; others provide a narrower orchestration layer.

Use the build, buy, or integrate framework to decide which platform capabilities must remain owned. Then compare the available models in the platform delivery comparison.

What does an operator own?

The operator commonly owns the customer-facing service and the operating decisions required by its licenses and markets. Outsourcing technology or operations does not by itself transfer every legal, conduct, security, data, or customer responsibility.

The exact responsibility must be confirmed against the target jurisdiction, licenses, contracts, and qualified advice. Do not use a system diagram as a legal conclusion.

Which boundaries belong in the architecture record?

Boundary	Questions the record should answer
Identity and account	Who collects, verifies, stores, changes, and audits customer data?
Wallet and transactions	Which ledger is authoritative, and how are retries and reversals reconciled?
Game session	Who creates, resumes, ends, and investigates a session?
Content and configuration	Who approves a game, market, version, limits, and availability?
Reporting	Which system creates each regulatory, financial, and operational record?
Incident response	Who detects, communicates, contains, restores, and preserves evidence?
Change and exit	How is a release approved, and how can data and service move later?

How should buyers use these labels?

Use the labels to begin discovery, then compare vendors against the same responsibility matrix. Record every included service, dependency, assumption, exception, evidence source, and accountable owner.

When custom platform or game work is a plausible choice, Wizards describes its platform-development approach. Compare it with licensed and aggregated models using the same boundaries; Wizards operates GEN, so that relationship is visible here.