Verification and Access Rules

Identity verification, self-exclusion, and jurisdiction rules used to be enforced in different places by different code, which is how a platform ends up with a player who is correctly blocked from depositing and then plays a slot or places a bet with no verification at all. This platform closes that gap with a single rulebook that every player action — deposit, withdrawal, opening a casino game, placing a sports bet, joining a promotion, and opening a reward box — checks against before it is allowed to happen.

What a player experiences

Whenever a player attempts one of those six actions, the platform answers one of three ways:

• Allowed. Nothing more is asked; the action proceeds.
• Verification needed. The player is told exactly which check is missing — proof of identity, proof of address, or both — and is offered the verification flow right there, without leaving the page they were on. The message follows what is actually outstanding: a player who only lacks proof of address is asked for their address, not their identity.
• Not available. The action is refused outright. This covers a jurisdiction your compliance policy has closed, a connection through a VPN or anonymizing proxy, or an account a compliance reviewer has actually rejected or placed on hold. Nothing the player resubmits reopens this state — a human decision is required. The player is never told why: the refusal says to contact support, and the internal reason (which control caught them, whether a review is open) stays in the server logs, because naming it would tip off a player under a compliance review.

A closed (deleted) account is refused at sign-in before any of this applies; see Player Accounts & Notifications.

A player who has chosen to self-exclude sees a fourth answer for the actions self-exclusion covers: they are simply told the account is excluded, with no mention of verification at all. Asking a self-excluded player to go verify their identity would read as an invitation to keep playing, which is exactly what self-exclusion exists to prevent.

Receiving a tip from another player is held to the deposit rules of the recipient as well: the same region, verification and self-exclusion checks apply, and the sender is told only that the recipient is unavailable.

The one deliberate exception: withdrawing your own money

Self-exclusion blocks depositing, playing casino games, placing sports bets, joining promotions and opening reward boxes. It does not block withdrawing an existing balance. A player who excludes themselves must still be able to get their own money out — a protection tool that also freezes a player's funds would punish them for using it, which defeats the point. Verification requirements on withdrawals still apply as normal; only the self-exclusion check is exempted.

What triggers a verification requirement

Two kinds of trigger exist, and they don't overlap:

• A cumulative amount. Deposits and withdrawals can require identity verification once a player's lifetime total (converted to a common currency) crosses a threshold you configure — for example, identity proof past a deposit total, and both identity and address proof past a larger withdrawal total. See KYC & Identity Verification for the current default thresholds and how the tiers work.
• The action itself. Casino play, sports betting, promotion enrollment and opening a reward box can each carry their own verification requirement independent of any amount — useful for jurisdictions that require proof of identity before any wagering at all, regardless of stake size.

As shipped, those four actions require no verification by default. Opening a reward box is a deliberate example of why the gate exists anyway: if you see boxes farmed by freshly created accounts, you can require a verified identity to open one — everywhere or only in the regions where it happens — without any code change. Opening a box stakes nothing, so wagering limits do not apply to it, but self-exclusion does.

A casino game is checked for access at the moment a player opens or resumes it, not on every individual spin. If a player's verification status changes while they're mid-session — an account is placed under compliance review, for instance — their open game session is closed immediately rather than being left running until they happen to reload the page.

It varies by region, on purpose

The platform's default rulebook applies everywhere, but any region can be given its own rule set that fully replaces the default for that region — not layered on top of it. This is what lets you require identity verification before the first deposit in one jurisdiction while allowing a threshold-based approach elsewhere, or block a jurisdiction from a given action entirely, all from configuration your compliance team controls in the backoffice. A region with no rule of its own simply follows the default. Because a region's rule replaces the default rather than adding to it, it must state everything it keeps — and editing the default does not reach a region that overrides it.

As shipped, every region follows the same default rule set — no jurisdiction has special-cased treatment, and no region is blocked outright. That is a starting position, not a limitation: turning on a jurisdiction's specific rules, or blocking a jurisdiction on the backoffice's Blocked Regions screen, is a configuration change, not new engineering work.

Blocking a region is stronger than a rule. A blocked region is walled for the whole site, not just for gated actions: a visitor whose connection resolves to that country gets a "not available in your region" page that names the country. Separately, a player whose stored region is blocked is refused every gated action even if their connection looks elsewhere. The stored region comes from the IP at sign-in, a staff member's manual setting, or an approved identity document, and the document wins over the other two. The staff reason for the block is internal and never sent to the browser. Two safeguards keep the wall honest: a lookup that cannot place the visitor never walls them, and the local-development fallback country is never used to wall anyone. Unsubscribe links in campaign email stay reachable from a blocked region.

Where a rejection or a hold applies

Two account states close the door on money and play regardless of anything else:

• A compliance-fatal rejection — the account failed a check for a reason that resubmission cannot fix, such as a sanctions or fraud match. This is permanent for the account.
• An account under review — verification monitoring is ongoing even after approval, and a player can be placed under review at any time. While under review, deposits, withdrawals, casino play, sports betting and promotion enrollment are all closed until a compliance reviewer resolves it.

A staff rejection of a document-upload case is just as final: the player can no longer upload or submit at that level, and the other levels point them to support rather than offering to verify.

This is different from a document-upload case that is merely waiting for review. Our own upload review is treated like any pending check: the level is not yet satisfied, so an action that requires it (a withdrawal needing identity, say) stays closed, but nothing else is blocked. Play and deposits stay open, no session is closed, and the player's status reads in progress. Only holds that come from a vendor or from ongoing monitoring close the door on everything.

An account already under review or carrying a fatal rejection cannot open a new casino game or place a new sports bet, even with an existing balance and even though nothing about their verification level has changed. A bet already placed before the review started is left to settle normally rather than being cancelled — a placed bet is a commitment the platform has already made, and unwinding it is a separate decision from closing the account to new activity.

Managing the rules in the backoffice

Your compliance team manages the rulebook on the Jurisdictions page: the default, then one row per country with its own rules, each saying in words what differs from the default. Opening a country shows every action with where its rule comes from — the default, or the country — alongside which provider verifies the country's players (the page names the upload route Manual review) and whether a player's first withdrawal is held for manual review. A country changes only what it needs to; everything else keeps following the default, including later edits to the default. Deposit and withdrawal thresholds are edited in place, as lifetime USD amounts with the checks needed past each one. A country with no provider of its own follows the default's; if no provider is set at all, the page warns that verification would fail for everyone who needs the check. Every change requires a written reason and is recorded in the audit log; the default cannot be removed, and a country can be reset to follow the default again. This one page replaces the separate player-gates and KYC-routing screens of earlier versions.

A deposit-wagering setting also exists in storage but is not yet enforced and is not shown on the page; no deposit is held by it today.

See also: KYC & Identity Verification for the verification tiers themselves and how vendor checks work, and Responsible Gaming for self-exclusion, deposit/loss/wager limits, and the other player-protection controls this rulebook defers to first.

Scope & Roadmap

Implemented. One rulebook checked by deposit, withdrawal, casino launch, sports betting, promotion enrollment and reward-box opening; per-region rules that replace the default; self-exclusion checked first, with withdrawals exempt; hard blocks for closed jurisdictions, VPNs, compliance-fatal rejections and accounts under review; a site-wide wall for blocked regions that names the country but not the reason; open casino sessions closed when access is lost; upload reviews that wait without blocking play or deposits; backoffice editing of every rule with mandatory reasons and an audit trail; an optional per-region manual review of a player's first withdrawal.

Not built. Thresholds on wagering turnover — only deposits and withdrawals escalate by cumulative amount. Enforcement of the deposit-wagering setting. Region-specific rules beyond the shared default are yours to configure; none ship preset.