iGaming regulations in Malta.

The EU’s iGaming capital

Malta pioneered EU iGaming regulation, and an MGA licence remains a gold standard for credibility and market access. See the broader regulations guide.

What the MGA requires

• Corporate and financial due-diligence
• Certified KYC and AML programmes
• Player-protection and responsible-gaming tools
• Technical and game-fairness certification
• Ongoing compliance reporting

Why operators choose Malta

Reputation, EU access and a mature ecosystem of providers make Malta a default base for serious operators — and we build platforms to MGA standard.

Malta licenses the supplier, not just the operator

This is the structural point that catches most teams out, and it is the one that matters most if you are building software rather than only running a brand. The MGA's published licence classes split into two routes: a Gaming Service licence — the B2C route, for taking bets from players directly — and a Critical Gaming Supply licence, the B2B route, for supplying the machinery that other licensed operators run on.

The MGA defines a critical gaming supply to include the supply and management of software, standalone or as part of a system, that generates, captures, controls or otherwise processes any essential regulatory record — and the supply and management of the control system that software resides on. Read that as an engineer rather than as a lawyer. It is describing your wallet, your bet-settlement path, your RNG integration, your player account store and your back office. If you build the platform and an operator puts their brand on it, the B2B licence is the one that describes you.

Both routes carry the same four game types. The MGA's own B2B licence page lists Type 1 as casino games, live casino, house-banked poker, lotteries and virtual sports; Type 2 as fixed-odds betting including in-play; Type 3 as peer-to-peer products — pool betting, player-versus-player poker and bingo, commission-based games; and Type 4 as controlled skill games. Several verticals can sit under one licence, but each needs prior approval before you switch it on.

That approval cadence is a scheduling problem, not a paperwork one. Type 3 peer-to-peer settles nothing like Type 1: rake and pot escrow across many players, versus a house ledger against a single counterparty. Type 2 in-play adds latency budgets and void-and-resettle paths the other two never exercise. If your architecture assumes one settlement engine serves every vertical, your second approval is where you find out.

That last row is why supplier-side work is held to a different internal standard. A B2C bug is an incident. A B2B bug is every client's incident at once, escalated to one regulator. It also sharpens the ownership question, because the MGA's definition turns on supplying and managing the software and its control system. If another vendor builds it, patches it and holds the keys, the honest answer to "who manages this?" is not you. Re-badging someone else's engine and presenting it as your critical gaming supply is a position you have to defend under audit. That is the real argument for a custom build over a white-label — not that white-label is bad, because it is genuinely faster and cheaper to launch a single brand on, but that it does not survive contact with a supplier licence.

An MGA licence is not an EU passport

This misconception is expensive, so it is worth stating flatly. Gambling is not regulated at EU level. Each member state regulates it nationally, and each may require its own licence. An MGA licence does not let you serve a member state that demands one of its own.

Germany, the Netherlands, Sweden and Denmark each run national licensing regimes. Serving their players on a Malta licence alone is not a grey area to those regulators — it is unlicensed, and it is enforced. The intuition comes from financial services, where an EU licence passports across the bloc. Gambling was carved out of that logic. The intuition is wrong, and the correction usually arrives as a letter.

What an MGA licence genuinely buys you is a base: an EU-domiciled entity, a regulator whose supervision other regulators recognise, and a supplier, payments and banking ecosystem that already understands what a gaming company is. It strengthens a national application. It does not replace one. If the UK is on your roadmap, that is a separate regime with its own licence and its own timetable — see UK gambling regulations. Check any target market against where iGaming is legal before you build a roadmap on top of it.

What multi-market base means in the build

If Malta is your base rather than your only market, the platform has to treat jurisdiction as a first-class dimension from sprint one. Retrofitting it is the most expensive rewrite in this industry, because it touches everything at once:

• Market gating at the session boundary, not on the marketing site. Which markets an account may play in gets resolved before a bet is accepted. It is a property of the request, not a banner.
• Per-market rule configuration — deposit limits, reality checks, cooling-off, bonus restrictions, self-exclusion scope. These differ per regulator and change on the regulator's schedule, not your release schedule. They belong in versioned configuration with an audit trail, not in code behind a deploy.
• Per-market reporting. Every regulator wants its own cut of its own players' activity. If answering "this market, this period, these players" needs a migration, every new market becomes a project.
• Separable player pools and ledgers, so a market can be added, suspended or exited without unpicking the others.
• Register-aware self-exclusion. Several regimes run a national register. The check has to consult the right register for that player's market — and fail closed when the register is unreachable.

Build this on day one and a new market is a sprint. Bolt it on and a new market is two quarters, every time, forever. That gap is the whole argument for platform development over site building, and it is why we put jurisdiction in the core rather than around it.

Player money is not your money

The MGA states the rule plainly: player funds are to be kept segregated and remain separately identifiable at all times, and the Authority may at its sole discretion exercise viewing rights over the common account of player funds. Most teams hear a banking instruction and open a second account. That is the easy half.

The hard half is the ledger. "Separately identifiable at all times" is a statement about your data model. It means that at any instant you can say what each player is owed, what the aggregate liability is, and that the aggregate ties to the money actually sitting in the account — and that you can show the arithmetic. A single mutable balance column cannot do this. Pending withdrawals, unsettled bets, bonus funds with wagering still attached, jackpot contributions and chargebacks all sit in different states of "owed", and a system that collapses them into one number cannot reconstruct the position after the fact. What works is double-entry: immutable postings, balances derived rather than stored, and a reconciliation job that fails loudly on the day the ledger and the bank disagree. You want that job failing in week one over five cents, not in year two over a real number.

Certification and the system audit

Two different things get tested, and teams routinely conflate them. Game and RNG certification is about fairness — an accredited lab verifies the randomness source, the return-to-player maths and the game logic against the paytable you publish. The system audit is about the platform: whether the thing you described in your application is the thing you actually run.

Per the MGA's published audit procedures, licensees engage approved audit service providers, and a review of the operation is generally expected after the first year of licensed operation, with further audits driven by risk. It is not a gate you clear once at launch. What passes is unglamorous: the environment matches the documentation, changes trace back to an approver, regulated records cannot be quietly edited, and someone can demonstrate a control rather than describe it. What fails is a platform whose answer to "show me" is "let me get an engineer". Build the demonstration surface alongside the feature — it costs a fraction of adding it under an audit deadline, and it is precisely what the licensing process exists to surface.

Engineering guidance, not legal advice

This page describes how we build software to meet a regulator's expectations. It is not legal advice. Malta's requirements change — the MGA revises its directives, checklists and audit procedures regularly. Confirm current requirements with the MGA and your own counsel before committing to a licence route, an architecture or a launch date.