If you hold a UKGC licence, you must check every player against GAMSTOP before they register or log in. If you hold a Swedish licence, you must check every player against Spelpaus. These are not recommendations. They are legal obligations — and failing to enforce them puts your licence at risk.
Most platform vendors acknowledge this, add an integration, and move on. But the difference between "we have a GAMSTOP integration" and "we guarantee no excluded player will ever complete a session" is significant. The first is a feature. The second is an architecture.
PAM treats exclusion registry integration as infrastructure. Not a plugin. Not an optional module. A set of automated, auditable checks that run at registration, at login, and in daily batch — with no manual step required from the operator.
What GAMSTOP and Spelpaus are
GAMSTOP is the UK's national online self-exclusion scheme. When a person registers with GAMSTOP, they choose an exclusion period — six months, one year, or five years. During that period, every UKGC-licensed online operator is required to prevent that person from gambling. The obligation sits with the operator, not the player. If a self-excluded person manages to create an account and place bets, the regulatory failure belongs to the operator.
Spelpaus is Sweden's equivalent, operated by Spelinspektionen (the Swedish Gambling Authority). Any person can register on Spelpaus to exclude themselves from all licensed gambling in Sweden. The exclusion is immediate and applies across every operator holding a Swedish licence. Unlike GAMSTOP's fixed periods, Spelpaus allows indefinite exclusion with a minimum period of one month.
Both registries expose APIs that operators must integrate with. The technical integration is straightforward — the challenge is making sure the checks are comprehensive, timely, and impossible to bypass. A player who self-excludes at 2pm must not be able to continue playing at 2:01pm. A player who self-excluded last night must not be able to log in this morning. A player on the exclusion list must never receive a marketing email inviting them back.
Non-compliance is not theoretical. The UKGC has issued significant fines to operators who allowed self-excluded players to gamble. In several cases, the technical integration existed but had gaps — batch checks that ran too infrequently, login paths that skipped the check, or marketing systems that operated independently of the exclusion data.
Daily batch sync
PAM runs scheduled tasks that check the entire active player base against the exclusion registry every day. For GAMSTOP, this is the DailyUkBatchCheckTask. For Spelpaus, the equivalent batch process runs on the same schedule. The logic is the same: take every active player in the relevant jurisdiction, submit their details to the registry API, and process the results.
When the batch check identifies a player who has self-excluded since the last run, the response is immediate and automated. The player's account is blocked. Active sessions are terminated. Any pending withdrawals are processed (the player is entitled to their funds), but no further deposits or gameplay are permitted. The blocking action is logged with a full audit trail — when the check ran, what the registry returned, and what actions were taken.
The batch check is not a substitute for real-time validation. It is a safety net. If a player self-excludes at 11pm and the real-time check at login somehow fails, the batch check at 6am will catch it. Defence in depth — the same principle that drives every serious compliance architecture.
The batch also serves a second purpose: detecting players who were already on the platform before they self-excluded. A player might have registered and played for months before deciding to self-exclude through the national registry. The daily batch ensures that the exclusion is enforced retroactively, without requiring the player to contact the operator separately.
Login-time validation
The daily batch runs once every 24 hours. That leaves a window. If a player self-excludes at 2pm and the batch ran at 6am, the player could theoretically log in and play for 16 hours before the next batch catches them. That window is unacceptable.
PAM validates against the exclusion registry at login. Every login attempt for a player in a GAMSTOP or Spelpaus jurisdiction triggers a real-time API call to the registry. If the player is on the list, the login is rejected. There is no grace period, no "check later" flag, no queued validation. The check is synchronous — the player cannot enter the platform until the registry confirms they are not excluded.
This means a player who self-excludes at 2pm is blocked by 2:01pm — not the next day's batch run. The login-time check and the daily batch are complementary. The login check handles the real-time case. The batch handles edge cases: players with active sessions at the time of exclusion, players who registered through a path that somehow bypassed the login check, or registry API outages that caused a login check to fail.
A UKGC-licensed operator allows a GAMSTOP-registered player to deposit and play for three days because the batch check runs weekly instead of daily, and the login-time check was not implemented. The player loses funds during that period. The operator faces a regulatory investigation, a potential fine, an obligation to return the player's losses, and reputational damage in licence review. The cost of the missing check dwarfs the cost of implementing it. Regulators do not accept "we checked, just not often enough" as a defence.
Affiliate marketing compliance
Exclusion registries do not only govern who can play. They govern who can be marketed to. Sending a promotional email, an SMS, or a push notification to a self-excluded player is a regulatory violation. It is also, from a responsible gaming perspective, exactly the wrong thing to do — contacting someone who has actively chosen to stop gambling and inviting them to gamble.
PAM integrates exclusion registry checks into the marketing workflow. Before any marketing communication is sent to a player list, PAM runs a BatchMarketingCheck against the relevant registry. Players who appear on the exclusion list are removed from the send list automatically. The operator's marketing team does not need to manually filter lists or remember to run a check. The check is built into the pipeline.
This matters because marketing systems often operate independently of the core platform. A CRM tool pulls a player segment, builds a campaign, and sends it. If the CRM does not know about the exclusion registry — or if it uses a cached player list from before the latest batch check — excluded players receive communications they should never see. PAM prevents this by making the marketing check a mandatory step in the send pipeline, not an optional filter the marketing team applies manually.
The commercial check also covers affiliate marketing. When an affiliate sends a list of leads or a batch of player data for matching, PAM validates that list against the exclusion registry before any marketing action is taken. Affiliates do not have access to the registry directly — the operator's platform must act as the gatekeeper.
The principle
Exclusion registries are not a feature you add when you enter a market. They are a prerequisite for operating in it. The integration has to be automatic, auditable, and fast enough to prevent a single excluded session.
"Automatic" means no human needs to remember to run a check, filter a list, or block an account. The system does it. "Auditable" means every check is logged — when it ran, what it checked, what the registry returned, and what action was taken. When the regulator asks, the answer is a database query, not a conversation with the compliance team. "Fast enough" means real-time at login and daily in batch. Not weekly. Not "when someone remembers to trigger it."
The architecture reflects a simple reality: in regulated markets, the cost of missing a single excluded player — in fines, in licence risk, in harm to a vulnerable person — is orders of magnitude higher than the cost of checking every player, every time. PAM is built on that assumption. Every login, every batch, every marketing send. No exceptions, no manual steps, no gaps.
PAM's GAMSTOP and Spelpaus integrations are live in production, running daily batch checks across all active players, validating every login in real-time, and filtering every marketing send against the exclusion registry. The entire pipeline is automated and auditable — operators see check results, block actions, and registry responses in the back office without writing a single line of code or running a manual process.