A game studio announces a new slot on a Tuesday morning. By that afternoon the same title was live on hundreds of casino sites in a dozen countries, sites with no corporate connection to each other, and most of them never touched the game’s code. The simultaneity looks like a coordination miracle. It’s a piece of infrastructure that rarely gets written about, and it has quietly grown into a substantial API business in its own right. The starting fact is that a casino website hosts surprisingly little of what it sells. The games run on servers belonging to the studios that made them, and everything else follows from that.
The game lives on the studio’s servers
The core of the model is called a remote game server, or RGS. When a player opens a slot on a licensed casino site, the site serves a wrapper: the page, the balance display, the cashier. The game logic and the math model that decides what a spin pays execute on the studio’s own hardware, and the result travels back over an API. The browser gets a client, usually HTML5, talking to a game engine that might physically sit in another country.
This is why the same game behaves identically everywhere. There’s only one copy of it, in any meaningful sense. The studio patches it once, and every operator carrying it is patched. It also lets a studio prove to a regulator that the certified build is the build players get, since no operator-side copy exists to drift out of sync.
Aggregators turn scale into a subscription
The second layer exists because of scale. Aggregators are middleware companies that integrate hundreds of studios once, on their own platform, then offer operators the whole bundle through a single API. An operator signs one contract, completes one integration project, and gains a catalog of several thousand games from studios it has never spoken to. When a new studio joins the aggregator, its games simply appear in the feed, the way a new channel appears in a TV package. That Tuesday-afternoon ubiquity of a new slot is one game server pushed through one aggregator, with hundreds of lobbies updating together.
The trade-off is sameness. Every operator on the same aggregator got the same push, so a catalog assembled this way is broad and current but rarely unique. Yeti carries games from about 75 different studios on one UK-licensed site. As direct work, that would mean 75 sets of API credentials and 75 release calendars for a mid-size operator to track an engineering budget out of all proportion to the business. Routed through aggregation, the same catalog is a contract and a feed, and 75 becomes an ordinary number rather than an impressive one.
The money is the custom part
The engineering that does happen per-operator is money movement. The game runs on the studio’s server, but the player’s balance never leaves the operator, and the bridge between those two facts is what the industry calls a seamless wallet API. Each spin fires a debit request from the game server to the operator’s wallet; each win fires a credit. The player sees one balance updating in real time while the ledger entries land on the operator’s side, where the license lives.
Dropped connections are the hard case. A connection that dies mid-spin can’t be allowed to eat a stake or pay a win twice, so these APIs are built around numbered transactions that either complete or get explicitly reversed when the game server reconciles. It’s unglamorous work, closer to payments engineering than to game development, and it faces the same hostile traffic as any financial API on the public internet. The precautions read like any security testing checklist for software that moves money: authenticate every call and assume part of the traffic is malicious.
Certification rides along with the game
The regulatory layer varies by geography, and Britain makes a convenient example because its regulator publishes the rulebook. Remote games offered there have to comply with the Gambling Commission’s remote gambling and software technical standards, which cover everything from RNG behavior to how results are displayed, with security requirements built on ISO 27001. Approved test labs certify games against those standards, and the certification attaches to a specific build for a specific jurisdiction.
The integration layer has to respect that. A UK lobby can only expose builds certified for the UK, so the aggregator’s feed is filtered by jurisdiction before it reaches the operator’s site. The same slot may exist in several certified variants, with different return-to-player configurations approved in different markets, so the “same” game can pay differently depending on where it’s licensed.
Why five thousand games overlap with three thousand
Put the layers together and a modern casino site starts to look like a very specific kind of company: a licensed wrapper around rented infrastructure. Games arrive from studios via an aggregator, live tables come from specialist broadcasters, and the platform underneath is often supplied by a third party too. The operator’s own contribution is narrower than the storefront suggests: the license, the payment handling, the verification work, and the customer operation.
For anyone comparing sites, that changes what the numbers mean. The 75-studio catalog above is not a moat: another operator on the same feed can carry games from the same 75 studios tomorrow. A lobby of five thousand games and a lobby of three thousand mostly overlap for the same reason, and the overlap grows every time another studio joins a feed both operators subscribe to.
