Spelpaus Integration in Practice: Architecture Requirements, Enforcement Risk, and the Failure Modes Regulators Find

Chapter 12 §4 of Spellagen (SFS 2018:1138) is unequivocal: gambling may not commence until the licensee has verified that the player has not excluded themselves under Chapter 14 §§12 or 13. That statutory prohibition has been in force since 1 January 2019. What changed with SIFS 2026:3, decided 23 April 2026 and in force 1 August 2026, is that Spelinspektionen has now prescribed exactly how that verification must be performed at the technical level. The gap between the obligation and the standard was, for years, a space in which integration approaches varied. From 1 August 2026, that variation is a compliance breach.

This article addresses what licensees and their technical teams need to understand about the integration architecture, where implementations commonly fail, and what enforcement exposure follows when they do. Compliance officers who have already read the SIFS 2026:3 text will find more value here in the operational failure analysis and the penalty framework than in a restatement of what the regulation says.

The Statutory Architecture Beneath Spelpaus

Spelpaus is established under Chapter 14 §12 of Spellagen as the national self-exclusion register. Any individual who registers with Spelpaus is excluded from all gambling with all licensees subject to the player-registration requirement in Chapter 12 §1. The register is operated by Spelinspektionen itself, not by a third party, which gives it a different character from operator-level self-exclusion systems used in jurisdictions such as Malta (MGA), Curaçao (GCB), and most US state markets.

The pre-gaming check in Chapter 12 §4 creates a hard gate: no gambling activity may begin without a verified non-exclusion result. The same chapter specifies that identification of the player must precede this check, meaning the player’s identity must be established before the Spelpaus query can be meaningfully executed. This sequencing matters operationally. A licensee whose login flow performs the identity check and the Spelpaus query in parallel, rather than sequentially, has not met the Chapter 12 §4 requirement, because the query cannot be attributed to a verified identity until identification is complete.

“Gambling may not commence until the license holder has verified that the player has not excluded themselves pursuant to Chapter 14, §§ 12 or 13.”, Spellagen (SFS 2018:1138), Chapter 12 §4

The marketing check obligation derives from Chapter 15 §2 of Spellagen, which requires that direct marketing communications not be sent to excluded players. SIFS 2026:3 operationalises both obligations by specifying the API infrastructure through which these checks must be performed.

What SIFS 2026:3 Adds: The Technical Prescription

Before SIFS 2026:3, the statutory obligation to check Spelpaus existed but the technical method was not prescribed in binding secondary legislation. SIFS 2026:3 fills that gap across five provisions, and each creates a distinct compliance obligation rather than restating existing law.

Spelinspektionen issues each licensee a unique Actor ID and an API Key. These credentials are per-licensee, not per-platform or per-product. §4 of SIFS 2026:3 provides that where a licensee commissions another party to perform checks on its behalf, that commissioned party must use the commissioning licensee’s own credentials. The credentials follow the regulated obligation, not the technical executor.

§5 mandates that the API endpoint used for a check must correspond to the purpose of that check. Marketing checks must be performed against the marketing API. Login and registration checks must be performed against the login API. The Swedish construction in §5 uses får endast, meaning “may only.” Cross-routing, using the login API for a marketing check or vice versa, is expressly prohibited, regardless of whether the technical result of the query would have been identical.

§3 defines when a check is considered legally complete: when it has definitively confirmed, one way or another, whether the individual is excluded. A query that times out, returns an indeterminate result, or is not executed at all does not satisfy §3.

What Happens When the Spelpaus API Times Out?

§3 of SIFS 2026:3 defines a legally complete check as one that has returned a definitive result. A system configured to allow the player through when the Spelpaus API returns an error or does not respond within the timeout window has not produced a legally complete check. Allowing gambling to commence on the basis of an incomplete check is a breach of Chapter 12 §4 of Spellagen, regardless of whether the player would ultimately have been found to be non-excluded.

The only approach consistent with §3 is to treat any non-definitive API response as a blocking result for login and registration purposes. For marketing checks, the same logic applies: a communications batch that was partially screened because of intermittent API availability is not a compliant screening process for the affected records. Integration teams should implement circuit-breaker logic that holds login or registration in a pending state during API unavailability and alerts operations teams immediately, rather than failing open. Monitoring for Spelpaus API response rates and alert thresholds must be treated as compliance infrastructure, not merely operational infrastructure.

Common Failure Mode One: Shared Credentials Across a Platform

The most structurally prevalent failure mode in Sweden’s market is the use of shared or platform-level credentials to service multiple licensee accounts. This pattern is common in white-label arrangements and managed-platform models where a single technical provider operates the gaming system for several licensed operators. In those architectures, a provider may have integrated against Spelpaus once using a single set of API credentials and routed all tenant-operator queries through that single integration.

SIFS 2026:3 §4 makes this architecture non-compliant from 1 August 2026. Each licensee must have its own Actor ID and API Key. A check performed using the credentials of a different licensee, or of the platform provider itself, is not a check made by the commissioning licensee as required by the regulation. Every white-label licensee must verify, in writing, that its platform provider has provisioned separate credentials per licensee and has reconfigured its integration accordingly.

The obligation to demonstrate compliance rests with the licensee, not with its supplier. Audit evidence showing that the correct per-licensee credentials were in active use at the time of any given check will be the expected form of documentary support in a supervisory review.

Common Failure Mode Two: Endpoint Mis-Routing

The endpoint segregation requirement in §5 is operationally non-obvious because the two API categories return functionally equivalent data: whether a given individual is excluded. The distinction between the marketing endpoint and the login endpoint exists for regulatory architecture reasons, not for reasons of technical output. A licensee whose integration team routes all checks through a single endpoint, on the basis that the response is the same either way, is in breach of §5.

The failure mode typically occurs where a marketing function has been bolted onto an existing login integration rather than built separately. In systems where player communications are generated by the same engine that handles login state, there may be a technical temptation to reuse the login API call to pre-screen marketing recipients. SIFS 2026:3 §5 prohibits that approach explicitly.

The reverse error also occurs: licensees who have built a dedicated marketing-check integration and then apply it to their login flow to simplify their architecture are equally non-compliant, because §5’s restriction runs in both directions. Compliance teams reviewing their integration configuration should confirm with their technical teams which endpoint is called at each of the three trigger events and verify that the mapping matches the regulatory specification.

Common Failure Mode Three: The Marketing Workflow Gap

The pre-marketing check obligation under Chapter 15 §2 of Spellagen, operationalised through SIFS 2026:3, is frequently implemented incompletely. The most common pattern is a licensee that screens its registered player base against Spelpaus at the point of account registration and at login, but applies only periodic bulk reconciliation rather than a per-campaign check before direct marketing is dispatched.

A player may register Spelpaus exclusion after their most recent login to a licensed platform. If the licensee’s marketing system relies on a cached exclusion status derived from the last login check, that cached status may be stale at the time of sending. The Chapter 15 §2 obligation is not satisfied by a login check that was accurate at the time it was made, the obligation requires that the check has been made in the context of the specific marketing dispatch.

The SIFS 2026:3 framework addresses this by requiring that the marketing-purpose API be used for marketing checks specifically. That technical separation is also a process separation: the marketing workflow must have its own Spelpaus check embedded, independent of the login workflow. Licensees whose CRM or marketing automation platforms are not configured to call the Spelpaus marketing API before each outbound campaign have not met the standard.

Cached exclusion status derived from a login check is not a substitute for a purpose-specific marketing check under SIFS 2026:3 §5.

Enforcement Exposure: How Spelinspektionen Calculates Penalties

Since market re-regulation on 1 January 2019, Spelinspektionen has issued 97 supervisory decisions against licensed operators, according to the ICLG Gambling Laws and Regulations Report 2026 for Sweden. The Gambling Act provides Spelinspektionen with a tiered enforcement toolkit: remarks, warnings, conditions, and financial penalty fees. Only one licence has been revoked for regulatory non-compliance.

The financial penalty framework changed materially following a judgment of the Swedish Supreme Administrative Court (Högsta förvaltningsdomstolen) on 9 May 2023. The court ruled that penalty fees must be calculated on the basis of gross gaming revenue rather than gross turnover, as had previously been applied by Spelinspektionen and lower administrative courts. The practical effect is that GGR-based penalties are proportionate to profitability rather than to wagering volume, and documented fees have reached 100 million SEK (approximately €9.7 million) in the highest cases to date, according to the ICLG Gambling Laws and Regulations Report 2026 for Sweden.

Spelpaus integration failures fall within the class of violations that attract financial penalties, not merely administrative remarks. A licensee that allows an excluded player to gamble has breached Chapter 12 §4 of Spellagen. The number of affected sessions, the duration of the breach, and the licensee’s GGR form the calculation basis. Where the breach involves systematic failures, for instance where a shared-credential or mis-routed endpoint architecture has been in place across many players over an extended period, the aggregated violation size will be substantially larger than in an isolated incident.

How Spelpaus Compares as a Technical Model

Understanding how Spelpaus sits relative to other national self-exclusion registers helps compliance teams assess why its integration requirements are architecturally more demanding in certain respects than those of comparator systems.

Register	Jurisdiction / Regulator	Model	Operator API Mandate	Check Triggers
Spelpaus	Sweden / Spelinspektionen	Centralised, regulator-operated	Yes, per-licensee credentials, dual endpoint (SIFS 2026:3)	Registration, login, direct marketing
GAMSTOP	Great Britain / UKGC	Centralised, third-party operated	Yes, mandatory participation (LCCP)	Registration and login, marketing covered separately under LCCP
ROFUS	Denmark / Spillemyndigheden	Centralised, regulator-operated	Yes, integration required under SCP.02.03 inspection standards	Registration, login, ROFUS link mandatory in UI
OASIS	Germany / Gemeinsame Glücksspielbehörde der Länder	Centralised, cross-state	Yes, real-time check before account access	Registration and login, approaching 350,000 registrations
CRUKS	Netherlands / KSA	Centralised, government-operated	Yes, pre-play check mandatory under KOA	Registration and login

Spelpaus’s distinguishing technical features under the post-SIFS 2026:3 framework are the mandatory endpoint segregation by check purpose and the per-licensee credential requirement. GAMSTOP, ROFUS, OASIS, and CRUKS each impose mandatory API integration, but none prescribes the same combination of purpose-segregated endpoints and per-licensee authentication at the level of binding secondary legislation. SIFS 2026:3 is, in that respect, among the most technically specific self-exclusion integration standards in European online gambling regulation.

For licensees already integrated with GAMSTOP or ROFUS, the additional layer in Sweden is the marketing-specific endpoint obligation. GAMSTOP’s integration framework addresses the marketing channel through the UKGC’s Licence Conditions and Codes of Practice rather than through the technical integration standard itself. In Sweden, the marketing check is woven into the same API framework and the same regulatory instrument as the login check, making it a single point of technical compliance that must be configured correctly rather than two separate obligations managed through different governance channels. Compliance officers maintaining multi-jurisdiction responsible gambling frameworks will find a detailed comparison of player-protection architectures across seventeen regulated markets in the Responsible Gambling Observatory.

France’s Interdiction Volontaire register, operated by ANJ, follows a similar principle of pre-check obligations before marketing dispatch, though the technical implementation standard differs. Licensees active across multiple European regulated markets should ensure their architecture can accommodate jurisdiction-specific endpoint configurations rather than implementing a single unified self-exclusion check layer that may be non-compliant in one or more jurisdictions.

Third-Party and Outsourced Platform Risk

SIFS 2026:3 §4 creates a specific compliance risk for licensees operating through shared or managed technical infrastructure. The provision states that where the licensee commissions another party to carry out checks, the commissioned party must use the commissioning licensee’s own Actor ID and API Key. The regulatory intention is clear: Spelinspektionen must be able to identify, from the audit trail of API queries, which licensed entity made each check.

In a white-label architecture, a single platform provider may host dozens of licensed operators. Each of those operators has its own Spelinspektionen licence and its own Chapter 12 §4 obligation. The platform provider cannot satisfy all of those obligations using a single shared integration. It must either maintain per-tenant credential routing, where each query uses the credentials issued to the tenant licensee, or demonstrate that each licensee has implemented a separate integration that happens to be executed through shared infrastructure with proper credential isolation.

Compliance officers should conduct contractual and technical due diligence on this point before 1 August 2026. The due diligence should produce written confirmation from the platform provider specifying which Actor ID is used for queries attributed to each licensee, and evidence that the routing configuration has been tested and verified. Without that evidence, the licensee cannot demonstrate compliance if Spelinspektionen initiates a supervisory review.

The same risk applies to licensees that have outsourced their CRM or marketing automation function to a third-party provider. If that provider dispatches marketing communications on the licensee’s behalf, the provider must use the licensee’s Actor ID and the marketing API when screening recipients. A third-party marketing provider operating its own Spelpaus integration and applying its own credentials is not a compliant arrangement under SIFS 2026:3 §4.

The Omsorgsplikt Nexus

Spelpaus integration failures do not occur in isolation from the broader Swedish responsible gambling framework. Chapter 14 §1 of Spellagen requires licensees to protect players from excessive gambling, and Spelinspektionen’s Omsorgsplikt Vägledning (duty-of-care guidance) operationalises this as a continuous monitoring obligation. Under the duty-of-care framework, allowing an excluded player to access gambling is not only a breach of Chapter 12 §4 and the Spelpaus-specific provisions, it is also a breach of the underlying omsorgsplikt, because the player has, by self-excluding, given the licensee the clearest possible signal of harm risk.

Spelinspektionen’s omsorgsplikt guidance identifies previous self-exclusions as a risk factor for excessive gambling, and states that players who have previously self-excluded with a licensee should be followed up with particular care. A licensee that has allowed an excluded player back into its system through a Spelpaus check failure may compound the regulatory exposure by also demonstrating inadequate risk monitoring under the omsorgsplikt framework. Supervisory decisions in Sweden have addressed responsible gambling failures under multiple concurrent provisions, and Spelpaus integration failures are among the categories most likely to trigger multi-provision analysis.

The 22 percent GGR tax on the Swedish market applies to the same revenue base that underpins the penalty fee calculation. A Spelpaus integration failure that generates revenue from excluded players will result in a tax liability on that revenue and potential penalty exposure calculated on the same GGR figure, along with any restitution obligations.

A Spelpaus integration failure is simultaneously a breach of Chapter 12 §4, a potential omsorgsplikt violation, and a basis for GGR-based financial penalties that have reached 100 million SEK in documented cases.

Implementation Checklist for the 1 August 2026 Deadline

The following represents the minimum verification steps a licensee’s compliance and technical teams should complete before the SIFS 2026:3 in-force date. Licensees should obtain qualified legal advice on jurisdiction-specific application before finalising their compliance position.

Credential provisioning: Confirm that Spelinspektionen has issued a unique Actor ID and API Key for the specific licence, and that those credentials are in active use in the production integration. Where platform providers execute queries, obtain written confirmation specifying which Actor ID is used per licensee.

Endpoint routing audit: Map all three trigger events (registration, login, direct marketing) to their respective API endpoint categories. Confirm that the marketing-purpose endpoint is not used for login checks and that the login-purpose endpoint is not used for marketing checks. Document the configuration and test results.

Failure-state behaviour: Review the system’s response to API timeouts and error states. Confirm that the default in failure states is to block the transaction or marketing dispatch, not to permit it. Monitoring and alerting for API availability must be configured as a compliance control.

Sequencing verification: Confirm that the Spelpaus check at login follows identity verification rather than running in parallel with it. The Chapter 12 §4 obligation requires the check to be against a verified identity.

Third-party arrangements: Review all contracts with platform providers, CRM suppliers, and marketing automation vendors for Spelpaus integration obligations. Ensure those agreements specify per-licensee credential use and the correct endpoint for each check type.

Licensees with multiple Swedish-licensed brands operating under a single corporate platform should treat each licence as requiring a separate configuration review. The SIFS 2026:3 credential and endpoint obligations apply at the licence level, not at the group level.

For a broader view of how Spelpaus sits within Sweden’s overall responsible gambling regulatory architecture, including deposit limits, the omsorgsplikt framework, and the channelisation dynamics that shape the market context, see the analysis of Spelinspektionen’s channelisation challenges and the Responsible Gambling Compliance hub, which covers national self-exclusion register models across seventeen regulated jurisdictions.

Key Resources

SIFS 2026:3, Spelinspektionens föreskrifter om det nationella självavstängningsregistret (in force 1 August 2026): spelinspektionen.se

Spellagen, Gambling Act (SFS 2018:1138), consolidated version SFS 2024:255, Ministry of Finance: riksdagen.se

Spelinspektionen supervisory decisions, full list of post-2019 decisions: spelinspektionen.se/vara-beslut/beslutslista

Omsorgsplikt Vägledning, Spelinspektionen duty-of-care guidance implementing Chapter 14 of Spellagen: available on spelinspektionen.se under föreskrifter och vägledning.