Self-exclusion asks 1 question; the shared wallet answers for 3 sites

Self-exclusion is built on a single question: do you want to be blocked from gambling here? It was designed for a world where "here" meant one operator, one licence, one database. The moment a player holds accounts at three skins running off the same wallet, that question stops describing reality. The player answers once; the wallet answers for three sites — and sometimes for a fourth they haven't opened yet.

The gap between what you answer and what gets blocked

Most national self-exclusion registers work on a per-operator basis. You tick a box, the operator flags your account, and marketing stops. That is a clean model when your relationship with the operator is a single account. It breaks when the operator's relationship with you is a wallet that funds accounts across several front-ends.

Consider a mid-size group running three brands on one back office. Same KYC file, same payment rails, same responsible gambling team. A player self-excludes on Brand A. Depending on how the group has wired its internal tooling, one of three things happens:

1. The block propagates to Brands B and C automatically, because the wallet is the identity layer.
2. The block stays on Brand A, and Brands B and C keep sending reload bonuses, because each brand's CRM treats the player as a separate customer.
3. The block propagates, but only after a delay measured in hours or days, during which the player can still deposit on B and C.

Option 1 is what players assume is happening. Option 2 is what regulators often assume is happening, which is why they keep writing multi-licence rules. Option 3 is the one that generates complaints, because the player did the responsible thing and still got a text message at 9pm.

The uncomfortable part: all three can be true inside the same group, depending on which product you're talking about. Sportsbook and casino on one wallet might share a block. A poker room acquired two years ago and not yet migrated might not.

Why shared wallets make self-exclusion harder, not easier

The intuitive take is that a shared wallet should make this trivial. One identity, one flag, one switch. In practice, shared wallets are usually built for the opposite purpose: to let a player move money between products without friction. That design goal — reduce friction — is directly opposed to the design goal of self-exclusion, which is to add friction at exactly the right moment.

A few structural reasons the switch is harder than it looks:

The wallet isn't always the identity. Plenty of groups have a payments wallet that sits downstream of three separate account systems. The wallet knows it's the same person because the card matches. The account systems don't, because they were built by different teams in different years and never reconciled their player IDs.

Marketing consent lives elsewhere. Self-exclusion is not the same as withdrawing consent for marketing, but players reasonably expect both to stop. If the CRM database and the gaming database are separate — and they usually are — a block in one doesn't touch the other. This is how people end up excluded and still receiving SMS.

Third-party tools sit in the middle. Many operators route self-exclusion through a vendor that handles affordability checks, KYC, or both. If the vendor's flag is per-account and the operator's wallet is per-person, someone has to write the mapping. That someone is usually a product manager with a backlog.

Licence boundaries are real. A group operating under a Malta licence and a UK licence may legally be able to share data internally, but the operational reality of two compliance teams, two reporting lines, and two sets of audit trails slows propagation. Not because it's forbidden, but because nobody owns the cross-licence case.

None of this is exotic. It's the normal state of an industry that grew by acquisition.

The number that matters

Here's the anchor: in the UK, self-exclusion through GAMSTOP covers roughly 90% of the online market by operator count, and the scheme reported over 100,000 registrations in a single year during its peak period. That's a national register doing what a national register does well. But GAMSTOP blocks the player across participating operators — it doesn't necessarily block them across skins of the same operator if a brand isn't properly integrated, and it doesn't touch unlicensed sites at all. A player who self-excludes via GAMSTOP and then opens a crypto casino with a Curaçao licence has answered the question once and been blocked approximately zero times.

That's not a failure of GAMSTOP. It's a failure of expecting a per-operator answer to solve a per-wallet problem.

What a wallet-level block would actually look like

If the industry took the shared wallet seriously as the unit of self-exclusion, the mechanics would look different in a few specific ways.

The block attaches to the payment identity, not the account. Card fingerprint, bank account, and verified name become the exclusion surface. Any account funded by those instruments is blocked, regardless of which brand front-end it sits behind. This is roughly how some payment processors already handle fraud — the infrastructure exists, it's just pointed at a different problem.

Propagation is synchronous, not eventual. When a player confirms self-exclusion, the flag writes to every product the wallet touches before the confirmation screen renders. No "please allow 24 hours." If the architecture can't do that, the operator should say so at the point of exclusion, not in a terms page.

Marketing suppression is part of the exclusion, not a separate request. The player asked to be left alone. Treating that as two consents is a compliance artefact, not a player expectation.

Cross-licence propagation is the default, not the exception. If a group can move money between licences, it can move a self-exclusion flag. The legal question is whether it's permitted; the operational question is whether anyone has been asked to build it.

The counterargument is real: a wallet-level block is harder to reverse, and reversals matter. Players do come back, and an over-broad block that follows someone across a group for years, with no clean way to lift it, creates its own harm. Most self-exclusion schemes handle this with a cooling-off period and a formal reactivation process — typically 24 hours minimum, often seven days, sometimes longer for a first reversal. A wallet-level block would need the same, plus a clear answer to what happens when the player's card changes.

The question nobody wants to answer

Here's where it gets awkward. If a group runs three brands on one wallet and a player self-excludes on one, the group almost certainly knows — with high confidence — that the player is now excluded and still holds two active accounts. Continuing to market to those accounts is not a grey area. It's a decision.

The industry's defence is usually technical: the systems weren't built to talk to each other. That was true five years ago. It's less true now, when the same groups run unified CRM platforms and single sign-on across brands for convenience purposes.

So the open question is this: if a group can unify a player's experience across three brands for the purpose of cross-selling, why can't it unify the exit? The technology is the same. The only thing that differs is who benefits from the delay.