When to require KYC at casino registration

First, what your licence requires

This guide is about operations, not law. Many gambling licences set their own rules on when a player's identity must be verified, how, and what happens to deposits and withdrawals until it is. Those rules apply to every player whatever a risk system says. Risk-based KYC works on top of them: it decides who is asked earlier or more carefully than the baseline, never who can skip it. Check your licence conditions, and your regulator's guidance, before you change your onboarding.

Why not verify everyone at sign-up?

You can, and some operators must. Where you have the choice, a full document check at registration has costs. Every extra step loses some genuine players before their first deposit, each check costs money, and the review team spends its time on players who were never a problem. On the other side, waiting until the first withdrawal lets a multi-accounter collect a bonus, wager it and only then hit the wall, after the marketing cost is spent.

Step-up KYC splits the difference: a light touch for the sign-ups that look ordinary, and an early, firm check for the ones that don't.

Which sign-up signals justify a step-up

Good triggers are signals that suggest the account may not be the separate, real person it claims to be. Useful ones at registration:

• A repeat inbox. The email is an alias of an address that already has an account at your site.
• A plus-tagged address, which on its own proves nothing but is a common way to make a "new" address.
• A hidden location. A VPN, a datacenter IP, or a browser time zone that doesn't match the IP's country.
• Signs of automation. A scripted HTTP client instead of a browser, or a machine-made address.

Avoid triggers that mostly measure who someone is rather than what the sign-up did, such as nationality on its own. They catch more innocent players and are harder to defend.

What to do with each outcome

Tell the player what is needed and why, in plain words. "We need to confirm your identity before your first withdrawal" lands better than a silent freeze.

Wiring it up with InlineShield

InlineShield screens the registration before the account exists and returns a verdict with a recommendedAction:

Sign-up screened
 ├─ ALLOWED      → allow                      → normal onboarding
 ├─ ALLOWED      → allow_no_bonus             → account opens, offer waits
 ├─ BLOCKED      → block                      → no account
 └─ QUARANTINED  → review (held)              → your team looks
        ├─ approved → signup.approved webhook → require_kyc or allow
        └─ rejected → signup.rejected webhook → block

A sign-up with a repeat inbox, a plus tag, a VPN, a datacenter IP, a time-zone mismatch, a scripted client or a machine-made address is held for review by default (or blocked, when the signals together are strong enough). When your team approves it in the console, the signed signup.approved webhook carries recommendedAction: "require_kyc": open the account, and send the player to your KYC provider before any bonus or payout. A rejection arrives as signup.rejected with block. If your server can't receive webhooks, it can ask the review status endpoint instead.

Two things InlineShield doesn't do: it doesn't verify documents itself, and it doesn't decide your KYC policy. It gives your KYC process a reason and a moment to start. The allow_no_bonus action covers the middle row of the table; see withholding the welcome bonus. All five actions are on the risk verdicts page, and the casino view is on online casino bonus abuse.