Single Customer View: Building One Across Brands Without Breaching GDPR
Multi-brand operators face a structural conflict between the responsible gambling imperative to maintain a unified view of player behaviour and GDPR's purpose limitation and data minimisation principles. This article maps the lawful basis options, architecture trade-offs, and regulatory expectations from the UKGC and MGA.
The Structural Conflict Multi-Brand Operators Cannot Ignore
Multi-brand iGaming groups face a genuine regulatory collision. On one side, gambling regulators in the United Kingdom, Malta, and an increasing number of European markets expect licensees to maintain a coherent, real-time picture of each player’s behaviour across all products and brands they operate. On the other side, the General Data Protection Regulation (GDPR) and, in the United Kingdom, the UK GDPR as retained under the Data Protection Act 2018, impose hard constraints on how personal data can be aggregated, shared across legal entities, and reused for purposes beyond those originally disclosed to the data subject.
A Single Customer View (SCV) is, in architectural terms, a unified data record that consolidates identity, transactional, behavioural, and responsible gambling attributes for one natural person across multiple brands or products under common ownership. The compliance question is not whether to build one. For any operator of meaningful scale, the responsible gambling case is compelling and, in several jurisdictions, effectively mandated. The question is how to build one that withstands scrutiny from both the gambling regulator and the supervisory authority responsible for data protection enforcement.
This article does not address the technical build in depth. It maps the legal architecture that must sit beneath any SCV: the lawful basis, the purpose limitation analysis, the controller relationship structure, and the retention framework. Operators should treat this as a framework for engagement with qualified legal counsel rather than definitive legal advice for any specific group structure.
What the Gambling Regulators Actually Require
The MGA Player Protection Directive (Directive 2 of 2018, V3 January 2023) creates a nuanced but important obligation. Article 17(1) of the Directive requires B2C licensees to employ effective measures and processes to detect and identify problem gambling and actions or behaviour indicative that a player is at risk, using analytical tools and behaviour monitoring systems. This obligation is framed at the licensee level, not the brand level. Where a single licensee operates multiple brands, the detection obligation attaches to the licensee as a whole.
The MGA Directive further provides that where a B2C licensee operates multiple brands and those brands require separate player registration, deposit and wagering limits may be implemented at the individual brand level upon player request. However, the responsible gambling detection obligation under Article 17 is not similarly relaxed. The licensee must maintain the analytical capability to identify at-risk behaviour regardless of brand structure.
The practical implication is that a licensee cannot argue that its responsible gambling obligations are satisfied by brand-level monitoring alone when a player who is not flagged on Brand A and not flagged on Brand B is, when viewed in aggregate, exhibiting clear markers of harm. The Directive’s requirement for effective detection implicitly demands a consolidated view where technically and operationally feasible.
The UK Gambling Commission’s Licence Conditions and Codes of Practice (LCCP) impose analogous requirements on remote gambling licensees. The relevant social responsibility codes require licensees to implement processes that identify customers showing indicators of harm and to take action. The UKGC has indicated in its guidance on customer interaction that operators should consider all available information, which industry consensus reads as extending to cross-product data held within the same corporate group where systems permit. Operators active under a UKGC remote operating licence should consult the current LCCP social responsibility codes and associated guidance for the precise current formulation, as these have been subject to ongoing revision.
The GDPR Framework: Five Principles That Constrain Every Architecture Choice
GDPR Article 5 establishes the foundational principles against which any SCV must be assessed. The most operationally consequential for cross-brand data aggregation are purpose limitation, data minimisation, and storage limitation.
Purpose limitation, under Article 5(1)(b), requires that personal data collected for specified, explicit, and legitimate purposes must not be processed in a manner incompatible with those purposes. When a player registers on Brand A, the data collected at that point is collected for the purposes disclosed in Brand A’s privacy notice. If Brand A’s privacy notice states that data is used for account management, identity verification, and responsible gambling on that brand, then routing that player’s data into a group-wide SCV for cross-brand profiling is a secondary processing purpose. Whether it is compatible with the original purpose requires a formal compatibility analysis under Article 6(4), examining the link between the purposes, the context and expectations of the data subject, the nature of the data, the consequences, and the existence of appropriate safeguards.
Data minimisation, under Article 5(1)(c), requires that personal data be adequate, relevant, and limited to what is necessary in relation to the purposes for which it is processed. An SCV architecture that aggregates every granular betting event, session duration, and device identifier across all brands may not satisfy minimisation if the legitimate purpose can be achieved with a subset of those attributes. In practice, operators should design the SCV schema with a documented minimisation rationale for each data field, not simply pull every available attribute because it might be useful.
Data protection by design and by default, under Article 25, requires that appropriate technical and organisational measures, including pseudonymisation, be implemented at the time of determining the means of processing. The ICO’s guidance on data security confirms that this is not a post-build compliance check but an obligation to embed privacy into the architecture from the outset. For an SCV, this means the design phase must address pseudonymisation of cross-brand identifiers, access controls scoped to the minimum necessary, and default settings that do not expose data to purposes beyond those currently justified.
Key requirement: GDPR Article 25(2) requires that, by default, only personal data necessary for each specific purpose is processed. Operators cannot build an SCV with maximum data aggregation and then apply purpose restrictions at the query layer : the default state of the system must reflect minimisation, not merely permit it.
Lawful Basis: Which Article 6 Ground Actually Works
Selecting the correct lawful basis under GDPR Article 6 is not a formality. The basis chosen constrains the processing activities that can be performed, determines the data subject rights that apply, and affects whether secondary purposes are compatible. For cross-brand SCV processing in the gambling context, three bases are relevant.
Consent, under Article 6(1)(a), is frequently proposed but is the weakest option in this context. Consent must be freely given, specific, informed, and unambiguous. In a contractual relationship where the player cannot access the service without providing data, the freedom element is compromised. More fundamentally, consent can be withdrawn at any time, and withdrawal must be honoured promptly. An SCV whose responsible gambling function depends on consent is architecturally fragile: the player who may be most at risk is also the player most likely to withdraw consent for intrusive monitoring.
Legal obligation, under Article 6(1)(c), is available where processing is necessary to comply with a legal obligation to which the controller is subject. Where a gambling regulator’s directive or licence condition effectively mandates cross-brand monitoring, this basis has real force. The MGA Article 17 obligation and equivalent UKGC requirements provide a credible anchor. The limitation is that legal obligation under Article 6(1)(c) covers only what the law actually requires; it cannot be stretched to cover commercially motivated uses of the aggregated data beyond regulatory compliance.
Legitimate interests, under Article 6(1)(f), requires the controller to identify a legitimate interest, demonstrate that processing is necessary for it, and balance the interest against the data subject’s rights and expectations. In the context of preventing gambling harm, the interest is readily characterisable as legitimate. The necessity limb requires that the SCV is the least intrusive means of achieving the objective. The balancing test is where operators frequently underinvest: the analysis must consider that players may not expect their data to be consolidated across brands and may not have been clearly informed that this would occur. Transparency in the privacy notice, combined with meaningful opt-out rights for processing beyond the strict minimum necessary for harm prevention, strengthens the balance.
Industry consensus is that a layered basis is the most defensible position: legal obligation for the core responsible gambling detection and limit-enforcement functions; legitimate interests, supported by a documented balancing test, for the broader behavioural analytics that enhance but are not strictly required by the regulatory obligation.
Controller Relationships: Joint Controllership Across Group Entities
GDPR Article 26 provides that where two or more controllers jointly determine the purposes and means of processing, they are joint controllers and must enter into a transparent arrangement reflecting their respective responsibilities. This provision is directly relevant to multi-brand groups where the SCV is hosted centrally but data is contributed by, and used for decisions within, multiple legal entities operating separate brands.
The Court of Justice of the EU’s interpretation of joint controllership has been expansive. Where Brand A’s player data is fed into a group SCV maintained by a parent or shared services entity, and that consolidated data is then used to trigger responsible gambling interventions on Brand B, both entities are participating in determining the purposes and means of processing. A formal joint controller arrangement under Article 26 is required. That arrangement must, at minimum, allocate responsibility for providing Articles 13 and 14 privacy information to data subjects, designate a contact point for data subjects exercising their rights, and specify which entity responds to data subject requests.
Where the SCV is operated by a third-party data platform on behalf of the group, a data processing agreement under Article 28 is additionally required between the group entity acting as controller and the platform as processor. Operators should be careful not to mischaracterise a joint controller relationship as a processor relationship simply because a technology vendor is involved. If the vendor exercises any meaningful influence over the purposes of processing, the Article 28 framing is legally incorrect.
Architecture Options and Their Data Protection Trade-Offs
Three broad architectural patterns are used in practice, each with different GDPR implications.
The centralised master record model maintains a single database linking all brand accounts to a master player identity. This offers the most complete view and the simplest responsible gambling logic, but it concentrates data protection risk. A breach at the central layer exposes cross-brand data for all players. The minimisation obligation under Article 25 requires that the central record hold only what is necessary, not a full replication of each brand’s data schema. Access controls must be role-based and logged.
The federated query model keeps data at brand level but allows a central orchestration layer to query across brands in real time, assembling a transient consolidated view for a specific purpose without maintaining a persistent cross-brand record. This architecture more naturally supports minimisation and purpose limitation, because the query can be scoped precisely to the data needed for the responsible gambling check. The trade-off is operational complexity and the risk that query logs themselves constitute personal data requiring management.
The pseudonymised identity spine model creates a cross-brand identifier that is derived from, but not directly equal to, the player’s identity attributes. Each brand holds its own data; the spine holds only the pseudonymous link and aggregated risk signals. This is the architecture most aligned with the Article 25 data protection by design obligation, particularly when the derivation key is held separately with strict access controls. It does not, however, eliminate the GDPR obligations: pseudonymous data that can be re-identified by the controller remains personal data.
Architecture note: No architecture eliminates GDPR obligations : it only affects the severity of risk and the strength of the minimisation argument. The choice of architecture should be documented in a Data Protection Impact Assessment (DPIA) under GDPR Article 35, given the large-scale processing of personal data and systematic profiling involved.
Retention: Aligning Gambling Regulatory Requirements with Storage Limitation
GDPR Article 5(1)(e) requires that personal data be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which it is processed. For gambling operators, this interacts with mandatory retention periods imposed by regulators and AML frameworks.
The GlüStV 2021, Germany’s Interstate Treaty on Gambling, provides a useful reference point from a parallel jurisdiction: Section 6g(1) requires licensees to retain players’ personal data for five years after account closure, after which deletion is mandatory. This illustrates that gambling-specific retention obligations can run longer than a controller might otherwise choose, and that those obligations can constitute a legal basis for retention under Article 6(1)(c) during the prescribed period.
For SCV data specifically, operators must distinguish between the retention period for brand-level transactional data, which is typically anchored to AML and gambling regulatory requirements, and the retention period for the consolidated cross-brand risk profile, which may have no direct regulatory mandate for extended retention beyond the period of the player relationship. Retaining aggregated cross-brand profiles for years after a player has closed all accounts and is no longer a customer requires a clearly identified purpose and legal basis. Commercial re-engagement analytics would not meet that threshold under a legal obligation basis.
Operators should document a retention schedule that maps each data category held in the SCV to a specific retention period, the regulatory or legal basis for that period, and the deletion or anonymisation process applied at expiry. The ICO’s guidance confirms that retention policies must be implemented in practice, not merely stated in documentation.
Transparency: Privacy Notices as the First Line of Compliance
The purpose limitation and legitimate interests analyses both depend heavily on what players were told at the point of data collection. Articles 13 and 14 of the GDPR require controllers to provide clear information about the purposes of processing and the legal basis, any recipients or categories of recipients of the data, and where processing is based on legitimate interests, what those interests are.
For a multi-brand group operating an SCV, this means each brand’s privacy notice must accurately describe that player data may be shared with or accessible to other group entities, that a consolidated view of behaviour across brands may be maintained for responsible gambling purposes, and the basis on which this is done. A privacy notice that describes data processing only in brand-specific terms, while the group actually operates an SCV, is a straightforward non-compliance with Article 13.
In practice, operators should layer their privacy information: a short-form notice at registration that clearly flags cross-brand data consolidation, with a link to a full privacy policy that explains the scope, basis, safeguards, and data subject rights in detail. The notice should be reviewed whenever the SCV architecture or processing purposes change materially.
Source: GDPR (Regulation (EU) 2016/679), Articles 5, 6, 13, 14, 25, and 26. MGA Player Protection Directive (Directive 2 of 2018), V3 January 2023, Articles 16 and 17. UK Data Protection Act 2018. ICO Guide to Data Security (under review following Data (Use and Access) Act, in force 19 June 2025).
Key Resources
GDPR (Regulation (EU) 2016/679), Official Journal of the European Union, 4 May 2016. Available at eur-lex.europa.eu.
UK Data Protection Act 2018, as enacted. Available at legislation.gov.uk. Note: ICO guidance is under review following the Data (Use and Access) Act coming into force on 19 June 2025.
MGA Player Protection Directive (Directive 2 of 2018), Version 3, January 2023. Published by the Malta Gaming Authority. Available at mga.org.mt.
ICO Guide to Data Security (Part of the UK GDPR guidance series). Available at ico.org.uk. Subject to update following the Data (Use and Access) Act 2025.
UKGC Licence Conditions and Codes of Practice, Social Responsibility Code provisions on customer interaction. Current version available at gamblingcommission.gov.uk. Operators should verify the current version at time of implementation.
Matt Denney
Editorial · gamingcompliance.io
Reads the primary source so you don't have to. Fifteen years inside iGaming compliance: operator, supplier, and crown-corporation lottery.
The Tuesday brief, every week.
One email. Every regulator change we surface, every standard we re-index, every enforcement decision we read. No marketing, no fluff.
Unsubscribe with one click. We'll never share your address.