Player Account Management System (PAM): What It Does and How to Choose One

Replacing a PAM or adding one to an existing stack? We build PAM, wallet and back-office modules for licensed operators and B2B platform suppliers, inside our casino platform software builds or for the stack you already run. Turnkey platform builds sit in a published $35K–$120K band with a 6–10 week launch for the software; lab certification and approvals run on their own timelines. Request a project scope.

Written by Team Capermint

What is PAM in iGaming?

PAM stands for player account management. In iGaming it is the software that owns the player record: who the player is, whether they are verified, what they hold in cash and bonus funds, which limits or exclusions apply, and every transaction behind those balances. GLI-19, the lab standard for interactive gaming systems, gives it its own section.

Player account management (PAM) system: The core iGaming software that registers and verifies players, keeps each player’s wallet and transaction ledger, applies bonus rules and responsible-gambling limits, and exposes that data to games, payments, CRM and regulators through APIs and reports.

A PAM does not run games, price bets or send marketing. Each of those systems asks the PAM two questions: is this player allowed to play, and is there enough money? Because everything is wired to its player IDs, session tokens and wallet API, the PAM is usually the hardest component to replace.

What does a PAM system include?

A production PAM has eight modules: registration and profile, identity and KYC status, authentication and sessions, the wallet and ledger, the cashier, bonuses and loyalty, responsible-gambling controls, and reporting and audit. Some vendors bundle CRM, affiliate tracking or a content system, but those sit outside the player record.

1. Registration and profile: personal data, consents, one record per person.
2. Identity, KYC and AML status: verification results, risk flags, exclusion-list checks.
3. Authentication and sessions: login, multi-factor authentication, device checks, geolocation hooks.
4. Wallet and ledger: cash, bonus and loyalty balances per currency, each movement recorded once.
5. Cashier and payments: deposits and withdrawals through payment providers.
6. Bonuses and loyalty: grants, wagering requirements, expiry, points.
7. Responsible-gambling controls: limits, cool-offs, reality checks, self-exclusion.
8. Reporting and audit: statements, regulator reports, audit trails; the staff back office sits on top.

Which PAM modules do you need at launch?

In a licensed market, six capabilities are day-one: registration, identity and age checks, sessions, the wallet and ledger with a cashier, responsible-gambling limits and exclusions, and regulator reports. Loyalty tiers, an advanced bonus engine, affiliate feeds and BI can follow in phase two, as long as the wallet and event stream are designed for them.

What do test labs check in each module?

Labs test behavior, not feature lists. The table maps each module to example requirements from GLI-19 v3.0; Great Britain’s own rules are in the regulators table below. Regulators adopt GLI-19 in whole or in part or set their own rules, so treat this as a starting specification and confirm the version your regulator applies.

Clause numbers are GLI-19 v3.0. GLI’s v4.0 public-comment draft moves player-account rules into their own chapter and adds MFA at account creation, so the numbering will change once it is final.

How does a PAM work with games, payments and the sportsbook?

The PAM issues the player’s session, and every other system calls its wallet API. A slot on a remote gaming server asks the PAM to debit the stake and credit the win; the sportsbook reserves a stake and settles it later; the cashier credits cleared deposits. The PAM records each call once, with a unique transaction ID.

1. Register and verify. The PAM runs identity and exclusion-list checks before activating the account.

2. Deposit. The cashier calls the payment provider; the PAM credits funds once authorized.

3. Launch a game. The lobby passes a PAM session token to the game on the RGS or aggregator.

4. Bet and win. The game calls debit and credit; the PAM checks session, location, limits and balance, and rejects duplicate transaction IDs.

5. Events out. CRM, BI and affiliate tools receive events but never change balances.

Many casino integrations use a seamless wallet, where the game calls the PAM every round; a transfer wallet moves funds into the provider’s wallet for the session instead. Our guide to seamless wallet vs transfer wallet explains the trade-offs. Either way, ask vendors to show idempotent wallet calls, so a retried debit never charges twice, and explicit rollback for failed rounds.

Monolithic, modular or API-first: which PAM architecture fits?

Choose by what you expect to swap later. A monolithic platform bundles PAM, front end and back office, which is fast to launch but hard to change. A modular PAM exposes the wallet, KYC and bonus engine as separate services. An API-first PAM lets your own front end, sportsbook or CRM connect through documented APIs.

As a rule of thumb, monolithic suits one brand in one market, modular suits adding markets or verticals in phases, and API-first suits groups with their own product teams.

What is the difference between a PAM and a CRM?

The PAM owns state; the CRM acts on it. The PAM holds identity, balances, bonus state and limits, and its records settle disputes. The CRM consumes PAM events, segments players and decides which message or offer each one gets. A CRM can request a bonus grant, but the PAM applies it and enforces responsible-gambling blocks.

• Compliance: GLI-19 says marketing must not specifically target excluded players, so suppression flags should come from the PAM in real time.
• Licensing: UK Gambling Commission guidance treats software that records gambling transactions and allocates wins as gambling software, but not CRM or affiliate management, unless the software uses player records to award bonuses inside a gambling session.
• Replaceability: a CRM that only reads events and requests grants can be swapped without touching balances.

Which system owns what?

Most PAM vs CRM disputes, and many integration problems, trace back to unclear ownership. Use this table to agree, in writing, which component holds each record and which one may change a balance. Supplier boundaries vary, so confirm each row against the contract and the API documentation, not the sales deck.

Is the back office part of the PAM?

Most PAM vendors ship one with it, but treat them as two layers. The PAM is the data and rules; the back office is the staff interface on top of it for support, payment approvals, KYC review, bonus setup and reports. A good back office changes balances only through logged PAM actions, never by editing records directly.

Can one PAM run casino, sportsbook and poker on a single wallet?

Yes. A single wallet across casino, sportsbook and poker is a design choice in the PAM: one cash balance that every vertical debits and credits through the same API. Casino rounds settle in seconds, sportsbook stakes stay reserved until results, and poker usually moves a buy-in to the table. The PAM must stop any of them double-spending the balance.

One wallet does not mean one rulebook. In the US, online casino is legal in only a handful of states, such as New Jersey, Pennsylvania and Michigan, while most states license sports betting, so the PAM switches products per state using geolocation. A growing list of states, including California and New York, restrict or ban the dual currency sweepstakes model; read our guide to sweepstakes casino compliance before you scope one. If a sportsbook platform is on the roadmap, design the wallet for open-bet liabilities from day one.

What can one PAM share across brands and markets?

One PAM instance can share the wallet engine, ledger and audit logs, and KYC records where licenses and data rules allow, as long as it separates what is shared from what is set per brand and per market. Each brand keeps its own front end and bonuses; each market keeps its own limits, reports, geolocation, tax and self-exclusion scheme.

How secure does a PAM need to be?

Secure enough to pass the regulator’s system review and a payment-card security assessment. That means encrypted data in transit and at rest, tokenized card data to shrink PCI DSS scope, role-based back-office access with staff MFA, tamper-evident audit logs, regular penetration tests and hosting where each regulator allows player data to sit.

• Evidence: a SOC 2 Type 2 report or ISO/IEC 27001 certificate covering the hosting; Ontario requires a recognized IT control framework and independent security assessments, for suppliers too (AGCO 5.01, 5.11).
• Fraud and AML: multi-account detection plus velocity and bonus-abuse rules that feed each market’s AML duties, such as PCMLTFA and FINTRAC reporting in Ontario (AGCO 6.02, 6.03).
• Staff access: least-privilege roles, MFA on every back-office login, a second approver for manual balance adjustments.
• Data protection: GDPR or equivalent controls, with retention set per market; penetration tests before go-live and after major changes.

Should you buy, rent or build a PAM?

Rent a white-label platform when speed and low upfront cost matter most and your market allows it; license a turnkey PAM when you hold your own license and want a core already certified in your market; build when you need several markets or verticals, or full control of the wallet API and data.

Our white label vs turnkey casino comparison covers the business models in full; this table covers what each route means for the PAM.

Bands cover a full platform build (PAM, wallet, back office, player front end, core integrations); a PAM or wallet module alone is quoted after scoping, and license, lab, payment, KYC and game-content fees are separate. Compare our turnkey casino software, white label casino software and custom igaming platform development.

Capermint is a development studio, not an operator, and holds no supplier license or registration. In Great Britain, licensed US states, Ontario and Alberta we take on work only where our role needs no license or registration of its own, and hand the build to the licensed or registered party; in Great Britain, that means custom work under the design control of a client that holds a gambling software license.

What moves the price: the number of markets, the verticals sharing the wallet, integrations, regulator reports, migration volume and certification scope. Costs after launch: hosting, maintenance, lab re-testing after material changes, per-check KYC and geolocation fees, payment fees, and supplier license or registration fees where required. For full platform budgets, see online casino development cost or the game development cost calculator.

How long does it take to implement a PAM?

At Capermint, a white-label or turnkey platform with its PAM has a typical 6–10 week launch for the software build; custom single- and multi-vertical builds are phased, with dates set in scoping. Go-live also waits for licensing or registration, supplier approvals and lab testing, which run on their own timelines, so start them in parallel with the build.

How would an operator adding a sportsbook later decide?

Picture an AGCO-registered Ontario operator launching casino first and adding a sportsbook in a second phase. Route A takes a turnkey core ($35K–$120K, a 6–10 week launch, with lab certification on its own timeline). Route B builds a custom single-vertical PAM ($60K–$180K) designed for a single wallet, then extends it. Route C builds multi-vertical from day one ($200K–$500K+).

Choose A if the sportsbook is uncertain and speed decides the business case, once you confirm the sportsbook can share the wallet; B if casino already earns and you want to own player data and the wallet API; C only if both verticals launch together or you run several brands.

In every route the operator registers with the AGCO and contracts with iGaming Ontario, suppliers that develop or run the gaming system register too, and the registered party holds the lab certificates. If the AGCO decides our development role needs registration, the work cannot go ahead with us while we are unregistered (see AGCO supplier registration). Alberta works the same way with AGLC and the Alberta iGaming Corporation.

How do you migrate players and balances to a new PAM?

Treat a PAM migration as a regulated financial cutover. Secure export rights in the contract, map every record, rehearse until balances reconcile to the cent, get the approvals your regulator requires, then freeze, move and verify. Self-exclusions, limits and open bets matter as much as balances, because a missed exclusion is a compliance breach.

1. Lock in export rights. Set export format, frequency, cost and deadline before you sign. Where the vendor processes player data for you, GDPR Article 28(3)(g) already requires EU and UK processor contracts to cover returning or deleting personal data when the service ends.

2. Map the data. Players, KYC status and documents, limits and exclusions, balances, pending withdrawals, open bets, loyalty points, history.

3. Plan approvals. A new PAM changes the gaming system; under GLI-19, the regulator’s change-management policy decides what the lab evaluates.

4. Rehearse and reconcile. Dry-run into staging until totals per currency and balance type match the legacy ledger.

5. Freeze and cut over. Pause deposits and bets, carry over open bets and withdrawals, load the final export, reconcile again.

6. Re-authenticate players. Password hashes and MFA secrets often cannot move, so plan a secure reset flow.

7. Keep the old records. Keep read-only access or an archive for audits, complaints and retention rules.

What must move, and how do you check it?

Balances are only part of a cutover. Regulators and players also judge it on exclusions, limits, open bets and statements. Make each row below a written go-live gate with an owner and a pass condition, and keep deposits closed until every gate passes.

What are the signs your PAM has become a bottleneck?

Five signs show up first: every new market or product needs vendor work, you cannot get raw data out, the revenue share now costs more than owning the code would, the wallet slows or fails at peak load, and the vendor roadmap blocks the verticals you plan. If two or more apply, scope the move before your next market launch.

Moving off a white-label or legacy PAM? Send us your current platform and markets and we will scope the data map, rehearsal and cutover.

What should you ask a PAM vendor before you sign?

Ask for evidence, not feature lists. The twelve questions below cover API access, data export, certification, licensing, markets, wallet scope, provider choice, responsible gambling, reporting, hosting and performance, pricing, and ownership. Vendors often share API documentation only under NDA or contract, so request it before signing rather than after.

1. API access: Will you share wallet, player and bonus API documentation and a sandbox before we sign?
2. Data export: Can we export every record in a documented format, how often, at what cost, and with what migration tooling?
3. Certification: Where has this exact PAM version been tested or approved, and can we see the certificates?
4. Licensing: Which supplier licenses or registrations do you hold in our markets, does your role need one there, and who submits the system to the lab?
5. Markets: Can one instance run markets with different limits, reports and products, and what does each extra market cost?
6. Single wallet: Which verticals share one balance, and can our own systems debit and credit it?
7. Provider choice: Can we plug in our own KYC, payment and geolocation providers, and which self-exclusion schemes are connected?
8. Responsible gambling: Are limits, cool-offs and exclusions enforced server-side for every product?
9. Reporting: Which regulator reports ship ready for our markets, and can we query raw data directly?
10. Hosting and performance: Where do player data and backups sit, and what throughput, latency, availability and recovery (RPO, RTO) targets do you commit to?
11. Pricing: What are the setup fees, per-market fees, monthly minimums and any revenue-share base (GGR or NGR)?
12. Ownership and service: Who owns customizations, is source-code escrow available, and what support hours does the SLA set?

Score it: rate each answer 0 (missing), 1 (claimed) or 2 (shown with documents or a demo). Treat a 0 on API access, data export, certification or licensing as a stop until the vendor fixes it in writing.

How does Capermint answer these questions?

Four of our answers are fixed by how we work: source code, certification, licensing and engagement. The other eight depend on your markets, verticals and stack, so we answer them in the proposal after scoping, including anything we do not hold or do not offer.

What do regulators expect from a PAM?

Operators hold the licenses, and in many markets anyone who supplies gaming software must be licensed or registered too. Regulators and their test labs then check what the PAM does: age and identity checks before play, accurate balances and statements, limits and self-exclusion that cannot be bypassed, and audit trails for every manual change.

Supplier licensing turns on the market and on who controls the product: Great Britain licenses whoever controls design and content (UKGC guidance), while New Jersey, Ontario and Alberta license or register gaming-system suppliers directly (NJ DGE vendor licensing, AGCO supplier guide). Confirm each party’s status with counsel before work starts.

Frequently asked questions about PAM systems

How we wrote this guide: we compared player account rules in GLI-19 v3.0 and its v4.0 draft, UK Gambling Commission standards, AGCO and Alberta rules and New Jersey regulations, and reviewed the top-ranking PAM pages. When we scope a PAM, we start with the wallet API contract, data-export terms and the market’s limit and exclusion rules. Capermint is an Ahmedabad-based studio with over 200 specialists and 650+ customers worldwide (Capermint-reported); see our iGaming portfolio.