DCMS Voluntary Code

Good practice now has a written standard.

The UK prize draw market has changed. The DCMS Voluntary Code of Good Practice gives relevant operators a common set of expectations around player protection, transparency and accountability.

For Beaver, the interesting question is practical: what should the software do differently because the Code exists?

What the Code is

The Code was published on 20 November 2025. It focuses on Great Britain prize draws where the result is determined by chance and participants can choose between paid and free entry routes.

Where an operator combines that free draw route with a skill element, the Code says the free draw part of the business should still be covered. It does not cover businesses operating solely genuine skill based prize competitions.

What the Code is not

It is not a new Gambling Act. DCMS explicitly describes the Code as voluntary. It is not legislation. It does not replace consumer law. It does not replace advertising law. Its purpose is to raise standards around protection, transparency and accountability.

Voluntary does not mean meaningless. Law and good practice are simply different things.

Implementation

Signatories were given six months from publication to implement the Code, with an implementation deadline of 20 May 2026. Operators joining after that date are expected to comply with the Code from the outset of becoming a signatory.

Code checked: 19 September 2026. This is a living source, and the signatory list has continued changing during 2026.

Player protection needs transaction level controls

The Code contains expectations around player protection. This is where Beaver's architecture becomes relevant, because the platform already has Live or Built controls for player set spending limits, operator spending caps, take a break, self exclusion, credit card controls, care flags, intervention workflow and marketing suppression.

No vague "fully compliant with the Code" claim. Instead: this provision maps to this Beaver control, and this is its current status.

The control mapping

This provision. This control. This status. This evidence.

A mapping of Code areas to Beaver controls, with the honest status of each. Individual clause references will be added once the final legal and compliance review has confirmed each mapping.

  • Requirement area

    Player spend controls

    Beaver control

    Player monthly cap and operator platform cap

    Status

    Live

    Evidence

    Checkout enforcement and audit state

  • Requirement area

    Self exclusion

    Beaver control

    Account exclusion that survives re registration

    Status

    Live

    Evidence

    Account state and audit record

  • Requirement area

    Temporary account suspension

    Beaver control

    Take a break state

    Status

    Live

    Evidence

    Account state. Exact duration mapping to be confirmed

  • Requirement area

    Marketing restrictions

    Beaver control

    Care flag suppression and closed account suppression

    Status

    Live

    Evidence

    Targeting eligibility. A suspension specific pathway is still to be evidenced

  • Requirement area

    Monitoring for potential harm

    Beaver control

    Behavioural signal rules

    Status

    Built

    Evidence

    Product tests, not yet live operator evidence

  • Requirement area

    Proportionate intervention

    Beaver control

    Review queue for flagged players

    Status

    Built

    Evidence

    Product tests, not yet live operator evidence

  • Requirement area

    Credit card monthly limit

    Beaver control

    Rolling 30 day credit card cap

    Status

    Built

    Evidence

    Product test, not yet live merchant evidence

  • Requirement area

    Credit cards on instant wins

    Beaver control

    Payment method filtered by product type

    Status

    Built

    Evidence

    Product test, not yet live merchant evidence

  • Requirement area

    Instant win portfolio share

    Beaver control

    Registry control exists but is not wired

    Status

    Not available

    Evidence

    None. We do not claim it

  • Requirement area

    Transparency of results

    Beaver control

    Committed entries, public randomness, public verifier

    Status

    Live

    Evidence

    Published draw record

If the rule is not wired, we do not colour the box green.

Transparency

Tell people how the promotion works. The Code is explicitly aimed at increasing transparency as well as player protection. Beaver's relevant capabilities include published odds, free entry presentation, public winner records, verifiable draws and audit evidence.

Transparency is more useful when the customer can inspect something.

Draw integrity

Live Beaver's draw engine commits the entry list, names future public randomness, refuses changed entries and allows public reproduction of the result.

See how Beaver verifies a draw

Credit cards

Beaver contains Built controls for rolling credit card spending and for blocking credit cards on instant win products. The payment architecture has not yet been validated against production merchant credentials.

Control logic: Built. Production evidence: not yet proven.

Instant wins

Live Beaver has sealed instant win allocation. However, the platform setting intended to cap instant wins as a proportion of the operator's portfolio is currently switch only, so we do not claim Beaver automatically enforces that provision today.

Evidence

Show what was active, not what the brochure promised. Beaver's Live Evidence Pack can produce a dated record of the controls active during a period: one of the practical ways an operator can retain evidence around its platform configuration.

Explore Compliance Evidence Packs

Primary sources

Where this page gets its facts

Checked 19 September 2026. Guidance changes; always read the current version at source.

From Code to control

Read the requirement. Configure the rule. Keep the evidence.