How player data is stored and protected

The players are the operator's, and so is their data. Each brand runs as its own deployment with its own database, so one operator's players are never stored alongside another's. The hosting provider and region are agreed per deployment.

In data-protection terms the operator decides what player data is collected and why; WW Games runs the platform that stores and processes it. If your market requires a written agreement on that processing, raise it before signing.

How the separation between brands works — deployments, databases, entry points — is set out on security. Provider and region are not published, for the reason given there: it helps someone attacking a brand more than someone evaluating one.

What an account, a wallet and fraud checks need: sign-in details, an optional profile, where the account was registered from, a device identifier, and the history of money and play. It does not store card numbers.

Card details are entered on the payment provider's page, not on the casino's. The platform receives the result of a payment, not the card, which keeps card data out of the brand's database altogether. How payments flow is on payments.

To catch fraud that costs operators money: several accounts run by one person, players referring themselves, and bonus abuse. Registration IPs and device identifiers are what those patterns are recognised by.

The device identifier comes from the player's browser and is treated as a signal, never as proof: it feeds a risk score that staff review, and a decision to hold a player is made by a person. How that works — without the thresholds, which are not published — is on anti-fraud.

Player and staff passwords are stored only as bcrypt hashes, never as text. Staff two-factor secrets are encrypted, players can sign in with passkeys, and sessions can be revoked at once.

A hash cannot be turned back into the password, so a copy of the database does not give anyone the passwords in it. Passkeys go further: there is no shared secret for a phishing page to capture. For the back office, sign-in requires a two-factor code and sensitive actions ask for it again — described on security.

Passwords, access and refresh tokens, two-factor codes and secrets, Telegram sign-in data, API keys and crypto wallet material are replaced with a placeholder before anything is written to logs, the audit log or the error tracker.

One list of sensitive fields drives every place data is written — request logs, error handling, the staff audit log, event records and the error tracker — so a new secret is protected everywhere by adding it once. The error tracker is also configured not to collect personal data by default.

Logs are where data leaks without anyone noticing: a debugging line that prints a request body can put thousands of passwords into a file nobody thinks of as sensitive. Removing them at the point of writing is the only reliable fix.

Only staff given the permission. Seeing players, balances and transactions is granted separately from acting on them, and every sensitive action — and every sign-in attempt — is recorded with who, what, when and from where.

A support agent can be allowed to read a player's history without being able to move money or change the account. Reading the audit log is itself a separate permission, and what it stores is sanitised so that credentials never end up in it. The full model is on security.

A full copy of the brand's database is taken every night and kept for a few days in object storage, with a minimum number of copies always retained. Older copies are deleted automatically.

Short retention is a data-protection choice as much as a storage one: a copy that no longer exists cannot leak. The order of operations — verify, upload, verify again, only then prune — and the recovery point are on security.

No. The back-office AI copilot answers from the platform's operator guide, has no access to players or balances, and is instructed not to ask for, repeat or process players' personal data. Its conversations are deleted after 90 days.

The language model is reached with provider-side data collection turned off and zero-data-retention routing on by default, and a deployment can point the copilot at a model on its own infrastructure. The copilot is switched on per brand, only for operators who want it — see AI copilot.

Not by themselves: the product has no self-service account deletion or data export for players today. How such requests are answered is the operator's decision; ask us how they are handled on your deployment.

We would rather say this than imply a feature that is not there. What the admin panel does offer is closing a player's access with a ban, and marketing respects it: banned players are left out of on-site notifications.

WW Games holds no third-party security or privacy certification; the full list of what we do not claim is on security.