Player protection
Protection should change what the platform can do.
A customer protection decision should not live in a spreadsheet. If somebody has reached a spending limit, checkout should know. If somebody has stepped away, participation should know. If somebody is excluded, marketing should know. If behaviour raises a concern, a person should be able to see it and act.
Beaver puts player protection into the operating flow rather than treating it as a page of good intentions.
One customer. One protection state.
- Entry eligibility
- Spending
- Marketing eligibility
- Operator review
Why this matters
Policies do not process transactions.
An operator can publish a responsible play policy explaining everything it intends to do. That matters. But the useful test comes when the customer reaches the point where that policy should affect an actual action.
- Can they spend again?
- Can they enter?
- Can marketing target them?
- Can the operator see the history?
Beaver is designed to make those answers part of the software.
A protection rule is strongest when the transaction knows about it.
Current UK good practice
The expectations now go further than a disclaimer.
For relevant signatories, the DCMS Voluntary Code includes measures around 18 plus participation and reasonable age verification, monthly spending controls, temporary account suspension, monitoring activity for signs of potential harm, proportionate intervention, credit card restrictions and marketing restrictions during suspension.
The Code is voluntary rather than legislation, and it does not replace consumer or advertising law. So Beaver distinguishes clearly between the external standard, the software control and the status of that control.
Requirement. Control. Status. Evidence.
Spend · Pause · Stop
The useful limit is the one that says no.
Live A player monthly limit and an operator platform cap, both enforced at checkout and on top ups. Built A cooling off period for increases and a rolling 30 day credit card cap.
Live Take a break and single operator self exclusion, which enforces a minimum period and is designed to survive re registration.
Audit record
Illustration of where enforcement happens, with example values. Not the Beaver product interface.
-
Take a break
Stepping away should affect access.
Live
The product can place an account into a temporary suspension state.
The DCMS Code describes a temporary suspension lasting at least six months, and encourages shorter pause options where technology allows. We will not use one Beaver label as if it proves every part of that clause. The final control mapping will show exactly which Beaver state satisfies which requirement.
Name the state properly. Then enforce what it means.
-
Self exclusion
Excluded should mean excluded.
Live
Single operator self exclusion enforces a minimum period and is designed to survive re registration, rather than disappearing when somebody creates another account.
Not "we added an exclusion checkbox". The exclusion remains part of the customer state.
-
Cross operator protection
One exclusion across participating operators.
Built
An opt in cross operator exclusion architecture, using a salted hash register shared across operators that choose to take part.
It is not a national register, an industry scheme, widely adopted or a GAMSTOP equivalent. The architecture is built; adoption has to be earned.
-
Care signals
Software can spot a pattern.
Built
Monitoring rules covering signals such as spending velocity, night time activity, repeated limit hits and behaviour consistent with chasing losses.
Beaver does not diagnose harm, make a clinical assessment or claim a predictive accuracy rate. It identifies configured behavioural signals.
A signal says look here. It does not claim to know the whole person.
-
Intervention
A flag should create work for a human.
Built
Identified signals become a queue for operator review, raised hourly. Automation identifies the reason to look. A person decides what the context means and what proportionate action is appropriate.
Software raises the flag. People make the judgement.
-
Marketing suppression
Protection has priority over promotion.
Live
A flagged player can be suppressed from targeting. A closed account receives no marketing, while communication about a prize still owed remains possible. Channel preferences for email, SMS, push and on site are Built.
The win back campaign does not get a veto.
One customer state
Why integration matters.
Imagine the opposite model. A customer reaches their limit in Platform A. An exclusion is recorded in Platform B. Email audiences sit in Platform C. Push notifications sit in Platform D. The operator then has to hope all four agree quickly enough.
Beaver's direction is different.
Protection works better when every part of the platform is looking at the same customer.
- Customer
- Protection state
- Entry eligibility
- Spending
- Marketing eligibility
- Operator review
What is live today?
Player protection is too important for fuzzy feature status.
| Capability | Status |
|---|---|
| Player monthly spending limit | Live |
| Operator platform spending cap | Live |
| Take a break | Live |
| Single operator self exclusion | Live |
| Marketing suppression on a care flag | Live |
| Closed account marketing suppression | Live |
| Cooling off on limit increases | Built |
| Rolling credit card limit | Built |
| Cross operator exclusion register | Built |
| Harm monitoring | Built |
| Intervention queue | Built |
Live proven on the deployed platform. Built in the product with passing tests, not yet proven with live customers. Roadmap planned, not a working feature.
What Beaver does not claim
Good protection needs software, process and judgement.
Beaver does not claim that:
- its signals diagnose gambling related harm
- all Built controls have been proven with live customers
- cross operator exclusion has industry wide adoption
- the product replaces trained compliance staff
- using Beaver automatically satisfies every obligation in the Code
- every protection appropriate to every operator has already been identified
Beaver is the software part.
Questions
Asked and answered
Does Beaver include player spending limits?
Yes. Player set monthly limits and operator platform caps are Live. Cooling off on increases is Built.
Does Beaver support self exclusion?
Yes. Single operator self exclusion is Live and is designed to survive re registration.
Does Beaver have a cross operator exclusion system?
The architecture is Built as an opt in salted hash register across participating operators. It is not an established industry wide scheme.
Does Beaver automatically identify customers with gambling problems?
No. Built monitoring rules can identify configured behavioural signals for review. They do not make a clinical diagnosis.
Can an excluded or flagged customer still receive marketing?
Beaver's Live care flag suppression prevents flagged players being targeted, and closed accounts do not receive marketing apart from communication required around an outstanding prize.
Primary sources
Where this page gets its facts
- DCMS: Voluntary Code of Good Practice for Prize Draw Operators(opens in a new tab)Player protection measures for relevant signatories. Last updated 1 September 2026.
Checked 19 September 2026. Guidance changes; always read the current version at source.
See the protection flow
Start with the customer. Follow the state through the platform.
We will show you spending controls, breaks and exclusion, marketing suppression, care signals, the intervention workflow and the current status of each control.