Single Customer View for Gambling Operators: What Regulators Want and What a Customer Data Platform Must Do

Single customer view (SCV) has two meanings in gambling. Inside a group it means one identity per player across brands, which the UK Gambling Commission already requires under social responsibility code 3.9.1. Across operators it means shared risk data, which in Great Britain is GamProtect, a voluntary Betting and Gaming Council scheme that shares account-closure flags and had 12,778 individuals registered by March 2026. A customer data platform (CDP) has to support both.

Who this is for: heads of safer gambling, compliance and data platforms at licensed operators. For the general concept, read single customer view; this page covers gambling-specific rules. Part of our iGaming customer data platform hub.

Two meanings of single customer view in gambling

Inside the operator or group. The regulator expects you to know that three accounts across three brands belong to one person, and to act on the combined behaviour. In Great Britain this is a licence requirement.

Across operators. The Gambling Commission challenged the online industry in February 2020 to develop a cross-operator view of a customer's behaviour, because online gamblers hold several accounts and harm can be missed when each operator sees only its own slice 1. It chose not to mandate a particular solution and left industry to build and test one 1.

What the UK requires inside your own group

Social responsibility code 3.9.1 (remote identification of individual customers) is the regulatory basis for an internal identity graph. It requires licensees to have policies to identify separate accounts held by the same individual, and where a customer can hold more than one account, to relate those accounts so that 3:

• a self-exclusion applies to all gambling with the licensee, unless the customer says it covers only some products or accounts;
• all of a customer's accounts are monitored, and decisions that trigger customer interaction rest on behaviour and transactions across all of them;
• any credit limit applies in aggregate across accounts; and
• individual financial limits can be applied across all accounts.

For companies, the provision extends to accounts held with group companies, on a reasonable-steps basis 3. The self-exclusion code adds a time limit on the marketing side: operators must remove a self-excluded person from marketing databases used by the company or group, or flag them as not to be contacted, within two days of the completed notification 3.

The Commission's customer interaction guidance reinforces the point: integrate systems so staff have a more complete picture of the customer, including records of earlier interactions, and note that the licensee remains responsible when a third-party platform runs part of the offer 4.

GamProtect: status in 2026

GamProtect is the Betting and Gaming Council's scheme for sharing risk flags between operators. It grew from the Commission's challenge and the ICO sandbox work below.

Three conclusions follow. GamProtect is live and growing but, on the licence conditions we read, still voluntary. In 2024 the Commission said the 2023 White Paper allows mandation to be considered if participation does not grow, and urged operators outside the founding group to onboard 8. And it declined to confirm or deny holding data on system failures and holds no figures on prevented attempts 9, so public performance data is thin.

What data GamProtect shares and on what legal basis

The ICO's exit report describes the design it reviewed. Three use cases were considered: customer-initiated self-exclusion, operator-enforced account closure, and a wider risk-score model. The operators built the second one first 7.

The legal analysis is what operators ask about most:

Cross-operator schemes beyond Great Britain

Regulators elsewhere mostly run the cross-operator layer, so your platform must integrate with it.

A German operator must check its customer against a national limit file and an activity file in real time, so a German SCV is largely a regulated integration. A British group must build its own identity layer and decide whether to join GamProtect.

How operators implement an internal single customer view

The internal build has five parts.

1. Identity across brands and products. Link accounts with deterministic keys (verified email, mobile, document-verified name and date of birth, payment instruments) and keep the merge history so each link can be explained. See identity resolution explained.
2. Limits that follow the person. Deposit and loss limits, breaks and exclusions apply across the linked accounts, as code provision 3.9.1 requires for financial limits 3.
3. Register checks. Check GAMSTOP, and in other markets the local register, at registration and again as the register changes, then propagate the result everywhere the person has an account.
4. Suppression in marketing systems. An exclusion must reach every campaign tool inside the two-day window 3. See consent withdrawal and suppression architecture.
5. Evidence. Keep the reason, time and rule behind every flag and action, because the Commission expects licensees to evaluate and demonstrate the effect of their interventions 4.

What a customer data platform must do

A customer data platform (CDP) is the natural home for the identity graph and the flag state, provided it meets these requirements:

• Cross-brand identity graph with explainable merges and splits, queryable in real time for "all accounts of this individual".
• Safer-gambling state as first-class data: self-exclusion, closure flags, limits and interventions, versioned and time-stamped.
• Inbound and outbound flag handling: receive register results and, where you participate, send and receive closure flags, with matching rules recorded.
• Purpose separation. Keep safer-gambling data apart from marketing use. The ICO expected GAMSTOP data to be segregated from SCV data 7, and Alberta limits player information to the lottery schemes its bodies run 16; the Commission says its financial risk assessment requirements will bar commercial use of that data 18.
• Minimisation. Share and store flags, not behavioural features, matching the proportionate design the ICO reviewed.
• Audit and contestability. An append-only record of each decision, its inputs, and the manual review and customer challenge route that UK guidance requires for automated decisions 4.
• Residency. Hold the graph inside each licence's boundary where required; see player data residency by jurisdiction.

PrivyCDP is a customer-owned deployment (on-premise, in your own cloud account, hybrid or sovereign) with an immutable append-only audit ledger and open APIs, one way to meet the audit and residency items; it does not run GamProtect or any register.

See also responsible gambling interventions in real time and real-time decisioning.

Single customer view checklist

1. Map every account-holding entity, brand and platform, including third-party platforms you are responsible for.
2. Define deterministic identity rules and the review process for uncertain matches.
3. Confirm limits, exclusions and monitoring run across linked accounts.
4. Connect to every mandatory register and test failure behaviour.
5. Decide whether to join GamProtect, with a legitimate interests assessment and an updated data protection impact assessment.
6. Add suppression to every channel tool and measure time to suppress against the two-day rule.
7. Separate safer-gambling data from marketing purposes in policy and access control.
8. Record rationale, rule version and reviewer for each flag-driven action.
9. Provide a customer route to contest automated decisions.
10. Check retention periods for flags, closures and logs against each market's rules.

To test whether a customer-owned deployment fits your licences and your identity-graph and audit requirements, start with our deployment qualification. More in the iGaming hub.