What is included
- Account: registration, login, profile and player status: active, under review, blocked, self-excluded.
- Wallet and transactions: real and bonus balance, deposits, withdrawals, bets and wins, with a separate record for every operation.
- Bonus engine: offer terms, wagering requirement, time limits, game weighting, crediting and forfeiture.
- KYC and checks: document statuses, AML flags.
- Responsible gambling: deposit limits, time-outs, self-exclusion.
- Back office and reporting: GGR, bonuses, payouts and a log of staff actions.
What it is linked to
The PAM sits at the centre. Games connect through an aggregator or directly, money flows through the cashier and PSPs, and data goes to CRM, analytics and anti-fraud. With game providers, the PAM usually works on the seamless wallet model: the casino holds the balance, and the game debits and credits money via API.
Operators rarely build their own PAM: it is slow and expensive. More often it comes from a supplier, on a turnkey platform or as part of a white label.
What matters to CRM
- Real-time events: registration, deposit, declined payment, bet, end of a bonus. An abandoned deposit message goes out within half an hour, and a once-a-day export is no good for that.
- Bonuses via API: CRM issues the offer itself, with no manual crediting.
- Exclusion flags: self-exclusion, limits and risk markers are visible to CRM before every send.
- New offer types are set up in the back office instead of waiting for a platform release.
Common mistakes
- Choosing a PAM by its feature list. What matters more is whether the platform sends events instantly and issues bonuses via API: all of CRM depends on it.
- The limit exists only in the interface. A deposit limit must block the payment in the PAM itself, and CRM must see the flag. Otherwise a player with a limit gets a deposit offer.
- Manual bonuses without a log. Credits from support and VIP managers are bonus cost too. Without a record of who credited what, to whom and why, they drop out of Bonus Rate.