How Remote Gaming Server (RGS) Works in iGaming?

How Remote Gaming Server Actually Works?

The complete technical and commercial guide. From a single game round in 48ms to global architecture, RNG certification, regulatory compliance, and scaling to millions of concurrent players.

Architecture Deep Dive
RNG & Certification
Compliance Frameworks
Market Research 2025
$78.7B
Global iGaming GGR 2024
$2.5B
RGS Market by 2027
12.3%
RGS Market CAGR
~48ms
Full Game Round Trip
Section 01 — Market Context

Why RGS Is the Most Critical Infrastructure Decision in iGaming

The global online gambling market generated $78.7 billion in GGR in 2024, with mobile accounting for nearly 80% of all sessions. Behind every single spin, every in-play bet, every crash game round, and every live dealer hand sits one piece of infrastructure that makes it all possible: the Remote Gaming Server.

An RGS is not simply a server that hosts games. It is the central nervous system of an iGaming operation — managing game logic, Random Number Generation, transaction processing, player session integrity, regulatory compliance, content distribution to 300+ providers, and real-time analytics, all simultaneously, across millions of concurrent players.

Without a certified, enterprise-grade RGS, you cannot obtain a gambling licence in any major regulated jurisdiction. The RGS is what regulators audit. It is what testing labs certify. It is what determines your latency, your uptime, your fraud protection, and ultimately your GGR growth ceiling.

The global RGS market is projected to reach $2.5 billion by 2027, growing at 12.3% CAGR. Operators who own their own certified RGS infrastructure are consistently valued 3–5x higher than those dependent on third-party licensed platforms, because their RGS is a revenue-generating asset — not an ongoing cost.

iGaming Market Intelligence 2024–2027

Key metrics shaping RGS demand and investment decisions

Global iGaming GGR (2024)
$78.7B
Projected GGR (2027)
$112B+
RGS Market Size (2027)
$2.5B
Mobile as primary channel
~80%
Bettors using online/mobile
77%
Avg games per top aggregator
2,400+
RGS CAGR (2024–2027)
12.3%

For Game Studios

Game studios build their games once on the RGS and immediately distribute them to thousands of operators worldwide through a single API connection. The RGS handles all the infrastructure — sessions, wallets, compliance logging, RNG certification — so studios focus entirely on game design and math models. Studios typically connect via an RGS-to-RGS aggregation link or the platform's proprietary Game Development Kit (GDK).

For Casino Operators

Operators connect their front-end casino to the RGS via a single API integration and instantly unlock a library of 300+ certified games from dozens of providers. The RGS manages all the backend complexity — player sessions, wallet transactions, game logs for regulators, and bonus mechanics — allowing operators to focus on player acquisition and product experience without building backend infrastructure.

For Regulators

Regulatory bodies like UKGC, MGA, and AGCO require that every RGS undergoes independent testing and certification before any games go live. The RGS is the primary audit point — it must maintain immutable game logs, certified RNG output, player protection tools, AML transaction records, and real-time reporting. The RGS is what makes a gambling operation legally operable in a regulated market.

Section 02 — Architecture

The Complete Anatomy of an Enterprise RGS

An enterprise RGS is not a single server. It is a distributed system of specialised microservices, each responsible for one critical function, all operating in concert at sub-50ms speeds.

L1
Client & Delivery Layer
The player-facing interface communicates with the RGS via WebSocket (for real-time game events) or REST API (for session initiation and account actions). HTML5 game clients run in browser or native app and render only the visual output — all game logic stays server-side.
WebSocketREST APIHTML5 SDKiOSAndroid
L2
API Gateway & Security
All incoming traffic passes through the API gateway first. It handles JWT authentication, rate limiting (preventing abuse), DDoS protection via Cloudflare, SSL termination, and request routing to the correct microservice. This layer rejects fraudulent or malformed requests before they touch business logic.
KongJWT AuthRate LimitingWAFDDoS Shield
L3
Core Game Services
The heart of the RGS. The Game Engine processes bet requests, invokes the RNG for outcomes, applies game math models (bonus mechanics, multipliers, jackpot triggers), and returns results. The Session Manager tracks the full player session state. Each service is independently deployable and scalable.
RNG EngineGame LogicSession ManagerBonus EngineOdds Service
L4
Wallet & Transaction Services
The Wallet Service processes financial transactions atomically — debiting bets and crediting wins in a single ACID transaction to prevent any possibility of double-spending or lost funds. It integrates with the operator's wallet or manages its own, supporting multi-currency, crypto, and e-wallet providers.
Atomic TransactionsMulti-CurrencyCrypto SupportAML Hooks
L5
Cache, Queue & Event Streaming
Redis Cluster caches active sessions, odds feeds, and jackpot values in memory for microsecond access. Apache Kafka streams all game events to analytics, compliance logging, and fraud detection pipelines asynchronously — ensuring the core transaction path is never blocked by secondary processes.
Redis ClusterApache KafkaEvent StreamingRabbitMQ
L6
Data Persistence & Analytics
Every game round is written to immutable storage — MongoDB for game event logs, PostgreSQL for financial records and compliance data, and ClickHouse for high-speed analytics queries. Elasticsearch powers the back-office search and reporting tools regulators require for audit access.
MongoDBPostgreSQLClickHouseElasticsearchTimescaleDB
L7
Cloud Infrastructure & Observability
Everything runs on Kubernetes-orchestrated containers across multiple cloud availability zones for active-active redundancy. Terraform manages infrastructure as code, Prometheus + Grafana provide real-time performance monitoring, and the ELK stack handles centralised log aggregation and alerting.
KubernetesDockerAWS/AzureGrafanaTerraform
Why Microservices Architecture?
A monolithic RGS is a single point of failure. If the billing module crashes, all games go down. With microservices, each function (RNG, wallet, session) is isolated. One module can fail, be updated, or scaled independently without touching any other. This is non-negotiable for a 99.9% uptime SLA.
Why Redis for Sessions?
Database queries take 5–20ms each. For a game round requiring 3–5 lookups (session state, balance, game config), that's 75ms before any game logic runs. Redis serves the same data in under 0.5ms from in-memory storage. At scale with 50,000 concurrent sessions, this difference is the gap between a functional platform and an unusable one.
Why Kafka for Event Streaming?
The core game transaction must complete in under 10ms. Analytics, fraud detection, and compliance logging are important but not time-critical. Kafka decouples these: the transaction commits instantly, and downstream processes (fraud scoring, BI reporting, regulatory logs) consume the event stream asynchronously without ever blocking a player's game round.
Why Multi-Cloud?
Regulated markets like UKGC and MGA require data residency within specific geographies. Multi-cloud with active-active failover means if AWS eu-west-1 has a degradation event, traffic seamlessly shifts to Azure West Europe within seconds. No single cloud provider outage can take your platform offline — a requirement for any real-money gambling licence.
Why Separate Compliance DB?
UKGC and MGA require that game logs are immutable, tamper-evident, and accessible for independent audit at any time. Keeping compliance data in a separate PostgreSQL instance with write-only access from the game engine (no UPDATE, no DELETE) ensures a complete, forensically sound audit trail that satisfies the most stringent regulatory requirements.
Section 03 — Transaction Flow

What Happens in 48 Milliseconds

A single game round — from the moment a player clicks "Spin" to the moment the result appears on screen — involves seven distinct technical operations across three infrastructure layers.

STEP 1
Player Initiates Bet
0–1ms

The player clicks "Spin" or places a bet on the game client. The client immediately renders a loading animation and sends a signed, encrypted bet payload over the existing persistent WebSocket connection to the API Gateway. The payload includes the session token, bet amount, game ID, and a client-side timestamp for latency tracking.

Protocol
WebSocket (persistent)
Encryption
TLS 1.3 end-to-end
Payload size
<2KB compressed
Client state
Optimistic UI lock
STEP 2
API Gateway Authentication & Routing
1–3ms

The API Gateway validates the JWT session token against a Redis-cached session store (sub-0.5ms lookup), checks the player's account status (not suspended, not self-excluded), verifies rate limits are not exceeded, and routes the validated request to the appropriate Game Logic microservice instance based on game type and load balancing policy.

Token validation
Redis lookup <0.5ms
RG check
Deposit limit / self-excl.
Routing
Kong gateway rules
Reject rate
<0.01% valid sessions
STEP 3
Wallet Debit & Balance Lock
3–8ms

Before any game outcome is calculated, the Wallet Service debits the bet amount from the player's balance using an ACID-compliant atomic database transaction. This prevents any possibility of a player being able to bet without funds. The balance is locked for the duration of the round. If the debit fails (insufficient funds), the round is rejected before the RNG is even invoked.

Transaction type
ACID atomic debit
Concurrency control
Optimistic locking
Insufficient funds
Reject & notify client
Currency handling
18-decimal precision
STEP 4
RNG & Game Logic Execution
8–15ms

The certified RNG generates a truly random seed, which the Game Logic service passes through the game's mathematical model (the "math engine") to produce a specific game outcome — which reel symbols land, what multiplier applies, whether a bonus triggers. Every parameter of this calculation is configured per the game's certified math documentation. The result is deterministic given the seed, making it independently verifiable.

RNG type
CSPRNG (hardware-seeded)
Math engine
Per-game certified model
RTP configured
Per jurisdiction rules
Audit hash
SHA-256 round hash
STEP 5
Win Calculation & Wallet Credit
15–22ms

If the game outcome produces a win, the win amount is calculated by the math engine and the Wallet Service credits the player's balance atomically in the same database transaction that records the round result. Both the debit (bet) and credit (win) are committed together — meaning it is impossible for a win to be credited without the corresponding bet being recorded, or vice versa.

Credit method
Same-tx as bet debit
Jackpot trigger
Async jackpot service
Bonus activation
Bonus engine hook
Net GGR capture
Real-time BI stream
STEP 6
Compliance Logging & Event Streaming
22–30ms (async)

The complete round record — player ID, session ID, bet amount, RNG seed hash, game outcome, win amount, timestamp, server IP, game version — is written to the immutable compliance database. Simultaneously, Kafka publishes the game event to downstream consumers: the fraud detection pipeline, real-time analytics, the BI dashboard, and the AML transaction monitoring system. These processes happen asynchronously and never block the player response.

Log retention
5+ years (UKGC/MGA)
Storage
Write-only append log
Fraud check
Async ML scoring
AML threshold
Per-regulator rules
STEP 7
Result Delivered to Player
30–48ms total

The game result payload is sent back to the client over the same WebSocket connection. The client receives the outcome data (which symbols landed, win amount, new balance, any bonus triggers) and renders the game animation — the reel spin, the win celebration, the jackpot sequence. From the player's perspective, the game simply responded instantly. The full round-trip is complete in under 50 milliseconds.

Response payload
Game state + new balance
Animation trigger
Client-side only
CDN edge
Served from nearest PoP
P99 latency target
<80ms globally
Section 04 — RNG & Certification

How Game Fairness Is Proven, Certified, and Enforced

The Random Number Generator is the most scrutinised component of any RGS. It is the mathematical proof that a game is fair — that outcomes cannot be predicted, manipulated, or biased. Every regulated jurisdiction requires an RGS's RNG to be independently tested and certified before a single game round can go live.

A Cryptographically Secure Pseudo-Random Number Generator (CSPRNG) is the standard for iGaming. It uses a combination of hardware entropy sources (thermal noise, hardware timing jitter) and cryptographic algorithms (typically AES-256 in counter mode, or ChaCha20) to produce statistically indistinguishable-from-random output that cannot be predicted even if previous outputs are known.

Each game's math model — its RTP (Return to Player), volatility index, hit frequency, maximum win potential, and bonus trigger probability — is documented in a certified math document. The RNG output feeds directly into this model. Regulators verify that the math model, as implemented in the RGS, matches the certified documentation exactly.

Hardware RNG
HRNG — True Random

Physical entropy sources (quantum noise, radioactive decay, atmospheric noise) generate seeds via hardware security modules (HSMs). Highest entropy quality. Used in land-based gambling machines and high-stakes online environments. More expensive but provides the strongest fairness guarantees.

Software CSPRNG
Pseudo-Random — Industry Standard

Cryptographically secure algorithms (AES-CTR, ChaCha20, Fortuna) produce sequences statistically indistinguishable from true random. Industry standard for online RGS. Seeded with hardware entropy at initialisation and re-seeded periodically. GLI and BMM certified implementations pass all statistical test suites.

Blockchain / VRF
Provably Fair — Emerging Standard

Verifiable Random Functions (VRFs) or public blockchain hash chains allow any player to independently verify that any specific game round outcome was not manipulated. Required for crypto casino operations and increasingly demanded by players for crash games, dice, and plinko formats.

The Four Major Certification Bodies

GLI
Gaming Laboratories International

The world's most widely recognised gaming testing laboratory. GLI certification is accepted in 475+ jurisdictions globally. Their RNG testing includes 41 statistical tests and a full source code review. Required for UKGC, MGA, AGCO, and most major markets.

475+ Jurisdictions
BMM Testlabs
BMM International

Specialised in complex gaming system testing including math model validation, RTP verification, and regulatory compliance testing. Strong presence in Australian, Asian, and European markets. Recognised by 300+ regulatory authorities.

300+ Authorities
eCOGRA
eCommerce & Online Gaming RA

Focuses specifically on online gaming and player protection. Issues the "Safe and Fair" seal recognised by players as a trust indicator. Conducts ongoing monthly testing rather than one-time certification — providing continuous compliance assurance.

Ongoing Monthly Testing
iTech Labs
iTech Laboratories

Australia-based, strong in APAC regulatory markets. Recognised by over 140 jurisdictions. Particularly prominent for online poker RNG testing, and certification for the Australian and New Zealand markets. Full statistical and source code testing.

140+ Jurisdictions

What RNG Testing Actually Involves

41+ statistical randomness tests (Chi-square, Kolmogorov-Smirnov, autocorrelation, spectral)
Full source code review of the RNG implementation and seeding mechanism
Math model verification — simulating 10 million+ game rounds to validate RTP within tolerance
Game function testing — verifying all bonus triggers, win calculations, and feature mechanics
Any RGS update that touches game logic requires re-testing a representative sample before deployment
Section 05 — Compliance Frameworks

Every Major Jurisdiction — What Your RGS Must Do

Compliance is not a checkbox. Each regulated jurisdiction has specific, technically-detailed requirements that must be built into your RGS architecture from day one — not retrofitted later.

🇬🇧
UKGC
UK Gambling Commission

The strictest regulated market globally. All RGS game logs must be retained for a minimum of 5 years and must be accessible within 24 hours of a regulatory request. RTP must be displayed to players before each game session. Self-exclusion via GamStop must integrate at the RGS wallet level — meaning excluded players cannot place any bet regardless of what game they attempt to access. Responsible gambling affordability checks must be triggered based on deposit velocity rules configurable in the RGS.

5-year log retentionGamStop integrationRTP displayAffordability checks24hr audit accessGLI/BMM certification
🇲🇹
MGA
Malta Gaming Authority

The most internationally recognised B2B licence. MGA requires the RGS to implement player verification at account level before any real-money game round can be processed. All financial transactions must be reported to MGA's system in real time. The RGS must provide a configurable responsible gambling layer including deposit limits, reality checks (session duration alerts), and cooling-off periods. Game fairness must be independently certified by an MGA-approved testing lab before any game can be offered.

Real-time transaction reportingKYC before first betReality checksCooling-off periodsMGA-approved lab cert
🇨🇦
AGCO
Ontario iGaming — Canada

Ontario's regulated market (launched 2022) has specific RGS requirements around data residency — player data must be stored on Canadian or US soil. The RGS must integrate with Ontario's self-exclusion registry (GameSense). Bonus mechanics must be fully transparent and clearly communicated via RGS-level metadata. All marketing communications must be suppressed at the RGS level for registered problem gamblers. High-velocity depositing triggers mandatory RGS-side intervention flows.

Canadian data residencyGameSense integrationBonus transparency metadataMarketing suppression
🇸🇪
Spelinspektionen
Sweden

Sweden mandates weekly deposit limits configurable in the RGS (maximum 5,000 SEK/week by default, adjustable upward by player choice). Session time must be tracked and displayed. The RGS must enforce mandatory 24-hour breaks after extended play sessions. Bonus offers are tightly restricted — welcome bonuses are prohibited for casino games; the RGS must flag and prevent non-compliant promotional mechanics from executing.

Weekly deposit limitsSession time displayMandatory play breaksBonus restrictions engine
🇪🇸
DGOJ
Spain

Spain requires that all game content served to Spanish players must be approved by DGOJ before activation. The RGS must maintain a live register of all approved games and block unapproved titles at the content distribution layer. AML reporting is mandatory for single transactions over EUR 2,000 and cumulative daily activity over EUR 10,000. Player identification must be verified before any game is loaded, not just before deposit.

Pre-approved game registerEUR 2K AML reportingPre-game ID verificationContent geo-blocking
🇨🇼
Curacao eGaming
Offshore Market

Curacao eGaming is the most accessible licence for operators entering the market, commonly used for LATAM, APAC, and emerging market operations. The RGS requirements focus on basic fairness certification (GLI or equivalent), standard AML/KYC flows, and player protection minimums. No data residency requirements. Curacao is undergoing regulatory reform (2024–2025) with stricter technical requirements expected to mirror MGA standards progressively.

Basic RNG certificationStandard KYCAML basicsPlayer protection tools
Section 06 — Scaling & Performance

How an Enterprise RGS Handles 50x Traffic in Seconds

During the FIFA World Cup final, IPL Super Sunday, or a UFC title fight, player traffic can spike 50x normal volume in under 60 seconds. An enterprise RGS must absorb this without any degradation.

<50ms
Game Response Target (P50)
The median game round response time for a well-optimised RGS. Achieved through edge-deployed API gateways, Redis session caching, and pre-warmed game logic instances. Players never perceive latency below 100ms — anything under 50ms feels instantaneous.
99.97%
Achievable Uptime SLA
Translates to less than 2.5 hours of downtime per year. Achieved via active-active multi-region deployment where two regions serve live traffic simultaneously. If one region degrades, the other absorbs 100% of load with no failover delay.
50x
Traffic Spike Capacity
Kubernetes HPA (Horizontal Pod Autoscaler) can spin up new game service instances in 45–90 seconds based on CPU and connection count metrics. Pre-scaling before known events (by scheduling more pods during predicted peak windows) eliminates the 90-second cold start entirely.

Scaling Architecture — How Each Layer Handles a 50x Spike

Sequence of actions from the moment unusual traffic is detected to full capacity absorption

1
CDN Edge Layer — Absorbs Static Load Instantly
Static game assets (graphics, audio, animations — typically 60–80% of all HTTP requests) are served directly from CDN edge nodes in 150+ global PoPs. No origin server contact required. A 50x traffic spike on static assets has zero impact on the RGS backend. Cloudflare's DDoS protection simultaneously validates that the traffic spike is legitimate player traffic and not an attack.
CloudFront CDN150+ PoPsDDoS validation
2
Redis Cache Layer — Prevents Database Collapse
Every active player session is in Redis memory. During a 50x spike, 98% of all session lookups are served from Redis without touching PostgreSQL. Redis Cluster auto-shards across additional nodes as memory pressure increases, maintaining sub-1ms response times. Without Redis, a 50x database query spike would collapse any SQL database within minutes.
Redis ClusterAuto-sharding98% cache hit rate
3
Kubernetes HPA — Auto-scales Game Services in 90 Seconds
Kubernetes Horizontal Pod Autoscaler monitors CPU utilisation and WebSocket connection count per game service pod. When either metric crosses the threshold (typically 70% CPU), new pods are provisioned from pre-built container images. For known peak events (IPL, World Cup), pods are manually pre-scaled 30 minutes ahead to eliminate the 90-second provisioning window entirely.
Kubernetes HPAPre-scaling90s cold start
4
Kafka Queue — Decouples Spiky Write Load
During a spike, compliance logging and analytics writes are the most vulnerable to backlog. Kafka queues all downstream events, allowing the core transaction to complete immediately while compliance logs are written at the database's natural throughput rate. The queue can absorb billions of events before causing any backpressure on the game logic layer.
Apache KafkaEvent queueZero backpressure
5
Database Read Replicas — Scale Read Queries Horizontally
During spikes, read queries (player balance lookups, game configuration reads, bonus eligibility checks) are routed to read replicas. MongoDB replica sets and PostgreSQL streaming replication create read-optimised copies of the database that scale horizontally. The primary database handles only write operations, keeping write latency stable regardless of read load.
MongoDB replica setsPostgreSQL streamingRead/write split
Section 07 — Own vs. License

The Real Business Case for Building Your Own RGS

Every operator faces this decision. The wrong choice costs millions. Here is the complete analysis.

Recommended for Serious Operators

Build a Custom RGS with Capermint

100% IP ownership. The codebase is yours. Sell it, licence it, migrate it to any hosting, or hand it to any team at any time. It is a real balance-sheet asset.
Zero ongoing royalties. From Year 2 onward you keep 100% of GGR. A mid-size operator at EUR 1M/month GGR saves EUR 960K/year vs an 8% royalty model.
Full architectural control. Custom game verticals, bespoke math models, proprietary bonus mechanics, unique player engagement features — none of which a generic licensed RGS will ever offer.
No vendor dependency risk. Your vendor's pricing change, acquisition, or shutdown cannot affect your platform. Full operational independence.
Higher company valuation. Operators with proprietary certified RGS infrastructure are consistently valued 3–5x higher in M&A transactions than those running on third-party licensed platforms.
Revenue-share option available. Zero upfront development cost via Capermint's revenue-share model. We invest the engineering; you invest the market access.
Significant Hidden Costs

License a Third-Party RGS

No IP ownership. The vendor owns every line of code. You are permanently dependent on their pricing decisions, survival as a business, and technical roadmap choices.
Perpetual royalty drain. Typical licensed RGS arrangements extract 5–12% of GGR in perpetuity. There is no year where your margins improve just from growth — the vendor's take scales with your revenue.
Generic feature set. You get what the vendor builds for their entire client base. Custom game mechanics, unique player journey features, and competitive differentiation are either impossible or require expensive custom development on top of their platform.
Compliance limits. Most licensed RGS vendors cover 1–5 jurisdictions. Expanding to new markets requires either waiting for the vendor to certify (12–18 months) or paying separate expensive add-on licences.
Faster initial time-to-market. The only genuine advantage — a licensed RGS can go live in 4–8 weeks. But a Capermint white-label is also live in 6–8 weeks, with IP ownership. The time advantage of licensing disappears at week 6.
Lower exit valuation. In any acquisition or fundraising scenario, a business built on a licensed RGS is valued as a revenue operation — not a technology business. The platform discount can reduce valuation multiples by 40–60%.
Decision FactorLicensed RGSCustom RGS (Capermint)Build Entirely In-House
Time to First Live Game4–8 weeks6–8 weeks (white-label)12–18 months
Year 1 Total Cost (1M EUR/mo GGR)EUR 960K+ (royalties)EUR 75–150K (one-time)EUR 400K–1.2M
Year 5 Total CostEUR 4.8M+ (royalties only)EUR 150K + 200K maintenanceEUR 1.5M+ (team + infra)
IP OwnershipNone100% from day 1100%
Custom Game MechanicsNoFull customFull custom
Compliance Jurisdictions1–512+ at launchExpensive, slow
M&A / Fundraising ValuationRevenue multiple onlyTech + revenue multipleTech + revenue multiple
Vendor Lock-in RiskHighNoneNone
Section 08 — 2025–2027 Trends

The Forces Reshaping RGS Architecture in the Next Three Years

FAQ

Technical Questions, Answered

What is the difference between an RGS, a casino platform, and a game aggregator?
Casino platform: The front-end player experience — lobby, registration, cashier, CRM, promotions. It does not run games. RGS: The backend system that actually runs the games — the RNG, game logic, transactions, compliance logging. The casino platform calls the RGS API to launch and play games. Game aggregator: A special type of RGS that connects to multiple other RGS providers (studios) and exposes all their games to operators via a single API. Capermint builds all three, or any combination.
How long does RNG certification actually take, and what does Capermint do to prepare?
A full RNG certification with GLI typically takes 6–12 weeks from test lab submission to certificate issuance. The most common cause of delays is incomplete or non-compliant documentation submitted with the RGS. Capermint prepares:
  • Complete math model documentation for every game to be certified
  • Full source code of the RNG implementation with entropy source documentation
  • System architecture diagrams showing RNG integration points
  • Pre-testing using the same statistical test suites labs use (NIST SP 800-22)
  • Game function test plans covering all bonus mechanics and edge cases
This preparation typically reduces lab turnaround time to 4–6 weeks and eliminates the most common re-test cycles.
What happens if the RGS goes down during a live game round?
A well-designed RGS has specific handling for mid-round interruption:
  • Session state is persisted in Redis before the bet is confirmed, so the bet amount is protected
  • Idempotency keys prevent the same round from being processed twice if the client retries
  • Game resume: when the player reconnects, the client queries the RGS for the pending round state and either completes the round or voids and refunds the bet
  • Regulator requirement: UKGC and MGA both require a documented interruption recovery procedure to be included in the RGS certification
Can one RGS serve both B2C (players) and B2B (game distribution to other operators)?
Yes, and this is one of the most powerful business models in iGaming. A game studio can build an RGS that serves their own branded casino (B2C) and simultaneously distributes their certified game content to third-party operators via an aggregation layer (B2B). The B2B revenue stream (typically a per-round royalty from operators) can exceed the direct B2C GGR for studios with popular titles. Capermint builds RGS platforms specifically designed for this dual-revenue model.
How does the RGS handle cryptocurrency wallets and settlements?
Crypto wallet integration in the RGS operates at the wallet abstraction layer. The RGS maintains an internal credit ledger in a fiat reference currency (typically EUR or USD). Crypto deposits are converted to this internal credit at the time of deposit using a real-time oracle price feed. All game rounds operate against the internal credit balance (giving speed and determinism). Crypto withdrawals convert credits back to crypto at the time of the withdrawal request. This architecture allows the core game logic to remain unchanged while supporting any number of crypto assets at the wallet layer.
Ready to Build?

Now You Know Exactly What an RGS Is — Let Us Build Yours

Capermint engineers enterprise-grade RGS platforms for regulated iGaming operators. Custom-built, fully certified, 100% IP ownership, deployed in weeks.

LET’S TALK

We understand that entrusting your ideas to a development partner requires trust. At Capermint, we take information security very seriously. Here’s what you can expect when you contact us:

check-square

100% Secure Communication.

check-square

No Spam, Ever.

check-square

NDA available

mail-im

Master email: [email protected]

GET YOUR PROJECT ESTIMATE

Tell Us About Your Project. We Reply In 48 Hours With A Custom Quote.

NDA-first. No sales pitch. Just a clear scope, team recommendation, engagement model, and itemized timeline so you can evaluate Capermint against any other vendor on equal terms.

FREE LEAD MAGNET

Project Readiness Assessment

Submit your brief and receive a free Project Readiness Assessment: scope breakdown, recommended team shape, estimated timeline, technology fit, budget range, risk surface, and launch checklist. Delivered within 48 hours, no obligation.

  • Custom itemized quote within 48 hours
  • NDA signed before any briefing call
  • You choose the engagement model and team structure
  • Free Project Readiness Assessment included
  • No obligation and complete confidentiality

Project Brief

Fields marked optional are not required to submit.
Submission goes via our secure contact system. NDA-first, no obligation. Your information stays confidential.