CRM Suppression After Self-Exclusion and RG Flags

What must be suppressed?

How should suppression work technically?

What do UK rules and guidance say?

igaming.cx covers this in detail: suppressing CRM after self-exclusion.

Which systems must receive the suppression?

How do you test that suppression works?

1. Create test accountsUse internal accounts in each market and self-exclude them.
2. Check every channelConfirm no messages arrive by email, SMS, push, on-site or paid audiences.
3. Check timingMeasure the time from exclusion to suppression in each system.
4. Check third partiesConfirm affiliates and providers received the update.
5. Repeat after changesRetest after any CRM, provider or data pipeline change.

igaming.cx describes suppressing CRM after self-exclusion.

What should happen when a player asks to come back?

When an exclusion ends, the player should not be added straight back to marketing. A safer approach is to require a positive action to return, run checks for harm indicators, apply sensible default limits, and only restart marketing with fresh consent. Win-back campaigns aimed at former self-excluders are a known regulatory risk.

What should a suppression record contain?

Worked example: a national scheme match at login

1. 09:00
   A player registers with the national self-exclusion scheme on its website.
2. 19:30
   The player tries to log in to an operator. The operator’s check against the scheme returns a match.
3. 19:30
   Login to gambling is blocked; the player can still access the balance to withdraw where rules allow.
4. 19:31
   A suppression record is created and pushed to the CRM, SMS, push and paid audience systems.
5. 19:35
   A scheduled promotional email due at 20:00 is removed from the send queue.
6. Next day
   Affiliate and partner lists are updated in the daily file.

igaming.cx explains suppressing CRM after self-exclusion.

How do national schemes compare?

See self-exclusion schemes for details of each.

Why does suppression fail in practice?

Suppression rarely fails because a team decided to market to excluded players. It fails at the joins between systems. Common causes include a CRM that receives exclusions in a nightly batch while a real-time journey fires in the meantime, an SMS provider holding its own copy of the audience, a paid social audience uploaded months ago and never refreshed, and an affiliate that never received the update.

Brand and group structure adds another layer. A player who self-excludes from one brand may also hold accounts with sister brands under the same licence. Depending on the market and the type of exclusion, operators may need to apply the exclusion across all of them. National schemes such as GAMSTOP, Spelpaus and OASIS cover every licensed operator, so the check has to happen everywhere the player could gamble.

The safest design treats suppression as a gate that every outbound message passes through at send time, not as a list that is copied into each tool. When a message is about to be sent, the system checks the current status of the player. That way, a late or missing copy cannot cause a breach.

What evidence should operators keep?

If a regulator or a player asks whether a self-excluded customer received marketing, the operator needs to answer quickly and with evidence. Useful records include when the exclusion was received, when each system acknowledged it, which scheduled messages were cancelled, and the send logs for the period. Regular tests with internal accounts, documented with screenshots and logs, show that controls work in practice.

Evidence also helps internally. When a breach happens, a clear timeline shows where the failure occurred and what to fix, rather than leaving teams to guess.

How does suppression work end to end, step by step?

1. Exclusion receivedFrom the player, a national scheme check, or the safer gambling team.
2. Status set at the sourceThe player account platform marks the player as excluded with scope and dates.
3. Event publishedAn exclusion event is sent to every marketing and messaging system in real time.
4. Queues purgedScheduled messages and journeys for the player are cancelled.
5. Send-time checkEvery outbound marketing message checks current status before sending.
6. Third parties updatedAffiliates, paid audiences and partners receive the update ^[3].
7. Evidence keptEach system’s acknowledgement is logged.
8. End of exclusionMarketing stays off until the player positively chooses to return and gives fresh consent.

Which regulators and schemes set suppression rules?

What does good suppression look like?

How should edge cases be handled?

Edge cases are where breaches tend to happen. Writing down the rule for each one, and testing it, keeps decisions consistent across teams.

Which metrics prove suppression works?

A daily check of send logs against the exclusion list catches failures that design reviews miss. Any message found should be treated as an incident, investigated and recorded, in line with the Commission’s guidance on keeping marketing away from self-excluded customers ^[8].

Reporting these metrics to senior management each month keeps suppression visible. It is easy for a control that works today to break silently after a vendor change, a new brand launch or a data migration, and regular reporting is the simplest way to notice.

What are the suppression rules by market?

Worked example: a same-day self-exclusion

What mistakes do operators commonly make?

Checklist

• Single source of truth for RG status.
• Real-time sync to every channel.
• Pre-send checks.
• Affiliate feeds included.
• National registers integrated.
• Audit logs kept.
• Suppression reaches every channel and third party.
• Monthly test with internal accounts.
• Time-to-suppress measured.
• No win-back to former self-excluders.
• Suppression record schema.
• Scheduled sends purged on exclusion.

Frequently asked questions

Sources

More guides