What a "no-KYC" game provider actually means
The phrase gets used loosely and it makes compliance teams nervous. Here is the precise, boring version — what data crosses the integration boundary, what does not, and whose obligations stay whose.
"No KYC" is one of those phrases that sells a meeting and then costs you an hour explaining what you did not mean. So let's be precise about it, because the precise version is genuinely useful — and it is much narrower than it sounds.
The claim, stated properly
A game content provider sits behind your platform. Players never have an account with us. They have an account with you. When a player opens Mines on your site, three things happen: you mint a session token, we resolve it to an opaque player identifier that you generated, and every bet from that point on settles against your wallet using that identifier.
That is the whole surface. The identifier is a string you choose. It can be a UUID, a hash, a sequence number — anything that means something to your system and nothing to ours. We never receive a name, a document, an address, a date of birth, an email, a phone number, a card number or a wallet address, because the integration has no field to put them in.
So the accurate statement is: we require no KYC data from you, because we have no use for it and no place to store it. Not: "you do not need to do KYC."
What that does and does not change for you
It does not change your licensing obligations. If your jurisdiction requires customer due diligence, that requirement attaches to you as the operator, and it would attach identically if you licensed content from a supplier that did demand player data. Nothing about our integration alters what your regulator expects from you.
What it does change is your data surface. Every party that holds identity documents about your players is a party that can leak them. Standard iGaming integrations often pass more than they need: real usernames because it is convenient for the live-bets feed, emails because someone wanted to send tournament notifications, IP addresses because a fraud vendor asked. Each of these is a copy of your customer data sitting in a system you do not operate.
Removing them is not a compliance shortcut. It is a reduction in blast radius. If we are breached tomorrow, the worst an attacker gets is a list of opaque identifiers and bet amounts. There is no identity graph to reconstruct.
The parts people get wrong
"So the games are anonymous?" No. From the player's perspective they are as identified as your platform makes them. Anonymity is a property of your onboarding, not of our games.
"Can we use this to serve markets we are not licensed for?" No, and this is worth saying plainly. Where you can operate is determined by your licence and your own geo controls. A supplier not holding identity data does not create permission that was not there.
"Does it mean you cannot investigate a dispute?" It means we investigate on round data, which is what disputes are actually about. Every round has a hashed server seed committed before the bet and revealed after settlement, plus the client seed and nonce. When a player claims a result was wrong, the answer is a recomputation, not a memory of who they are. Give us the round ID and we can reconstruct exactly what happened — and so can the player, independently.
"What about responsible gaming limits?" Those live in your wallet. When a player hits a deposit or loss limit, your wallet refuses the debit and the bet does not happen. The control point is on your side, where it belongs, because you are the one who knows the player's full activity across every game and provider.
What we do store
Being specific here matters more than the marketing line. Per round we keep the opaque player ID, the game, the currency, the amount, the timestamps, the seeds and the outcome. Aggregate reporting is built on those. We keep it because you need reconciliation and because fairness proofs are worthless if the round data disappears.
We do not keep, because we never receive: anything that identifies a natural person.
Why we built it this way
Partly principle, mostly self-interest. Holding customer identity data means inheriting the obligations that come with it — retention policies, subject access requests, breach notification duties, audits — in every jurisdiction where our operators have players. A content supplier that avoids collecting it avoids all of that, and gets to spend the engineering time on the games instead.
That is the honest version. It is less exciting than the phrase, and it is the one worth putting in a contract.