Skip to content
Spelinspektionen · Spelpaus 10 min read May 1, 2026

SIFS 2026:3: Spelinspektionen Formalises Spelpaus API Requirements for Swedish Licensees

SIFS 2026:3 establishes the binding technical and procedural framework Swedish licensees must follow when querying the Spelpaus national self-exclusion register, with all five provisions taking effect 1 August 2026.

Matt Denney

By

Founder, gamingcompliance.io · 15 yrs in iGaming compliance

Published May 1, 2026 10 min read Filed Responsible Gambling Compliance

Spelinspektionen’s formal regulatory collection, the Spelinspektionens Författningssamling (SIFS), carries the binding weight of Swedish gambling law. SIFS 2026:3, decided 23 April 2026 and published 29 April 2026, establishes the specific technical and procedural obligations that licensed operators must follow when querying the Spelpaus national self-exclusion register. The regulation enters into force on August 01,  2026, leaving a narrow implementation window in which licensees must complete system integration, credential management, and internal compliance review.  You can read more about the actual upcoming changes in our SGA Explorer.

For compliance officers and technical teams at Swedish-licensed operators, SIFS 2026:3 is not a policy statement or a conceptual update to self-exclusion obligations. It is a binding technical standard. Its five substantive provisions specify which API endpoints to use for each type of check, whose credentials must authenticate each query, when a check is considered legally complete, and precisely how the three defined trigger events map to system interactions. The regulation is compact, but each provision carries material compliance obligations that operators should not treat as interchangeable or optional.

Regulatory Authority and Scope

SIFS 2026:3 is made under the authority conferred by Chapter 16 §10 point 6 of Spelförordningen (2018:1475), the Swedish Gambling Regulation, which empowers Spelinspektionen to issue prescriptions implementing the provisions of Spellagen (2018:1138), the Gambling Act. The scope of SIFS 2026:3 is defined in §1: it applies to holders of a Swedish gambling licence who are required to register their players under Chapter 12 §1 of Spellagen. It governs how those licensees must interact with the national self-exclusion register established under Chapter 14 §12 of Spellagen.

This scoping provision is consequential. The obligation to register players under Chapter 12 §1 applies to mainstream licensed online casino and betting operators. Licensees uncertain whether their specific licence category triggers the Chapter 12 §1 registration requirement should verify their position directly with Spelinspektionen rather than applying a broad or assumed interpretation. The consequences of operating under a misunderstood scope assumption, in either direction, are material.

Scope check: SIFS 2026:3 applies to licensees required to register players under Chapter 12 §1 of Spellagen (2018:1138). Operators uncertain whether their licence category triggers this requirement should seek written clarification from Spelinspektionen before 1 August 2026 rather than proceeding on an unconfirmed assumption.

Three Trigger Events for Mandatory Checks

The operational core of SIFS 2026:3 is built around three defined trigger events, each requiring a mandatory query against the national self-exclusion register. These triggers are defined as kontroll (checks) in §2 second paragraph, point 3, with direct reference to the underlying statutory provisions in Spellagen and Spelförordningen.

The first trigger is direct marketing, governed by Chapter 15 §2 first paragraph of Spellagen. Before a licensee sends direct marketing communications to any individual, it must check that individual against the national self-exclusion register. The purpose is to prevent excluded players from receiving promotional communications that could undermine their self-imposed exclusion. Operationally, this means the register check must be embedded in the marketing dispatch workflow as a mandatory pre-send gate, not treated as a periodic batch reconciliation or a post-dispatch audit process.

The second trigger is player registration under Chapter 11 §9 first paragraph of Spelförordningen. When a new player attempts to register an account, a check must be performed before registration is completed. An excluded individual must not be registered as a new customer on any licensed platform.

The third trigger is player login under Chapter 11 §9 second paragraph of Spelförordningen. When an existing player attempts to log into the gaming system, a check must be performed. An excluded player must be blocked from accessing the gaming environment on every login attempt, not merely at the point of initial account creation or onboarding.

The three-trigger structure reflects a layered approach: exclusion status is verified at acquisition (registration), at every point of engagement (login), and ahead of every direct marketing communication. None of the three checks is optional or contingent on the others.

These three trigger events are not new obligations created by SIFS 2026:3. The underlying requirements derive from Spellagen and Spelförordningen directly. What SIFS 2026:3 adds is the binding technical framework for how these checks must be conducted: the API architecture, the credential requirements, and the completeness standard that determines when a check has been legally performed.

API Segregation: Marketing Versus Login Endpoints

One of the operationally significant provisions in SIFS 2026:3 is the mandatory separation of API endpoints for different check types, established in §5. The regulation provides that checks must be performed against the API that corresponds to the purpose of the check. Specifically, SIFS 2026:3 §5 provides two rules.

First, a marketing check as defined under §2 second paragraph 3(a) may only be performed against the APIs designated for marketing purposes. Second, a registration or login check as defined under §2 second paragraph 3(b) and 3(c) may only be performed against the API designated for login purposes.

This is a restrictive construction. The Swedish får endast used in §5 means “may only,” and the provision prohibits cross-use of the two endpoint categories. Using the login API for a marketing check, or the marketing API for a registration or login check, is non-compliant with SIFS 2026:3 §5 as written, regardless of whether the technical outcome of the check would have been identical.

The practical implication for technical integration teams is clear but operationally demanding: the Spelpaus integration cannot be a single unified API call route applied to all three trigger events. The system architecture must route each check type to its designated endpoint, which may mean maintaining separate integration logic in marketing dispatch systems, player registration flows, and login authentication flows respectively. Teams that have built or are planning a single-endpoint integration on the assumption that Spelpaus provides one unified API for all check types need to revisit that architecture before the August 2026 deadline.

Architecture review required: Under SIFS 2026:3 §5, marketing checks and registration/login checks must use separate designated API endpoints. A single unified Spelpaus API call serving all three trigger types is non-compliant. Technical teams should audit routing logic across marketing, registration, and login systems separately.

Credential Accountability and the Delegation Provision

SIFS 2026:3 §4 addresses the credential requirements for performing checks and makes a substantive clarification about third-party delegation that carries direct implications for operators using managed platform services or white-label suppliers.

The regulation provides that each check must be authenticated using the anslutningsuppgifter (connection credentials) assigned to the licensee by Spelinspektionen. These credentials consist of a unique Actor ID and an API Key issued to each individual licensee. The credentials are per-licensee, not per-system or per-platform.

The delegation provision in §4 is direct: if a licensee commissions another party to perform the check on its behalf, the commissioning licensee’s own connection credentials must still be used in that check. The credentials follow the regulated obligation, not the technical executor.

This has significant implications for operators who have outsourced elements of their platform or compliance infrastructure to managed service providers, platform operators, white-label technical suppliers, or shared services arrangements. In those structures, a third party may be operating the technical systems and executing the API calls against Spelpaus. Under SIFS 2026:3 §4, that third party must use the commissioning licensee’s Actor ID and API Key, not a generic or shared credential belonging to the service provider or used across multiple client licensees.

Compliance officers at operators using third-party platform providers should verify, in writing, that those providers are configured to use per-licensee credentials as required and are not operating with shared or supplier-level credentials. This confirmation should be documented as part of the operator’s compliance record. Outsourcing the technical execution of a Spelpaus check to a third party transfers no part of the regulatory responsibility to that third party. Spelinspektionen will hold the licensee accountable for any non-compliance, including failures that occur within a supplier’s system when that system is executing checks on the licensee’s behalf.

The Completeness Standard: When a Check Is Legally Done

SIFS 2026:3 §3 establishes the standard for when a check is considered legally completed. A check is complete when it has shown whether the person is excluded from gambling or not. This is a definitiveness requirement, not a dispatch requirement.

A check is not legally complete under §3 upon submission of the API request. It is complete only when the licensee’s system has received and processed a definitive answer on the individual’s exclusion status. API timeout responses, error codes, partial responses, or inconclusive returns do not satisfy the §3 completeness standard.

Operators must therefore design their integration error-handling logic so that ambiguous, incomplete, or failed API responses trigger an appropriate hold or rejection at the relevant trigger point, rather than a default-permit pathway. This requirement has particular operational relevance for login checks, where user experience and latency considerations can create engineering pressure to pass players through on non-definitive API responses. SIFS 2026:3 §3 does not permit that approach. The integration must return a definitive exclusion status result before a player is permitted to proceed through any of the three trigger events.

A check is complete when it has definitively shown whether the person is excluded, not when the API call has been dispatched. Engineering teams must treat non-definitive API responses as incomplete checks, not as permission to proceed.

What SIFS 2026:3 Does Not Specify

A precise assessment of SIFS 2026:3 requires acknowledging what the regulation does not provide, and this gap is material for operators planning their technical implementation. The regulation establishes the obligation to query Spelpaus at defined trigger points, using designated credentials and endpoints, with a definitiveness standard for completion. It does not, within its own text, specify the technical API specifications, the response data schema, performance requirements or latency thresholds, retry and fallback protocols, or version management rules for the Spelpaus API.

These specifications are not found in SIFS 2026:3. Technical integration documentation for the Spelpaus API is published separately from the formal regulatory text, through Spelinspektionen’s technical guidance channels and the Spelpaus operator portal. According to reporting by iGaming Business (29 April 2026), the regulation establishes the technical framework but does not yet specify detailed API specifications, response formats, or performance standards, and operators require that supplementary documentation to complete their integration planning.

Compliance officers should ensure their technical teams have obtained the current Spelpaus integration documentation directly from Spelinspektionen or through the official operator portal, and are monitoring for updates to that documentation ahead of the 1 August 2026 deadline. Relying on the text of SIFS 2026:3 alone as a technical integration guide leaves material gaps that could result in non-compliant or incomplete implementations.

Practical Compliance Priorities Before 1 August 2026

The following areas represent the core compliance priorities that emerge directly from the provisions of SIFS 2026:3 and that operators should address within the available implementation window.

Operators should confirm receipt of their Spelinspektionen-issued Actor ID and API Key, and verify that these credentials are correctly provisioned in their gaming system and, where applicable, in any third-party platform provider’s integration. Credential management under §4 is a non-delegable obligation. If credentials have not been issued or cannot be located, operators should contact Spelinspektionen promptly given the August 2026 deadline.

Technical teams should audit the API routing logic for all three trigger events against the §5 endpoint segregation requirement. Marketing dispatch systems, player registration flows, and login authentication flows each need to route to their designated API endpoint. This may require separate integration work streams for each system rather than a single central implementation.

The error-handling and fallback logic for API calls should be reviewed against the §3 completeness standard. Any code path that permits a user to proceed through a trigger event on the basis of a non-definitive API response needs to be corrected before August 2026. A block-on-non-definitive-response policy, with appropriate audit logging, represents the most defensible implementation approach.

Operators using third-party platform, managed services, or white-label suppliers should obtain written confirmation from those suppliers that the Spelpaus integration is configured to use per-licensee credentials as required by §4, and that the supplier has implemented the API endpoint segregation required by §5. This written confirmation should be retained as compliance documentation, given the licensee’s continuing accountability for third-party failures under the delegation framework.

Operators with unresolved questions about the application of SIFS 2026:3 to their specific licence category, integration architecture, or third-party arrangements should seek qualified legal counsel with expertise in Swedish gambling law. Spelinspektionen is accessible for formal regulatory enquiries, but the consequences of any compliance failure attach to the licensee directly, and legal advice should reflect that accountability structure.

Key Resources

SIFS 2026:3: Spelinspektionens föreskrifter om det nationella självavstängningsregistret. Decided 23 April 2026, published 29 April 2026, effective 1 August 2026. Published in the SIFS collection at spelinspektionen.se.

Spellagen (2018:1138): The Swedish Gambling Act. Relevant provisions: Chapter 12 §1 (player registration obligations), Chapter 14 §12 (national self-exclusion register), Chapter 15 §2 (direct marketing). Available at riksdagen.se.

Spelförordningen (2018:1475): The Swedish Gambling Regulation. Relevant provision: Chapter 11 §9 (registration and login check obligations). Available at riksdagen.se.

Spelpaus operator integration documentation: Technical API specifications for Spelpaus are published separately from the regulatory text and are not contained within SIFS 2026:3. Operators should obtain the current version through their Spelinspektionen operator portal access or by direct contact with Spelinspektionen ahead of the 1 August 2026 implementation deadline.

Matt Denney

Matt Denney

Editorial · gamingcompliance.io

Reads the primary source so you don't have to. Fifteen years inside iGaming compliance: operator, supplier, and crown-corporation lottery.

Related coverage · also tagged Responsible Gambling Compliance

Browse all →

Responsible Gambling Compliance

MGA Player Protection Directive: Deposit Limits, Reality Checks, and Disclosure Requirements Under Directive 2 of 2018

May 4 · 10 min read

Responsible Gambling Compliance

Single Customer View: Building One Across Brands Without Breaching GDPR

May 3 · 12 min read

Responsible Gambling Compliance

Cross-Operator Self-Exclusion: Comparing GAMSTOP, ROFUS, Spelpaus, and OASIS Across Jurisdictions

May 2 · 11 min read

The Tuesday brief, every week.

One email. Every regulator change we surface, every standard we re-index, every enforcement decision we read. No marketing, no fluff.

Unsubscribe with one click. We'll never share your address.