Player account management (PAM)

Who this is for

Two kinds of buyer reach this page. An operator who already runs a casino or sportsbook and wants to replace the account and wallet layer underneath it. And a founder deciding whether the player account should come with the platform or be bought on its own. For the founder: take it with the platform. A separate PAM pays off when you already own the front end, the game aggregation or the sportsbook, and the account layer is the part that fails.

The PAM is the one module that is hard to swap. Games, payments, the bonus engine and the CRM all read from it and write to it. A front end can be replaced in a quarter. A ledger holding live balances, pending withdrawals and half-wagered bonuses moves only with a migration plan and a freeze window.

What the module covers

• Registration and identity. Age check at sign-up, a KYC workflow with document and liveness checks through the provider your licence accepts, and a verification state that gates deposits, play and withdrawals.
• Wallet and ledger. One balance per player across casino, live casino and sportsbook. Cash and bonus money sit apart, and every movement carries a timestamp and a unique transaction ID.
• Limits and exclusions. Deposit, loss, wager and session limits, cooling-off, self-exclusion, operator-imposed limits, and connections to national registers where the licence requires one.
• AML hooks. Thresholds that open a review, flags that hold withdrawals pending source-of-funds checks, and an audit trail of every manual balance adjustment.
• Back office. Roles, account notes, document storage and exports in the regulator's format.

GLI-19, the interactive gaming systems standard (version 3.0) that test labs certify against, sets the floor. It expects one active account per player unless the regulator allows more, and multi-factor authentication for changing credentials or the payment account. It expects a lock after suspicious activity, giving three failed logins in thirty minutes as the example, and re-authentication after thirty minutes idle. Where a player's own limit and an operator's limit differ, the stricter one wins. A player may loosen a self-imposed limit only on twenty-four hours' notice, unless the regulator sets another period.

Module or platform

The question is what you already own, not which PAM has more features. If you are still choosing between white label, turnkey and owning a platform, settle that first in the launch models guide; this table assumes you have.

For the full platform route, start with online casino software, where the delivery models are compared. A module purchase does not change who holds the licence; it changes who carries the integration risk.

The KYC trigger is a setting, not a constant

Licences disagree on when identity must be verified and what the account must check. A PAM that hard-codes one rule needs a code release for every new market. Read the right-hand column as the configuration the module must hold per market.

What integration with an existing stack requires

1. The wallet model. In a single wallet, the aggregator or sportsbook calls your PAM for every bet and win. Aggregators such as Hub88 require that call to be idempotent: a repeated request with the same transaction ID returns the same answer and is never booked twice. A transfer wallet moves money into a separate game balance and back, which is simpler to build and worse for a player who switches between casino and sport.
2. Balances in flight. Cash balances, pending withdrawals, open bets and bonuses part-way through wagering all move with the player. Each needs a mapping and a reconciliation report signed off before cut-over. Our migration service covers this step.
3. Identity records. Verification states, documents and provider references. Agree in advance whether players keep their status or re-verify.
4. Payments. PSP callbacks repointed to the new ledger, and the cashier rules per market moved with them. The payment gateway page covers routing.
5. Events out. The CRM, BI, anti-fraud and affiliate systems need registration, deposit, verification, limit and exclusion events as they happen, not in a nightly file.

Where PAM projects fail

• Bonus money mixed with cash. GLI-19 asks for restricted bonus credits and credits that can expire to be shown separately. A ledger that stores one number cannot migrate wagering progress, and players lose it.
• Limits enforced in the front end. A second front end or a direct API call walks past them. Limits and exclusions belong on the server.
• Exclusion that stops at the account. GLI-19 says excluded players must not be targeted by marketing. If the exclusion event does not reach the CRM at once, the next campaign breaks the rule.
• No export clause. The player database is the asset a buyer or a bank values. Agree format, fields and timing of a full export before you sign, not when you leave.

Questions to put to any PAM vendor, including us

1. Show the ledger entries for a failed withdrawal and its reversal, live, on a test account.
2. Which limit types exist, and can each be switched on per market without a release?
3. Which national self-exclusion registers are connected today, and which are planned?
4. How are duplicate wallet calls handled, and what happens to a bet when the game provider times out?
5. Which test-lab certificates does the PAM hold, against which standard, for which jurisdiction?
6. What does a full export on exit contain, including documents, bonus states and limit history?

What we deliver

Our PAM ships inside every casino and sportsbook build, and we also integrate it as a standalone module under an existing front end, aggregator or sportsbook. Delivery follows the same stages as a full build. Scoping produces a fixed-scope statement. Then come integration, certification where the licence requires it, and launch with hypercare. Where a licence is still being applied for, the licensing team runs it in parallel.

Frequently asked