CRM guides
CRM Architecture for Consent-Aware Gambling Marketing
A consent-aware gambling CRM keeps permissions and exclusions in their own stores, apart from profile and campaign data, and makes every send ask one decision point that reads all of them at the moment of sending.
In short
- Keep four kinds of data apart: identity, marketing permissions, safeguarding status and campaign activity.
- Exclusions and opt-outs win over every permission, so store them where no campaign tool can edit them.
- Make one service answer "may we send this message to this person now?" and call it on every send.
- Record every permission change as an event, so the current value can always be explained.
Scope and limits. This guide describes a reference structure, not a product. It reflects the Gambling Commission's direct marketing and self-exclusion codes for Great Britain and the general rules compared on consent rules in each market. We have not audited any operator's CRM.
Why architecture decides whether exclusions hold
The failures the Gambling Commission lists are mostly data problems, not decisions to break a rule: a list exported before an exclusion arrived, a field that one system updated and another did not, a manual workaround. The Gambling Commission's page on self-excluded customers lists exactly these causes, including "the recycling of old customer lists which had not been updated" and "technical vulnerabilities in control systems".
The structure below is designed so that a stale copy cannot be used to send a message, because the send itself re-checks the source of truth.
The four stores
| Store | What it holds | Who may write to it |
|---|---|---|
| Identity | Account ID, contact details, verified age and identity status, market | Registration and verification services |
| Permissions | One record per product and channel, with value, time, source and wording shown | Preference center and registration flow only |
| Safeguarding | Self-exclusion, national register matches, objections to marketing, safer gambling flags | Responsible gambling systems and the register checks |
| Campaigns | Segments, sends, opens and clicks | Marketing tools |
The rule that holds this together: campaign tools may read permissions and safeguarding status, but they never write to them. A marketing user who wants to "re-add" a customer to a list cannot, because the list is not where permission lives.
Permissions as records, not flags
A single "marketing allowed" checkbox cannot meet the British rule for remote casino, bingo and betting licensees. Social responsibility code 5.1.12 says "Licensees must provide customers with options to opt-in to direct marketing on a per product and per channel basis." That means a matrix: betting, casino and bingo against phone, email and text message, as applicable to the business.
Store each cell as its own record with the value, the time it was set, the screen or process that set it and the wording the customer saw. Code 5.1.11 asks that licensees "be able to provide evidence which establishes that consent", and the stored wording is that evidence. Managing preferences across products and channels covers the matrix in detail, and append-only consent records covers the evidence.
Safeguarding sits above permissions
Self-exclusion and objections to marketing are more than another permission value. In Great Britain, code 3.5.3 requires reasonable steps to keep marketing away from self-excluded customers; the rule in each market is in exclusion deadlines by market. Under the UK General Data Protection Regulation (UK GDPR), the Information Commissioner's Office (ICO) says "Individuals have an absolute right to stop their data being used for direct marketing."
Put these facts in the safeguarding store and give them precedence in the decision service. A customer can hold a valid opt-in for casino email and still be excluded; the exclusion wins. The order of checks is described in consent-gated workflows.
One decision point
Every channel tool should call the same decision service with three inputs (customer, product, channel) and get back one of three answers: send, suppress or hold for review. Keeping the logic in one place means a rule change is made once, and every tool behaves the same way.
Example, illustrative only:
POST /decide
{"customer": "C-1042", "product": "casino", "channel": "sms", "purpose": "marketing"}
200 OK
{"result": "suppress", "reason": "self_excluded", "checked_at": "2026-10-28T10:15:02Z"}The response carries a reason code and a timestamp, so the send log can show why a message was or was not sent. You can try the same order of checks in the decision-order explorer.
Changes travel as events
When a permission or exclusion changes, the store emits an event that every connected system consumes. The event design, including what to do when a system is offline, is in the permission event format. Exclusions also need a list that survives account closure; see suppression lists. To test whether a product supports this structure, use the CRM platform evaluation criteria.
Questions
Can the marketing platform hold its own copy of permissions?
It can cache them for segmentation, but the send itself should still call the decision service, because a cache can be out of date when an exclusion arrives.
Where should a national register match be stored?
In the safeguarding store, with the date of the check and the register's reference, so the suppression can be shown later.
Sources
- Gambling Commission, LCCP Condition 5.1.11 - Direct electronic marketing consent, no date shown.
- Gambling Commission, LCCP Condition 5.1.12 - Direct marketing preferences, no date shown.
- Gambling Commission, LCCP 3.5.3 Self-exclusion - remote SR code, no date shown.
- Information Commissioner's Office, Right to object, page dated March 25, 2025 (under review after the Data (Use and Access) Act).
Every source was read on October 28, 2026. How we choose sources: data sources.
Safer gambling support is listed on the safer gambling page.