Getting licensed is mostly a long list of questions about your platform. Openora is built so that most of the answers are already yes - and so the rest are yours to change, whenever you need to.
Switch between jurisdictions and open any row to see what it means in practice. We've been deliberate about the difference between what ships working, what you configure, and what remains your responsibility as the operator.
The most demanding of the mainstream licences, and the one most operators are measured against. If your platform satisfies Malta, it comfortably clears most other jurisdictions.
Who is allowed to open an account, and what you must know about them before they play.
The area regulators scrutinise hardest, and where most home-built platforms fail their first audit.
Proving that every cent is accounted for, and that money moves the way the regulator expects.
The single biggest reason platforms fail an audit: they can't prove what happened, or the records could have been altered.
Standard, unglamorous requirements. Easy to satisfy when they're built in, tedious and error-prone when they aren't.
Where the platform's job ends and the game provider's begins - a distinction regulators care about and vendors often blur.
Spotting the patterns that suggest laundering or abuse - and being able to show a regulator that you were looking.
Mapped against the MGA System Audit Checklist (MGA/G/002), the document an approved auditor works through when they inspect your platform.
Openora was built to be worked on by AI assistants as well as people. In practice that means a new requirement is a conversation and a review, not a quarter of development.
We're recording a walkthrough of a real regulator requirement going from wording to a tested change. It'll land here shortly.
Watch a real requirement go from a regulator's wording to a tested change - start to finish, unedited.
In plain language, straight from the regulator's document: "players must be able to set a weekly loss limit, and loosening it can only take effect after 72 hours." No translation into technical specification first.
Every part of Openora ships with machine-readable documentation describing what it does and where its boundaries are. An AI assistant doesn't have to reverse-engineer a codebase it's never seen - it starts from a map that's kept up to date automatically.
Because the platform is built as separate, well-defined pieces, a change to player limits touches player limits. Your developer reviews a focused, contained change instead of auditing a sprawling patch.
The change lands in your own repository with its history intact. When an auditor asks when a rule changed and who approved it, that's a question you can answer in seconds.
None of this removes the need for a competent engineer to review what lands in production - and it shouldn't. What it removes is the months of learning an unfamiliar system before anyone can safely change a single rule.
Made early, because these are the things that are painful or impossible to add to a platform once it's live.
Every action on the platform is written down and cryptographically linked to the one before it. If someone edits a balance, the chain shows it. Auditors care about this more than almost anything else, and it is the one thing that is genuinely painful to add later - so it's in the foundation, not an upgrade.
Limits, self-exclusion and cooling-off periods are enforced deep in the platform, not in the website. A broken page or a third-party game can't accidentally let a self-excluded player place a bet - which is exactly the failure regulators fine operators for.
Malta wants a 24-hour cooling-off period. Another regulator wants 72. Brazil wants a different AML threshold. On Openora these are values you change, not features somebody has to build - which is why a second licence doesn't cost what the first one did.
Your KYC provider, payment processors and game suppliers all connect through standard connection points. Entering a market that needs a local provider means adding a connector, not rewriting your business logic - and switching vendors later doesn't put your licence at risk.
This industry has a long history of vendors implying they can hand you a licence. They can't, and neither can we. Here's the honest boundary.
Licences are granted to companies and people, not to software. You'll need a licensing advisor, a corporate structure, and to pass fit-and-proper checks on you and your team. No platform changes that.
An approved auditor inspects your live system against the regulator's checklist. What Openora gives you is a platform where the honest answer to most of their questions is already "yes" - not a shortcut around the inspection.
RNG and game fairness are certified by accredited testing labs and belong to your game providers. Openora integrates them and records every result. Any platform claiming to certify its own RNG should make you nervous.
AML policies, complaints procedures, local staff, segregated bank accounts, regulator reporting deadlines. Openora holds the data these depend on, but the obligations are yours as the operator.
Regulations change, sometimes quickly - Brazil's have moved repeatedly. Treat this page as a map of how the platform is built, and confirm the current detail with a licensing advisor for your market.
The technology side is more tractable than most people expect - a lot of what a regulator asks about is already handled here. The parts that catch first-time operators out are rarely technical: company formation, banking, a licensing advisor, and the capital to fund player balances. Get those in motion early and in parallel, not after the platform is ready.
It depends on the markets you want and how much time and capital you have. Anjouan and Curaçao are common starting points - faster and cheaper, enough to launch and prove the business. Malta carries far more weight with payment providers and game suppliers, but takes longer and costs considerably more. Because the platform doesn't change between them, starting light doesn't lock you out of moving up later.
Threshold and rule changes are usually a matter of days. Local integrations - a regional KYC provider, a payment method, a regulator reporting feed - are typically weeks. The honest bottleneck in a licence application is almost never the software; it's paperwork, banking and the regulator's own queue.
You need someone technical who is accountable for the platform - employed, contracted, or through us. What you don't need is a large team, because you're configuring and extending an existing platform rather than building one. That's a meaningfully different cost base.
You change your platform, on your schedule. That's the entire point of this page. On a closed platform you file a request and wait for a vendor who is weighing your market against everyone else's - and pay for the privilege of waiting.
Yes, and the platform is designed for it. Limits and exclusions follow the player across brands, while thresholds and local rules are configured per market. Running a second brand or a second jurisdiction reuses everything you already built.
Planning a licence application and want to know whether this fits? Talk to the team - we'll tell you honestly if it doesn't.
Whether you're building from scratch, extending a legacy platform or planning a gradual migration, the framework gives you the freedom to evolve without vendor lock-in.
