How to Redistribute Games Through a Remote Gaming Server (RGS) in iGaming

There is a version of this topic that stops at the definition — an RGS hosts games, operators connect by API, everyone wins. That version is not useful to anyone who has to actually build or buy one. The interesting questions in game redistribution are not what an RGS is. They are: which topology do you distribute through, what exactly does the integration contract specify, who holds the player balance during a round, what happens when a wallet call times out mid-spin, how many certifications do you really need, and where does the money go on each spin.

This guide answers those. If you want the architectural fundamentals of the server itself — the layer model, the 48-millisecond round trip, RNG internals — that is covered in our companion piece, what a Remote Gaming Server is and how it works. This article is about the layer above: turning a certified game engine into a distribution business.

What Game Redistribution Through an RGS Actually Means

The distinction that matters commercially is between integration and distribution. Integration is a one-to-one engineering task: connect system A to system B. Distribution is a one-to-many product: build an interface once and let partners consume it repeatedly without your engineering team being involved in each connection. The entire value of an RGS as a business asset comes from moving your content delivery from the first model to the second.

That shift changes what you are actually selling. A studio without distribution infrastructure sells games as projects. A studio with an RGS sells access to a catalogue as a recurring royalty stream that scales with partner count rather than with headcount. This is why the RGS is consistently the highest-leverage engineering investment a content business makes — and why owning it, rather than renting it, determines both margin and enterprise value. Talk to Capermint about owning your distribution layer.

The Four-Layer Content Supply Chain

RGS vs Aggregator vs PAM vs Casino Platform

The Four Distribution Topologies

Every Integration Method: How Content Physically Reaches the Operator

Method 06 in Detail: Source Code and Binary Distribution

There are legitimate reasons to do it. Some jurisdictions mandate that gaming systems and player data reside on domestic infrastructure, which makes a foreign-hosted RGS non-compliant. Some land-based and hybrid operators require on-site deployment. Some strategic licensing deals — where a large operator wants a title exclusively and permanently — are structured as a code licence rather than a service. And white-label engagements, where a client buys the platform outright, are source delivery by definition.

• Deliver compiled binaries, not source, unless the contract explicitly buys the source. A signed, obfuscated package running in a controlled container gives the operator deployment without handing over your math model.
• Keep the RNG and math model server-side even on-premise. On-premise means their data centre, not their client. The outcome must still be produced by a server component you specified and certified.
• Version-pin and sign every build. The operator, the regulator and you must all be able to prove which exact build produced a given round. Unsigned deployments make disputes unwinnable.
• Contract the RTP configuration explicitly. If the operator can alter RTP on their own deployment, you have handed them the ability to break your certification while your name is on the game.
• Require telemetry back to you. Round-level reporting returned to your systems, or you have no visibility of performance, no basis for royalty calculation and no defence if something goes wrong.
• Define the termination artefact. What happens to the deployed code when the agreement ends? Without an explicit destruction and attestation clause, it simply keeps running.
• Price for the loss of control. Source and binary distribution should never be priced like an API integration. You are trading recurring revenue and control for an upfront sum — the number has to reflect that.

Game Engine Architecture: Inside the RGS or Alongside It?

The practical consequence is that these are not competing choices so much as sequential ones. A studio starts with an embedded engine because it is the cheapest way to ship a catalogue. The moment it wants to carry other people's games — the RGS-to-RGS aggregation topology — it needs the GS bridge pattern, because it cannot embed a third party's proprietary math into its own process. Building the bridge capability from the start is far cheaper than retrofitting it around an engine that assumed it owned every game.

Deployment Models: Where the RGS Itself Runs

The Integration Contract: What You Are Actually Publishing

The Game Launch and Round Flow

Every redistributed game round follows the same sequence regardless of topology. Understanding it is what lets you reason about failure.

Seamless Wallet vs Transfer Wallet

The practical guidance for anyone building distribution infrastructure: implement seamless first and treat it as the contract, then add transfer wallet as an explicitly supported compatibility mode. Building transfer-first and retrofitting seamless is substantially harder, because seamless imposes stricter requirements on transaction atomicity, idempotency and timeout handling that are difficult to introduce after the fact.

Idempotency, Rollback and Reconciliation

• Idempotency keys on every mutating call. The operator must guarantee that receiving the same key twice produces the same result once. A timeout is not a failure — the debit may have succeeded and only the response was lost. Without idempotency, your retry policy is a double-charging mechanism.
• A defined timeout budget, agreed in writing. Specify how long the RGS waits for a wallet response and exactly what it does on expiry: retry with the same key, roll back, or hold the round pending. Undefined timeout behaviour is the root cause of most cross-party disputes in distribution.
• Deterministic round recovery. If a player disconnects mid-round, the client must be able to query the round state on reconnect and either complete it or void and refund it. Regulators such as the UKGC and MGA expect a documented interruption recovery procedure as part of certification.
• Rollback that is itself idempotent. Rolling back the same transaction twice must not double-credit. This sounds obvious and is one of the most frequently mis-implemented parts of an operator wallet.
• Round-level daily reconciliation. Compare your round records against the operator's transaction records every day, automatically, and alert on divergence. Monthly reconciliation means discovering a systematic mismatch after thirty days of compounding.
• An agreed cut-off and timezone. Your GGR day and the operator's GGR day must start at the same instant. If they do not, your invoices and their reports will never agree and someone will assume bad faith.
• Immutable round records on both sides. Write-only compliance storage with no update or delete path. Regulators expect a forensically sound trail, and partners expect an authoritative record when a player disputes a result.

Multi-Tenancy: The Architecture Decision That Decides Your Ceiling

What must be configurable per tenant, without a code deployment:

Certify Once, Distribute Everywhere — and Where That Stops Being True

The distinction that trips up first-time distributors is between three separate things that all get called "certification":

• Platform certification. The RGS itself — RNG implementation, transaction integrity, session handling, logging, recovery — assessed against a standard such as GLI-19 for interactive gaming systems or GLI-33 for event wagering. This is the expensive one, and it is the one you reuse. Independent RGS certification is treated as a distinct discipline from game testing, not an extension of it.
• Game certification. Each title's math model, RTP, volatility, hit frequency, bonus mechanics and maximum win are verified against the certified documentation, typically by simulating very large numbers of rounds. On an already-certified engine this is a delta test, which is what makes shipping a new title commercially viable.
• Market approval. Jurisdiction-specific authorisation to offer that content to players in that territory. Some markets maintain a register of approved games and require pre-approval before activation. This is per-market and it does not transfer.

Jurisdictional Content Gating

• Gate at launch, not in the lobby. Filtering the catalogue in the operator's front end is presentation. The authoritative check must happen when the RGS issues a game session, because that is the point you control and the point a regulator will test.
• Maintain a per-market approved title register inside the platform, mapped to each market's regulator requirements, updated as approvals are granted and withdrawn.
• Feature-level gating, not just title-level. Some markets prohibit specific mechanics such as autoplay, turbo spin or bonus buy while permitting the title itself. Your configuration model needs that granularity.
• Certified RTP variants per market. Where a market mandates an RTP band, the platform must serve the correct certified variant of the same title, and prove which variant a given round used.
• Fail closed. If jurisdiction cannot be determined with confidence, refuse the launch. An undetermined market is not a permitted market.
• Log every gating decision. Which title, which operator, which market, which outcome, which rule fired. This is the evidence that you enforced the register.

The GDK: Why Some Catalogues Grow Faster Than Others

If your ambition includes RGS-to-RGS aggregation or hosting third-party studios, the GDK stops being internal tooling and becomes the product surface those studios evaluate you on. The questions serious studios ask before committing to a platform:

• Can front-end and back-end teams work independently? A client developer must be able to build against a mock server, and a math developer must be able to validate a model without a finished client.
• How good is the forced-outcome tool? Being able to force a specific reel result, bonus trigger or jackpot hit is what makes testing deterministic. Without it, QA is probabilistic and slow.
• Are free rounds, jackpots, tournaments and bonus buys native? If these are per-game bespoke work rather than platform primitives, every title re-implements them and every implementation is a new certification surface.
• How is localisation and currency extension handled? Adding a currency or language should be configuration. If it requires a game rebuild, expansion into new markets is gated on engineering.
• Is round replay supported? Several regulators require the ability to replay a specific historical round exactly. If the platform cannot, those markets are closed to you.
• How does a finished game reach operators? The GDK is only half the story — the platform must also carry the finished title into aggregator and operator integrations without additional per-partner work.

The Revenue-Share Stack: Where the Money Goes Per Spin

Operator Onboarding: Two Weeks or Two Quarters

Running Distribution at Scale

Once you have partners live, distribution becomes an operations discipline rather than an engineering project. The things that separate platforms that scale to hundreds of partners from those that stall at twenty:

• Self-service partner provisioning. Creating a tenant, issuing credentials and opening sandbox access should be an operation in your back office, not a ticket to engineering.
• Per-tenant observability. Wallet call latency, error rate and timeout rate broken out by operator. When a partner reports "the games are slow," you need to know within a minute whether it is your platform or their wallet.
• Automated daily reconciliation with alerting. Every partner, every day, with divergence thresholds that page a human. Reconciliation discovered by the partner first is a trust event.
• Release management that does not require partner coordination. New titles and platform updates ship without every operator scheduling a release window. This is only possible with strict backward compatibility on the integration contract.
• Contract versioning. When the integration contract must change, run versioned endpoints and migrate partners individually. A breaking change applied globally will take down partners who did not have capacity to migrate.
• A revenue and settlement engine. Calculating what each partner owes across per-title rates, minimum guarantees and market splits is a real system. Spreadsheet settlement fails somewhere around partner fifteen.
• Support tiering and escalation paths. Define what partners can self-serve, what your first line handles, and what escalates to engineering. Without this, every partner query becomes an engineering interrupt. Capermint builds the partner back office alongside the platform.

Redistributing Across Verticals: Casino, Sweepstakes, Sportsbook, Poker and Beyond

Build, Buy or White-Label Your Distribution Platform

What a Distribution-Ready RGS Costs to Build

Below is an indicative component breakdown for a multi-tenant, distribution-ready RGS at Capermint's India engineering rates. Ranges reflect scope: a single-vertical casino RGS sits at the lower end, a multi-vertical platform with a full GDK and RGS-to-RGS aggregation at the upper.

Costs outside the platform build: third-party laboratory certification fees, per-jurisdiction market approval costs, licensed odds or sports data feeds if sportsbook is in scope, cloud infrastructure, and ongoing certification renewals when the platform materially changes. Capermint also offers a revenue-share engagement with zero upfront development cost, where the engineering investment is exchanged for a percentage of platform GGR — suited to teams with market access but limited build capital.

Five Failure Modes That Kill Distribution Platforms

• Non-idempotent wallet calls. A retry after a lost response double-debits a real player. It produces reconciliation breaks, regulatory incidents and partner distrust simultaneously. Enforce idempotency keys at the contract level and actively test duplicate delivery in your sandbox.
• No defined round recovery. A player disconnects mid-round and the bet sits in limbo with no deterministic resolution. Regulators expect a documented interruption recovery procedure; partners expect a support answer. Define completion versus void-and-refund before launch.
• Single-tenant architecture retrofitted for many operators. The system was built for one partner, then adapted with per-partner branches and conditionals. Maintenance cost now grows linearly with partner count, destroying the exact economics the RGS model exists to create.
• Hard-coded jurisdiction rules. Adding a market requires a code change and a release. Regulated expansion becomes gated on engineering capacity, and a mis-served title in an unapproved market becomes your partner's compliance incident.
• Reporting built as an export button. If the data model does not capture every round with tenant, title, market, currency and version dimensions from day one, every operator query and every regulator request becomes an engineering ticket. Reporting is a data-model decision, not a feature you add later.

Why Capermint for RGS and Distribution Engineering

Capermint builds Remote Gaming Servers, casino game aggregators and iGaming platforms for studios and licensed operators across Europe, APAC, LATAM and MENA. We are an engineering partner, not a platform landlord: we do not hold your source code, we do not take a permanent slice of your GGR by default, and we have no commercial interest in you remaining dependent on us.

Capermint iGaming & Platform Services

Key Terms in RGS Game Distribution

Remote Gaming Server (RGS)

The certified backend that executes game logic, invokes the RNG, produces outcomes, writes compliance records and exposes the API through which operators consume content. Owned typically by the game studio or by an operator with proprietary content.

Game aggregator

A layer above the RGS that integrates many studio RGSs and resells access to all of them through a single unified API and one commercial contract. Gives operators breadth quickly and gives studios reach quickly, in exchange for a markup on the studio's wholesale rate.

Seamless wallet

The wallet model in which the player balance remains with the operator and the RGS calls the operator's wallet API synchronously for each bet and win. Produces one balance and one transaction history across all products. The modern default.

Transfer wallet

The wallet model in which funds move into a game session at launch and back out at exit. Removes the per-round dependency on the operator wallet but introduces balance sync issues, slower game switching and fragmented bonus tracking.

Idempotency key

A unique identifier attached to a mutating request so that receiving it more than once produces the effect only once. The mechanism that prevents a network retry from double-debiting a player. Non-negotiable on every wallet call.

Round recovery

The defined process by which an interrupted game round is resolved when a player reconnects — either completing the round from persisted state or voiding and refunding the bet. Regulators expect this procedure to be documented as part of certification.

Multi-tenancy

Architecture in which one platform instance serves many operator partners, with every request, record, configuration value and report scoped to a tenant. The property that allows partner count to grow without maintenance cost growing with it.

GDK (Game Development Kit)

The toolset an RGS exposes so game teams can build titles on the platform: client-server protocol, math harness, free rounds, jackpots, tournaments, bonus buy support, and forced-outcome tooling for deterministic testing.

Certify once, distribute everywhere

The economic principle that certifying the RGS platform and RNG once allows subsequent titles on that engine to require only a delta test rather than a full platform re-evaluation. Reusable across titles, but not across jurisdictions.

Jurisdictional content gating

Enforcing at launch time, from configuration, which titles and features may be served to which markets, backed by a per-market register of approved games. Prevents serving unapproved content into a regulated territory.

GLI-19 / GLI-33

Gaming Laboratories International standards for Interactive Gaming Systems and Event Wagering Systems respectively. Casino and slot distribution is governed principally by GLI-19; sportsbook distribution by GLI-33. Some businesses need both.

RGS-to-RGS aggregation

Connecting a third-party studio's RGS upstream into your own platform so their titles are distributed alongside your own to your operator network. The technical basis of becoming an aggregator rather than only a supplier.

Wholesale vs retail content rate

The wholesale rate is what a studio charges an aggregator; the retail rate is what the aggregator charges the operator. The difference is the aggregator's markup, commonly cited at five to fifteen percentage points on top of the studio rate.

Round replay

The ability to reproduce a specific historical game round exactly as it was played, from stored seed and state. Required by several regulators, and impossible to add retrospectively without the necessary data having been captured all along.

Frequently Asked Questions

---