Sweden's new Spelpaus rule defines when a self-exclusion check actually counts

Sweden's new Spelpaus regulation turns a technical exchange into a legal control. A licensee must use its assigned credentials, call the API that matches the reason for checking and receive an answer that shows whether the person is self-excluded. Sending a request into a timeout does not satisfy that final condition.

The rule sounds narrow because it is narrow. It does not redesign self-exclusion or set a new exclusion duration. It defines how operators must connect to the national register and when they can say the check occurred.

A national register can expose different interfaces for different moments or purposes. Using an endpoint that does not correspond to the required check risks producing the wrong answer, an incomplete record or no legally useful result at all. SIFS 2026:3 removes room for an operator to treat any contact with the system as compliance.

Unique credentials matter for attribution. They help connect a request to the licensed business responsible for it and support logs that can be reviewed after a dispute or incident.

Spelinspektionen says the check is completed when it has shown whether the person is excluded. That frames the control around an outcome, not a button click. An operator that cannot obtain a result still has a player-protection problem to manage.

The public summary does not say exactly how long to retry, when to fail closed or what evidence format must be retained. Those operational questions may be answered by technical documentation or future supervision. Atlas will not invent them.

Correct register access can prevent an excluded person from passing a check under the identity presented. It cannot by itself detect a different identity, a stolen account or every form of duplicate registration. KYC, session controls and account monitoring remain separate layers.

Nor does one successful response guarantee later compliance. The relevant check may need to occur at more than one customer-journey point under the wider law. This story addresses only the new API rule.

Engineers may own the integration, but compliance needs to define the legal event, operations need a safe fallback and audit teams need logs that prove what happened. A silent change to credentials or endpoint routing can therefore become a licence risk.

Boards do not need to inspect code. They do need assurance that the system fails safely, incidents are escalated and fixes can be reconstructed from records.

That assurance should cover vendors too. If a third party manages identity or registration flows, the licensee still needs visibility over Spelpaus requests, responses and outages. An outsourcing contract cannot turn an incomplete register result into a completed legal check.

No sanction under SIFS 2026:3 appears in the announcement. The first decision could show whether the regulator focuses on an isolated technical error, the operator's fallback response or a wider pattern of admitting excluded players.

Until then, the rule's practical message is already clear. A self-exclusion check counts when the authorised system returns the person's exclusion status through the correct channel.

Many responsible-gambling promises are hard to test from outside. This one is unusually concrete: the operator used its credentials, selected the right API and obtained a status response. That sequence can be logged and audited.

The limitation is equally concrete. A clean log proves the register interaction, not the effectiveness of every subsequent action. Atlas will keep those two claims separate when enforcement begins.