What the platform is
Every online casino and sportsbook is a website or an app in front of a platform, and the platform is where the business actually happens. The front end shows games and markets; the platform holds the accounts, moves the money, records every bet, enforces the rules, connects to the games and the odds, talks to the payment providers and the identity vendors, runs the promotions, and produces the reports the finance team and the regulator read. An operator that owns its front end and rents its platform owns very little; an operator that understands its platform can decide what to own.
This lesson maps the platform's components, what each does, and where the boundaries between them fall, because those boundaries are where suppliers compete, where integrations fail and where regulators look.
The player account management system
At the centre sits the player account management system (PAM), the term the industry uses for the platform core: GAN, a platform supplier headquartered in Las Vegas, described in its annual report for 2024 the player account management system as the core of its platform and the focal point of regulatory licensure. It owns the customer record: registration, identity and verification status, contact and consent preferences, responsible-gambling settings, self-exclusion status, risk flags, segment and value classifications. It owns the session: login, authentication, geolocation checks, device recognition. And it owns the wallet, which is the platform's most important single function.
The wallet is a ledger. Every deposit, withdrawal, bet, win, bonus award, bonus conversion, adjustment and fee is a transaction against a balance, or against several balances (real money, bonus money, withdrawable and non-withdrawable amounts, per-currency balances), and the ledger must be exact, complete, auditable and reconcilable to the payment providers on one side and the game and sportsbook systems on the other. Regulators have the systems that hold the wallet tested and certified, audit them and require reports from them: the GLI-19 laboratory standard for interactive gaming systems, for example, requires the system to report the total the operator holds for player accounts, log every manual balance adjustment as a significant event and allow only authorised, auditable adjustments. A wallet discrepancy is among the most serious technical failures an operator can have.
Game aggregation and the seamless wallet
Casino games run on the studio's own servers (the remote game server, or RGS), not on the operator's platform. The platform integrates to each studio, directly or through an aggregator that fronts many studios with one API (GAN's annual report describes a "super" remote gaming server, otherwise known as a remote gaming server aggregator), and the integration works one of two ways. Under a transfer wallet, the operator moves a balance into the game session and back at the end; under a seamless wallet, the game calls the operator's wallet for every bet and win in real time, so that the customer sees one balance across every game. Seamless integration keeps the ledger in one place, which is its main advantage in a regulated market, although the transfer model is still permitted: GLI-19 sets rules for moving funds from the account balance to a session credit meter and returning them automatically when the session ends. Seamless also means the platform's wallet API must answer every bet and win call in real time and at low latency, at peak volumes, and that a slow wallet makes every game feel slow.
The aggregator layer manages the catalogue: which games are available in which markets (certification differs by jurisdiction), in which currencies and languages, with which RTP versions, under which regulatory flags (bonus-buy disabled here, stake limits there, such as Britain's maximum online slots stake of £5 per game cycle, or £2 for adults aged 18 to 24, in force since 9 April and 21 May 2025 respectively). Lobby management, the merchandising of the catalogue to the customer, sits either in the platform or in the front end depending on the architecture.
The sportsbook
A sportsbook is a separate system with its own architecture: a feed of events and prices from data suppliers and the operator's trading function, a market-management layer, a bet-acceptance engine that checks limits and liabilities, a bet slip and cash-out engine, a settlement engine driven by results feeds, and a risk-management console; GAN's filing summarises the sportsbook engine's job as pricing, trade execution and risk management. It integrates to the PAM's wallet like a game does, seamlessly, and it is supplied either as a module of the platform, as a separate product from a sportsbook provider, or as a managed trading service that includes the pricing, such as Sportradar's, which it describes as a trading, risk and liability management solution embedding its odds services. Sportsbook latency requirements are the platform's hardest: in-play prices change in seconds, and a bet accepted at a stale price can cost the operator money.
Payments and the cashier
The cashier is the customer-facing deposit and withdrawal flow; behind it sits the payments orchestration layer, which connects to acquirers, payment service providers, bank-transfer and open-banking rails, e-wallets, vouchers and local methods, routes each transaction to the best provider for the customer's market, method and risk profile, cascades to a second provider on failure, and applies closed-loop and limit rules. Closed loop means paying withdrawals back to the method used to deposit; Britain's Gambling Commission calls it best practice, strongly recommends it and requires operators that run open-loop payments to treat them as a money-laundering risk. Payments orchestration is a specialist function often supplied separately from the PAM, and it is where market coverage is won: an operator entering a new market needs the local methods, and the orchestration layer's connections decide how fast it can offer them.
Identity, risk and compliance modules
Around the core sit the modules that make the platform lawful in a regulated market. Identity verification integrates document and database checks from specialist vendors, applying each market's rules on when verification is required. Age verification and sanctions and politically-exposed-person screening run at registration. Self-exclusion checks against national registers (GamStop in Britain, Cruks in the Netherlands, OASIS in Germany, Spelpaus in Sweden and the rest) run at registration and again when the customer returns: British remote licensees must participate in the national multi-operator self-exclusion scheme, Swedish licensees must check Spelpaus before allowing play, Dutch operators store a Cruks code with the customer account and use it to check the register when the player returns, and in Germany the OASIS check is made at registration and at every login. Anti-money-laundering monitoring scores transactions and behaviour against rules and models and raises alerts for the compliance team. Responsible-gambling modules enforce deposit, loss, stake and session limits, reality checks and cooling-off, apply market-specific mandatory limits, such as Germany's cross-operator deposit limit of, in principle, no more than €1,000 a month, and score accounts for markers of harm. Geolocation, in markets that require it, confirms the customer's position through a specialist service; GLI-19, for instance, requires a location check before the first game after login and again after an IP address change or thirty minutes, unless the regulator specifies otherwise. Each module has a vendor market of its own, and each is a certification item.
The bonus engine and CRM
The bonus engine configures, awards and tracks promotions (the Casino Bonuses guide and the glossary's bonus-engine entry cover what it does), and it needs the wallet, the game transaction stream and the customer record to work. Customer relationship management systems, which segment customers and run campaigns across email, push, SMS and on-site messaging, are usually separate products fed by the platform's data, with triggers flowing back into the bonus engine. The boundary between platform and CRM is a design decision: tightly integrated platforms include both; modular architectures connect a best-of-breed CRM through the platform's events.
Reporting, data and the back office
Every regulated market requires reports: revenue and tax by product and period, customer numbers and activity, responsible-gambling measures, anti-money-laundering statistics, and in several markets a near-real-time data store or feed the regulator can access: the Netherlands requires operators to record near-real-time gaming data in a separate control database open to the Kansspelautoriteit, and German licensees must connect to the regulator's LUGAS supervisory system. The platform's reporting layer produces them, and its data warehouse feeds the operator's analytics, finance reconciliation and CRM. The back office is the set of tools the operator's staff use for everything above: customer service views, manual adjustments (with authorisation procedures that make every change auditable, which regulators inspect), bonus configuration, content management, risk review queues, and audit logs of every staff action.
The front end
The website and apps are the customer's experience of all of the above, and in most architectures they are the operator's own: built on the platform's APIs, branded and localised, with the lobby, the bet slip, the cashier and the account pages assembled from platform services. Native mobile apps, progressive web apps and responsive web are the delivery options, each with app-store, regulatory and performance considerations of its own; Apple, for example, requires real-money gambling apps to hold licences where they are used, be geo-restricted to those locations and be free to download.
What to take from this lesson
A platform is the PAM (accounts, sessions and the wallet ledger) plus game aggregation through seamless wallet integrations to studios' remote game servers, a sportsbook with its own feed, acceptance, settlement and risk engines, payments orchestration behind the cashier, identity, screening, anti-money-laundering, responsible-gambling and geolocation modules, a bonus engine and CRM connections, reporting and a back office, and the operator's front end on top. The boundaries between these components are where suppliers compete, integrations fail and regulators look, and the wallet is the component that everything depends on.