ROFUS: Why Denmark’s National Self-Exclusion Register Is the Template Every Regulator Copies

ROFUS, the Register Over Frivilligt Udelukkede Spillere (Register of Voluntarily Self-Excluded Players), has been the operational centrepiece of Danish online gambling regulation since Denmark liberalised its online gambling market in 2012. Spillemyndigheden, the Danish Gambling Authority, owns, operates, and maintains the register. Every licence holder providing online casino or sports betting services in Denmark must integrate with it via API, query it at account registration, and query it again at every single player login. No other player protection mechanism in the Danish framework touches every customer interaction in the same way. That architecture, regulator-hosted data, national digital-identity authentication, and mandatory real-time checks at the session level, is the reason regulators across Europe and North America have studied ROFUS as a reference model when designing their own national self-exclusion systems.

What ROFUS Actually Is

ROFUS is one of three core technical systems that Spillemyndigheden has built into the Danish online gambling infrastructure. The other two are the SAFE data storage system (the licence holder’s encrypted game-data repository to which Spillemyndigheden retains read access) and TamperToken (the integrity system that prevents stored game data from being altered). Together, these three systems form what Spillemyndigheden’s technical standards document, Tekniske Krav for Onlinekasino Og Væddemål V2.5, describes as the technical backbone of online gambling supervision in Denmark.

ROFUS covers players who have voluntarily chosen to exclude themselves, temporarily or permanently, from online casino games, online sports betting, and land-based casinos in Denmark. A player self-registers using MitID, Denmark’s national digital-identity system. The register sits entirely with Spillemyndigheden, not with any individual licence holder. A licence holder cannot register a player on that player’s behalf, and a licence holder cannot modify or delete a ROFUS entry.

Self-Exclusion Durations: What the Danish Framework Prescribes

Players registering in ROFUS may choose from the following durations, as set out in Spillemyndigheden’s guidance document Vejledning Om Væddemål Og Onlinekasino Version 7.0:

Duration Type	Period	Account Status
Spilpause (gaming break)	24 hours	Temporarily blocked, account not closed
Temporary exclusion	1 month, 3 months, or 6 months	Temporarily blocked, account not closed
Permanent exclusion	Indefinite	Account closed, new account earliest after 1 year

Spillemyndigheden’s Vejledning Om Ansvarligt Spil Version 1.4 (6 December 2022) specifies that a temporary self-exclusion must be a minimum of 30 days. An exclusion period of seven days, for example, would be in breach of the responsible gambling regulations. A licence holder may offer temporary exclusion periods longer than those listed above, and may offer supplementary tools such as daily session-time caps, but the minimum durations are set by regulation.

On permanent exclusion, the consequences are immediate. The gambling system must inform the player that all released funds will be paid out from the gambling account. The licence holder must initiate the payout procedure without delay. A new gambling account for the same player cannot be created until at least one year after the account closure.

What Does a ROFUS-Registered Player in Denmark Mean for a Licence Holder?

Two distinct operator obligations trigger when a player is in ROFUS. The first applies at account registration. Spillemyndigheden’s Certification Programme Inspection Standard SCP.02.03.EN.2.0, section 3.2.1, requires the gambling system to confirm that the customer is not registered in ROFUS as part of the account-opening process. If the player is listed, no gambling account can be created, not even a temporary one. The second obligation operates at every login. Vejledning Om Væddemål Og Onlinekasino Version 7.0 is explicit: every time a player logs into the gambling system, the system must consult ROFUS and verify that the player is not registered. If the player is registered, access must be denied.

“Each time a player logs into the gambling system, ROFUS must be consulted and it must be verified that the player is not registered in the register. If a player is registered in the register, the player must be denied access to log in.”, Spillemyndigheden, Vejledning Om Væddemål Og Onlinekasino Version 7.0, section 7.2.11.3.

This per-login check distinguishes ROFUS from systems that rely on periodic batch synchronisation. There is no grace period between a player self-registering in ROFUS and the block taking effect at a given licence holder’s platform. The system must block access on the next login attempt following registration.

The licence holder also carries a positive obligation regarding ROFUS visibility. Every function of the gambling system related to self-exclusion, whether temporary or permanent, must inform customers of the possibility of registering in ROFUS and must link directly to the register on Spillemyndigheden’s website. This requirement is embedded in SCP.02.03 section 3.3.1.10. The licence holder’s terms and conditions must also explain how a customer may self-exclude and set deposit limits, per SCP.02.03 section 3.1.1.10.

Why MitID Authentication Is the Critical Design Choice

The architecture of ROFUS is built on Denmark’s national digital-identity infrastructure. A player can only register in ROFUS using MitID, the successor to NemID. MitID is tied to a civil registration number (CPR number), the unique identifier assigned to all Danish residents. This binding to state-issued identity removes the most common evasion pathways that have afflicted operator-level self-exclusion systems elsewhere.

In jurisdictions relying on operator-managed exclusion lists, a self-excluded player who registers with a variant spelling of their surname, a different email address, or a fresh payment method can bypass the block. A 2019 investigation reported that UK players were circumventing exclusion through exactly these methods. ROFUS eliminates that pathway. Because the CPR number is the lookup key, not a name, email, or device identifier, a player’s self-exclusion status cannot be obscured through minor variations in registration data. Spillemyndigheden’s guidance also notes that licence holders offering online casino and sports betting must be vigilant about players who use another person’s CPR number or NemID credentials, and must design registration procedures that account for this risk. But the structural anchor remains the CPR-to-MitID link: within the ROFUS system, that link is government-authenticated and cannot be spoofed through an operator’s front end.

What Must the Gambling System Do Technically?

Tekniske Krav for Onlinekasino Og Væddemål V2.5 groups ROFUS alongside the SAFE and TamperToken systems as mandatory components of the technical infrastructure that licence holders must implement to obtain and maintain a licence. The document states that licence holders must develop their gambling systems to use the interfaces to Spillemyndigheden’s systems, and that it is a requirement to use the specified interfaces that Spillemyndigheden has developed for that purpose.

Access to a test environment is available to licence holders during both the application phase and during ongoing operations. Tekniske Krav V2.5 notes that Spillemyndigheden can provide test CPR numbers to licence holders for verifying ROFUS integration in the test environment. Any change to the procedures for customer login or customer registration triggers a notification obligation: the licence holder must notify Spillemyndigheden, and must have received Spillemyndigheden’s acceptance of the change before it takes effect.

The inspection standard SCP.02.03 further specifies that the deposit ceiling on temporary gambling accounts is DKK 10,000 (or the equivalent in another currency). Players on temporary accounts who have not yet completed full identity verification are thus subject to that hard deposit cap while also subject to ROFUS checks. The two controls operate in parallel.

How ROFUS Compares with Other National Self-Exclusion Registers

A growing cohort of national self-exclusion registers now exists across regulated gambling markets. Each draws on similar principles but differs in scope, identity infrastructure, and the degree of operator obligation it imposes.

Register	Jurisdiction	Identity Anchor	Hosted By	Check Trigger	Scope
ROFUS	Denmark	MitID / CPR number	Spillemyndigheden (regulator)	Registration + every login	Online casino, sports betting, land-based casinos
Spelpaus	Sweden	BankID / personnummer	Spelinspektionen (regulator)	Registration, login, pre-marketing (from Aug 2026)	All licensed online gambling
GAMSTOP	Great Britain	Name, DOB, email, postcode	GAMSTOP (third-party scheme, UKGC-mandated)	Registration, periodic re-check	All UKGC-licensed remote gambling
OASIS	Germany	Name, DOB, ID document	GGL (Joint Gambling Authority)	Registration + login	All licensed online gambling, land-based
Interdiction Volontaire	France	Identity document	ANJ (regulator)	Registration check mandatory for licensed operators	Licensed online gambling, land-based casinos
RGIAJ	Spain	DNI / NIE	DGOJ (regulator)	Via Player Verification Service at registration	All licensed online gambling, land-based
AGLC CSE	Alberta, Canada	Government-issued ID	AGLC (regulator)	Registration + login via API	iGaming and land-based casinos and racing venues

The comparison reveals consistent structural borrowing from the ROFUS model, alongside meaningful divergences. Sweden’s Spelpaus, established after the Spellag (2018:1138) gambling reform, is architecturally the closest equivalent. Like ROFUS, it is regulator-hosted, uses a national identity system (BankID and the Swedish personnummer), and mandates per-login API checks. Spelinspektionen’s regulation SIFS 2026:3, which enters into force on 1 August 2026, has formalised credential-based API access for Spelpaus queries, separating the marketing API from the login API and specifying exactly when a check is considered legally complete. For compliance officers managing Swedish licences, the Spelpaus API requirements under SIFS 2026:3 represent the most detailed national codification of what ROFUS operationalised earlier.

GAMSTOP, the UK’s multi-operator self-exclusion scheme, became mandatory for all UKGC-licensed remote gambling operators in March 2020. It differs from ROFUS in one structural respect: it relies on name, date of birth, email address, and postcode as its lookup keys, not a government-anchored identity number. That reliance means the identity-fraud vulnerability that ROFUS’s MitID anchor removes is not fully addressed. The UKGC has pursued a multi-layered mitigation approach rather than a single-point identity anchor, in part because the UK does not have a mandatory national identity card or an equivalent single-number civil registration system of the same universal coverage as Denmark’s CPR system.

Germany’s OASIS register, operated by the Gemeinsame Glücksspielbehörde der Länder (GGL), mirrors the ROFUS model in hosting the register at the regulatory level and requiring real-time checks at both registration and login for all licensed online operators. It extends to land-based venues, as does ROFUS. Spain’s RGIAJ, managed by the DGOJ, integrates directly with Spain’s Player Verification Service tool, which allows online operators to simultaneously verify a player’s national identity number (DNI or NIE), check RGIAJ status, and confirm the player is not a minor, in a single API call at registration. France’s ANJ Interdiction Volontaire imposes an obligation on licensed online operators to check that players are not registered before allowing gaming activity, consistent with the ROFUS logic.

Alberta’s AGLC Centralised Self-Exclusion (CSE) programme, which is a core requirement for all operators registering ahead of the July 2026 market launch, follows the ROFUS architecture explicitly on the key operational points. Per the AGLC’s Standards and Requirements for Internet Gaming (SRIG, dated 17 March 2026, section 3.4), all registered operators must maintain an effective API connection to AGLC’s centralised information system for prohibited persons. The iGaming platform must prevent any individual not cleared by AGLC’s centralised system from registering an account or from logging into an existing account. The AGLC system goes one step further than ROFUS in one respect: a player self-excluded through the CSE is blocked from both online iGaming and land-based casinos and racing entertainment centres, creating a genuinely cross-channel exclusion. ROFUS achieves a similar cross-channel effect for Denmark’s land-based casino sector, but the AGLC’s explicit three-option enrolment model (iGaming only, land-based only, or both) gives players granular control that the Danish system does not formally specify at the same level of detail.

AGLC will maintain a centralized list of prohibited persons… All registered Operators must have effective API connection to AGLC’s centralized information system. The iGaming site must have effective controls in place to prevent any individual not cleared by AGLC’s centralized system from registering an account or from logging into an existing account., AGLC SRIG, section 3.4 (17 March 2026).

Where the Danish Model Differs from Operator-Level Approaches

The fundamental policy choice behind ROFUS is the decision to place the register with the regulator rather than with individual operators or with an industry-funded third-party scheme. The consequences of that choice run throughout the compliance architecture.

An operator-level self-exclusion system, the model used under the MGA in Malta, by most US state regulators, and previously in markets that have since adopted national registers, means the exclusion operates only within the operator’s own brand or platform. A player self-excluding from one operator remains free to register with a competitor. The Malta Gaming Authority’s compliance audit framework requires licence holders to exclude a player from all their own brands when the player is classified as a problem gambler, and to retain self-exclusion records for the exclusion period plus six months. But it does not link Malta’s licensed operators to a shared national register in real time, because no such register exists within the Maltese framework. Similarly, the Curaçao Gaming Control Board’s Responsible Gaming Policy for Licensed Operators, adopted under the Landsverordening op de Kansspelen (LOK), requires operators to offer self-exclusion covering all brands and domains operated under their licence for a period of at least one year, but the mechanism remains operator-held rather than centrally hosted. For a wider view of how these models sit across different regulated jurisdictions, the Responsible Gambling Compliance hub maps the full landscape of national versus operator-level self-exclusion frameworks.

The regulator-hosted model creates a different accountability structure. Because Spillemyndigheden manages the ROFUS database, enforcement against a licence holder for failing to query ROFUS is a failure against an observable, auditable requirement. Spillemyndigheden can verify through its supervisory access to each operator’s SAFE data whether ROFUS queries are being made at the required points. That auditability is harder to achieve in a purely operator-held system where exclusion records exist across dozens of separate platforms with no central visibility.

What Operators Cannot Do Under the Danish Framework

Licence holder obligations around ROFUS are structured as much by what they cannot do as by what they must do.

A licence holder cannot register a player in ROFUS on that player’s behalf. Registration is strictly voluntary and initiated by the player. The licence holder’s role is to inform the player of the possibility of ROFUS registration, to provide a link to Spillemyndigheden’s website, and to block access when the player appears in the register. This design preserves the voluntary character of ROFUS while making evasion at the operator level structurally impossible once registration has occurred.

A licence holder cannot create a gambling account, including a temporary account, for a player who is registered in ROFUS. The block applies from the moment of registration confirmation: section 3.2.1.4 of SCP.02.03 states clearly that if the customer is confirmed as registered in ROFUS, no gambling account may be opened, not even a temporary one.

A licence holder cannot implement a higher deposit limit immediately upon customer request. While lowering a deposit limit takes effect immediately for all future gambling, a requested increase cannot come into effect until at least 24 hours later. This asymmetric implementation rule applies to the operator’s own deposit-limit system rather than to ROFUS directly, but it reflects the same design logic: friction is placed on actions that increase gambling exposure, not on those that reduce it.

The Minimum Exclusion Period Rule and Its Practical Implications

One underappreciated element of the Danish responsible gambling framework is the minimum temporary exclusion period of 30 days, set out in Spillemyndighedens Vejledning Om Ansvarligt Spil Version 1.4. An operator offering a seven-day temporary exclusion option would be in breach of the underlying regulations, specifically the ministerial orders on online væddemål and onlinekasino that took effect on 1 January 2020 and that were the direct regulatory output of the political agreement on new measures against gambling addiction signed on 29 June 2018.

The 24-hour spilpause (gaming break) available through ROFUS is treated as a distinct category from a temporary exclusion. The purpose of the gaming break is to give a player an immediate cooling-off without triggering the full consequences of a formal temporary exclusion. A licence holder may offer its own operator-level cooling-off periods of 24 hours without those being counted as formal self-exclusion periods under the regulatory definition. However, any period presented to the player as a temporary exclusion must be at least 30 days.

What Regulators Importing the ROFUS Architecture Should Note

The effectiveness of ROFUS rests on a precondition that not every jurisdiction can replicate easily: a universal, government-managed digital-identity system tied to a single civil registration number. Denmark’s CPR system, and MitID as its authentication layer, mean that self-exclusion entries in ROFUS are identity-anchored at the government level. Jurisdictions attempting to build equivalent systems without that infrastructure face the same identity-verification challenge that has limited the effectiveness of name- and email-based exclusion schemes.

Austria’s forthcoming iGaming liberalisation has explicitly targeted this requirement. According to iGaming Business reporting in June 2026, the Austrian framework under development includes a central self-exclusion register linked directly to Austrian digital-ID systems, with sign-up available through the regulator. That design follows the ROFUS playbook. The deposit-limit architecture being proposed for Austria, which includes differential limits for under-26s and over-26s, similarly echoes the player-segmentation logic that Danish responsible gambling regulation has embedded in the wider framework around ROFUS.

Brazil’s federal gambling regime under Lei 14.790/2023 (the Bets Act) has introduced a centralised self-exclusion framework via Portaria SPA/MF 2.579/2025. Brazilian regulators, as iGaming Business reported in June 2026, are also reviewing deposit limits and player risk assessments as part of the ongoing maturation of the regime. The trajectory is consistent with the ROFUS architectural logic, though Brazil’s federal structure and the absence of a single national digital-identity system equivalent to MitID create implementation complexity that Denmark did not face.

Compliance officers advising clients on multi-jurisdiction operations should note that the ROFUS-influenced architectures now in place or being built in Sweden, Germany, Spain, France, and Alberta share the per-login API check requirement as their operational core. The marketing-check extension formalised in SIFS 2026:3 for Sweden, requiring a Spelpaus query before any direct marketing is sent to a player, has not yet been codified in the same explicit terms in Denmark’s published technical requirements, but the principle that a ROFUS-registered player must not receive marketing is implicit in the obligation to deny access to registered players.

Operators holding Danish licences alongside licences in other national self-exclusion jurisdictions should treat each register as a separate API integration and should not assume that a player’s ROFUS status is visible to, or shared with, other regulators, or vice versa. Cross-register data sharing remains largely absent from the current frameworks, with each national register operating as a closed national database. Qualified legal counsel should be consulted on the interaction between national self-exclusion obligations and any cross-border marketing or CRM activity involving players registered in one or more national systems.

Key Resources

Spillemyndigheden, Vejledning Om Væddemål Og Onlinekasino Version 7.0, The primary operational guidance for online casino and sports betting licence holders in Denmark, including the full description of ROFUS obligations at sections 7.2.3.3 and 7.2.11.3.

Spillemyndigheden, SCP.02.03 Inspection Standards for Online Casino v2.0, The certification programme inspection standard governing gambling system requirements, including ROFUS checks at registration (section 3.2.1.4) and self-exclusion obligations (sections 3.3.1.5, 3.3.1.10).

Spillemyndigheden, Tekniske Krav for Onlinekasino Og Væddemål V2.5, The technical requirements document specifying ROFUS as one of three mandatory system integrations for licence holders, including test-environment access procedures.

Spillemyndighedens Vejledning Om Ansvarligt Spil Version 1.4 (6 December 2022), The responsible gambling guidance document setting out the minimum 30-day temporary exclusion period and describing ROFUS registration workflows, updated to include guidance on licence holder use of ROFUS registration data.

AGLC, Standards and Requirements for Internet Gaming (SRIG), 17 March 2026, Section 3.4 (Access Management: Prohibited Persons) and section 3.5 (Centralised Self-Exclusion), the Alberta equivalent of the ROFUS API integration requirement. Available at aglc.ca/igaming.