iGaming licensing,
made understandable.

The licence decides the build

Your choice of regulator shapes everything — features, reporting, even hosting. That is why we settle licensing strategy before architecture. Start with the broader regulations guide for context.

What every licence requires

Specifics vary, but most regimes demand the same pillars: corporate due-diligence, segregated player funds, certified KYC and AML, responsible-gaming tools, certified RNG/game fairness, and regulator reporting.

Costs and timelines

Curaçao is the fastest and cheapest route to a global-facing launch; the MGA and UKGC take longer and cost more but carry far greater trust and market access. Expect weeks for Curaçao and several months for tier-1 regimes.

How we help

We build your platform to the chosen regulator’s technical standard and support you through certification — the licence application itself you complete with specialist legal advisors.

Two different projects, one word

“Licensing” hides two projects. They fail for different reasons and they are run by different people.

The first is the corporate application: the entity and its structure, directors and shareholders, source of funds, the business plan, and the fit-and-proper assessment of the people behind it. It is disclosure, paperwork and patience. It is a job for licensing consultants and gambling lawyers.

The second is technical compliance: what the software has to do, and what it has to be able to prove it did. Certified game outcomes. A wallet that reconciles. Player-protection controls that hold at the account layer. An audit trail a regulator can read without you standing over their shoulder explaining it.

We do the second one. We are engineers — not licensing consultants, not lawyers. We will not file your application or assess your directors, and a firm offering to do all of it from one desk is selling you something. What we do is build the platform to the standard the regulator has published, and hand the test house something that passes.

The two tracks run in parallel, and that is where months disappear. The corporate track has an obvious owner and a visible queue. The technical track has neither — until somebody reads the technical standard properly and finds the platform has been recording the wrong things since sprint one. Before either starts, be certain the market is one you can serve: the regulations guide and our breakdown of where iGaming is legal cover that ground.

1. The random number generator

An approved test house looks at the generator, not the game: the entropy source, how it is seeded and reseeded, and how raw numbers are mapped onto reels, cards or draws. What it hunts for is correlation between an outcome and something that should never touch it — the player’s identity, their balance, their session, whether they are on a bonus. Most RNG failures we see are not in the generator. They are in the mapping.

2. Game maths and RTP

The paytable has to pay what you say it pays, over a run long enough that variance stops mattering. That is a simulation exercise, and it means nothing unless the RTP that was simulated is the RTP that is live. If your game server reads a return figure from a config file anyone with production access can edit, you have not certified a game. You have certified one possible version of it.

3. The audit trail

Take one bet from six months ago and rebuild it: who placed it, on which game and which build, what the RNG returned, what the paytable said, what the wallet did, what the player saw. If that takes an engineer a day with a SQL client, it is not an audit trail. It is archaeology.

4. Player-protection controls

Deposit limits, loss limits, session reminders, cooling-off, self-exclusion. The test is not whether the settings screen exists. It is whether the control holds when the interface is bypassed.

5. Change management — the one nobody scopes

Certification is not a gate you walk through once. It permanently changes how you are allowed to ship, and almost nobody budgets for it.

The UK Gambling Commission’s published testing strategy makes compliance with the remote technical standards a licence condition, and states that new games and RNGs can only be released once testing has been completed and the report provided to the Commission. It separates minor updates — no impact on game fairness, releasable without external retesting — from changes that do affect fairness and must be retested first. It also expects licensees to keep change-control documentation available on request, to have a personal management licence holder oversee the process, and to submit changes to an annual audit by an approved test house. Ontario’s AGCO takes a similar line in its Registrar’s Standards for Internet Gaming: standardised change-management procedures, segregation of duties between development and production, and emergency changes that are approved, tested, documented and monitored.

Read that as an engineer and it says something concrete: your release process becomes a regulated artefact. “Who approved this, what did it change, was it fairness-affecting, which build went out, and can you prove it” is a question your pipeline should answer, not a person from memory. Teams shipping weekly off trunk and a Slack thread do not find out until the first audit. Rules also move — confirm the current position with your regulator or your counsel before planning around any of it.

Every request in the left column has a right answer and a wrong one. The wrong one is a spreadsheet, a support ticket, or an engineer saying “that can’t happen”. The right one is a system that emits the evidence as a by-product of doing its job.

Build for audit, or pay twice

Retrofitting compliance is the most expensive recurring mistake in this industry, and it is expensive for a reason people miss. The code is not the hard part — a competent team adds an event log in a fortnight. The problem is that you cannot back-fill history. Evidence is only evidence if it was recorded at the time. Bolt the ledger on in month nine and your reconciliation starts from an opening balance nobody can vouch for, which is precisely the number an auditor asks about.

“Engineered from sprint one” is not a slogan. It is five decisions, made before the first game is integrated:

• Immutable event logs. State changes are appended, not updated. The audit trail is a by-product of how the system works, not a feature bolted to the side of it.
• A wallet ledger that reconciles. Double-entry. Every game round moves money in a way that balances, and the balance is derived from the ledger rather than held in a column someone can UPDATE.
• KYC status gating withdrawal. The withdrawal path cannot complete unless the verification check has passed — enforced in the state machine, not in a checklist an ops team follows. Our KYC and AML controls cover how those checks are sequenced.
• Self-exclusion at the account layer. Not the interface. The account is the boundary, so every route in — web, native app, partner API, an old client someone forgot to kill — hits the same refusal.
• Regulatory reporting as a data feed. Built off the event stream from the start, not assembled by a script that scrapes a replica at 3am and fails quietly.

Here is the honest counterpoint, because it matters when you are choosing. White-label is genuinely faster and cheaper to launch. The supplier’s platform is already certified and you inherit that work. If you want to be live this quarter and find out whether the market wants your brand, that is a rational decision and we will say so. What you trade is IP ownership, revenue share, per-brand cost, and the ability to build anything the supplier’s roadmap does not want.

Custom wins in four situations: you have volume, and the revenue share now costs more than a build would; your product is genuinely different and the supplier cannot ship it; you run several brands or markets off one core; or you intend to sell the company, in which case the owned platform is the asset being bought. That comparison is set out in development vs white-label, and the architecture in iGaming platform development.

The environment the auditor drives

Somewhere late in the plan there is a line that says “certification”. It quietly assumes a test house can get hold of your system and make it do things. That assumption deserves planning.

An auditor needs an environment that is the same build as production. Not last month’s build, not production-minus-three, not a branch with the payment provider stubbed out. If staging differs from live, the test house certifies software you do not run, and the gap is yours to own.

They need to reach edge states on demand: an account at its deposit limit, one mid-cooling-off, a self-excluded account, a player stuck between KYC tiers, a round interrupted by a dropped connection. If reaching those states needs an engineer writing SQL, every re-test costs a week.

They need determinism. Verifying that a given RNG output maps to a given reel position means being able to inject a seed and force an outcome — in staging, through a documented hook, never in production, and logged whenever used. Teams that never build that hook end up demonstrating fairness by playing a thousand spins by hand.

And they need read access to the logs and reports behind your claims, in a form they can query themselves. A screenshot is not evidence. Neither is a CSV you exported for them.

None of this is exotic — reproducible builds, seeded fixtures, isolated data. It is only that in gambling, someone external eventually turns up to check whether you had it. Our infrastructure and DevOps work treats those environments as deliverables, not as something improvised the week before an audit.