Skip to content
casino.limo
CurrentPublished by Alexa SavelleContent updated · Research checked

How to Start an Online Casino

A launch plan covering market access, license responsibility, platform and data control, games, payments, compliance, testing and exit.

Starting an online casino is not a software-shopping exercise. It is the controlled assembly of a regulated operating business: target-market authorization, a named consumer-facing operator, approved content, production payment capacity, player-protection controls, tested technology, and an operating team that can evidence what happened after launch.

This guide is a procurement sequence, not a vendor directory. Great Britain and Malta provide concrete regulatory boundaries, but every target jurisdiction needs its own market, entity, product, and supplier decision. Treat each supplier logo, demo environment, license number, test certificate, and payment integration as one scoped input. Legal and operational readiness requires the complete market, entity, product, supplier, control, and production picture.

The practical output is a launch evidence pack. Every material launch decision needs a legal entity, contract clause, authority record, production test, named control owner, and dated acceptance record. If any of those items is missing, treat the point as an open dependency rather than a launch fact.

Key decisions and controls
  • + Freeze the target market, customer location, products, channels, and operating entity before selecting a platform.
  • + Treat white label, turnkey, and software license as commercial delivery models, not as proof of regulatory authorization.
  • + Name the legal entity responsible for the player, license, merchant account, customer funds, data, games, AML decisions, and responsible-gambling interventions.
  • + Accept content game by game and build by build; an aggregator connection does not prove that every title is approved for every market.
  • + Prove production payments, reconciliation, withdrawals, customer-funds treatment, and PCI scope before taking deposits.
  • + Make launch conditional on evidence from compliance, testing, security, operations, and exit-readiness workstreams, not on a vendor's delivery status.

Continue the decision

Continue with the guide that matches the next licensing, market-access, procurement, or launch decision.

01

Freeze the market before buying the stack

Write one target-market decision for each country or territory. It should name the player locations you will accept, the products and channels you will offer, the entity that will contract with players, the intended domains or apps, and the legal basis for every regulated activity. Do not use the place of incorporation as a shortcut for the place of regulation. A business based abroad still needs a Gambling Commission license when serving consumers in Great Britain.

The decision must also cover the proposed corporate and technical setup before the site is built. A Malta application covers the applicant and key people, funding, business plan and operating procedures, technical setup, and a system audit. Those are linked workstreams, not forms that a platform supplier can complete in isolation.

  • + Accepted and blocked player locations, including travel and VPN handling
  • + Casino products, game types, channels, currencies, languages, and marketing routes
  • + Applicant, consumer-facing operator, license type, and any host or software permissions
  • + Domains, apps, infrastructure locations, material suppliers, and regulator notifications or approvals
  • + Written legal assumptions, unresolved questions, decision owner, and re-review trigger
  1. 1
    Create the market fact sheet

    Record the player location, product, channel, entity, domain, marketing route, and payment flow. Ask local gaming counsel to answer against those exact facts rather than against a generic 'online casino' description.

  2. 2
    Build the authorization matrix

    For every activity, name the required authorization, holder, issuing authority, application or register evidence, scope limitation, and condition that must be met before launch.

  3. 3
    Open dependencies before procurement

    List corporate, funding, key-person, policy, system, audit, domain, supplier, and payment dependencies. Give each one an owner and acceptance document before a vendor proposal becomes a build commitment.

Market first, platform second

If the target jurisdiction and license holder are still described as 'to be confirmed,' platform pricing and launch plans are not decision-grade. The missing regulatory facts can change the entity, contracts, suppliers, payment route, controls, testing, and data architecture.

Sources for this section: [1], [2]

03

Choose white label, turnkey, or software by control boundary

White label, turnkey, and software license are not stable regulatory definitions. Suppliers bundle different entities, licenses, services, and control rights under the same labels. Compare the actual operating boundary: who holds authorization, contracts with players, controls the ledger and data, contracts with games and payments, operates compliance, approves releases, and can continue the business after termination.

A software permission is not the same as a casino operating permission. UKGC materials distinguish remote casino, host, and gambling-software activities, and make the software supplier responsible for software that can be deployed in compliance with the technical standards. That does not by itself authorize the buyer's consumer-facing operation.

Commercial models compared by the boundary that must be fixed in contracts and acceptance tests.
ModelTypical control boundaryMain procurement testDo not assume
White-label operating arrangementAnother operator may supply the regulated operating umbrella and much of the stack while the brand controls a narrower commercial layer.Identify the actual license holder and confirm its oversight, decision rights, player relationship, domains, payment entity, data access, and termination process.That the brand owns the player relationship or that the license holder's responsibility passes to the brand or platform.
Turnkey stack under the buyer's operating structureA supplier delivers an integrated platform and services, while the buyer is intended to be the licensed consumer-facing operator.Confirm that the buyer can meet applicant, funding, operating-policy, technical, audit, supplier, payment, and data obligations with the delivered system.That 'turnkey' includes a license, merchant account, approved games, operational staff, or regulator acceptance.
Software license or component buildThe buyer integrates and operates more of the platform, suppliers, infrastructure, controls, and release process.Define source and configuration rights, interfaces, hosting, security, test evidence, support, change control, data export, and exit deliverables.That software conformance proves the complete operation is licensed, secure, tested, or ready for players.

Buy an explicit boundary, not a label

Reject a proposal that cannot show the exact legal entities, regulated activities, production responsibilities, data and money flows, dependencies, exclusions, acceptance evidence, and exit process behind its delivery label.

Sources for this section: [1], [2], [3], [4], [5]

04

Secure platform, ledger, and data control

Platform control is the ability to operate, supervise, evidence, change, recover, and exit the service. It does not require direct database administration, but it does require reliable access to the player account, wallet and ledger, game and payment events, compliance decisions, communications, configuration, and audit trail at the level needed by the operator and its authorities.

Treat data roles and technical access as separate questions. Where the EU GDPR applies, a controller must use processors that provide sufficient guarantees and must put the processing terms in a binding contract; subprocessors require authorization, and security must be appropriate to risk. Other markets, including Great Britain, have their own applicable privacy framework. Contract language is still not enough. Require routine exports, incident access, restoration, and a termination export to pass tests as rigorous as the player journey.

  • + Immutable transaction identifiers and traceable relationships among deposits, bets, wins, bonuses, adjustments, reversals, and withdrawals
  • + Documented schemas, APIs, time zones, status definitions, retention rules, and correction procedures
  • + Operator-controlled roles, least-privilege administration, approval workflows, logs, and emergency access
  • + Reproducible configuration, release inventory, backup ownership, recovery objectives, and tested restoration
  • + Complete, documented exports for operations, regulators, disputes, migration, retention, and deletion
  1. 1
    Map data and decision rights

    For each dataset and system action, name the owner, controller or processor role, permitted purpose, location, retention rule, users, subprocessors, and approval authority.

  2. 2
    Run evidence-grade export and reconciliation tests

    Export a complete test population, reconstruct account and wallet events, reconcile totals to source systems, and verify that identifiers, timestamps, statuses, and adjustments survive the export.

  3. 3
    Test recovery and exit before launch

    Restore an agreed environment or dataset, exercise incident access, and produce the termination export and handover documents. Record defects as launch dependencies rather than future roadmap items.

A dashboard is not data control

A dashboard can hide missing fields, aggregation, delayed status changes, and unexportable decisions. Accept data control only after the operator can reconstruct a player, balance, game, payment, and compliance case from exported records.

Sources for this section: [5], [12], [14]

05

Approve the content chain game by game

Separate commercial access to a game from permission to deploy it. A casino may receive content through a direct studio contract, an aggregator, a platform bundle, or several layers at once. Record every legal entity and technical host in that chain. Then verify the supplier status, game and RNG evidence, allowed market and channel, exact build, rules and return information, and any regulator submission required for that casino.

Use a controlled games register as the release source of truth. In Great Britain, new games and RNGs that require third-party testing may be released only after testing is complete and the report has been provided. A B2C licensee using B2B content must still maintain its own current games register. Apply the exact local rule for the target market rather than copying the British process.

  • + Studio, aggregator, remote game server, platform, and contracting legal entities
  • + Supplier authorization or register entry and any market, product, channel, or hosting limitation
  • + Game name and identifier, build or version, RNG and test-report references, channel, language, rules, paytable, and return information
  • + Jurisdiction approval or notification status and evidence owner
  • + Change classification, retest decision, release approval, rollback, suspension, and supplier-withdrawal process
  1. 1
    Trace the complete supply chain

    Require the platform or aggregator to disclose the contracting supplier, software supplier, host, and any sub-aggregator for every content family. Match each entity to the relevant authorization and contract.

  2. 2
    Build a per-game evidence pack

    Bind the title and internal game ID to its supplier, exact build, test or RNG evidence, permitted jurisdictions and channels, rules, return information, and regulator record or submission where required.

  3. 3
    Gate releases and updates

    Release only an approved build from the games register. For each update, record whether fairness or another regulated behavior changes, whether retesting or filing is required, who approved it, and how to roll it back.

  4. 4
    Prepare withdrawal and suspension

    Test the ability to remove a title or supplier quickly without corrupting balances, incomplete rounds, reports, dispute evidence, or retained records.

Sources for this section: [4], [5], [6], [14]

06

Prove payments, merchant status, and customer-funds treatment

A payment-method logo or working sandbox is not production payment capacity. Accept a method only when the correct casino entity has a named production merchant and acquiring route, approved use case and markets, production credentials, settlement account, pricing and reserve terms, chargeback ownership, withdrawal route, reconciliation fields, support path, and tested failure handling.

Draw the complete money flow from player to final settlement and back to the player. Keep payment-account-data scope separate from the wider gambling ledger and customer-funds question. PCI DSS remains relevant to entities that store, process, transmit, or can affect payment account data, including outsourced arrangements. Customer-funds rules are jurisdiction-specific: a Great Britain remote B2C casino operator covered by the customer-funds regime must segregate held customer funds from business accounts, but segregation alone does not guarantee repayment on insolvency. Do not apply that rule to B2B or software-only entities without checking their actual license activity.

  1. 1
    Approve the money-flow diagram

    For each method, show every legal entity, account, processor, currency conversion, fee, reserve, settlement leg, wallet posting, refund, chargeback, and withdrawal leg.

  2. 2
    Test production-like positive and negative paths

    Cover successful, declined, abandoned, duplicated, delayed, reversed, disputed, partially settled, and failed-withdrawal cases. Prove idempotency and the final ledger and bank treatment.

  3. 3
    Sign the first complete reconciliation

    Reconcile processor, acquirer, bank, wallet, customer-funds, fees, reserves, chargebacks, and general-ledger records using the same identifiers and owners that operations will use after launch.

Payment and funds acceptance controls for each method and legal entity. The standards and regulatory boundaries do not replace merchant and contract records.
Control areaRequired decisionLaunch evidence
Merchant and acquirerName the contracting merchant, acquirer or acquiring chain, approved markets and transaction type, settlement currency, reserve, and prohibited activity.Executed contract or approval, production merchant identifiers, production credentials, settlement instructions, and live support escalation.
Gateway and processorDefine routing, tokenization, stored credentials, retries, 3DS or equivalent controls, status model, webhooks, and data responsibility.Production configuration, data-flow and PCI-scope record, negative-path tests, duplicate protection, and event logs.
Deposits and withdrawalsDefine eligibility, ownership checks, pending and failed states, reversals, limits, manual review, and who can release or reject funds.End-to-end test cases, approval matrix, customer messages, case records, and reconciliation across payment and wallet systems.
Customer fundsDefine which balances count as customer funds, where they are held, how they are separated or protected, who controls them, and what is disclosed.Applicable legal memo, account evidence, funds policy, insolvency treatment, disclosure text, approvals, and ledger-to-bank reconciliation.
Finance operationsAssign settlement, fee, reserve, chargeback, wallet, bank, and general-ledger reconciliation and defect ownership.Signed reconciliation with traceable exceptions, close procedure, access controls, evidence retention, and escalation thresholds.

Sources for this section: [5], [7], [8], [13], [14]

07

Build KYC, AML, and player-protection operations

Buy workflows, evidence, and accountable decisions, not isolated checks. The target-market control set may include identity and age eligibility, location, sanctions and PEP screening, customer due diligence, enhanced due diligence, source-of-funds or source-of-wealth review, transaction monitoring, suspicious-activity reporting, self-exclusion, limits, harm indicators, interventions, complaints, and record retention. The applicable thresholds and legal procedures come from the target jurisdiction; they should not be invented by the platform or copied from a different market.

FATF provides an international risk-based baseline, including customer and beneficial-owner identification, the purpose and nature of the relationship, ongoing due diligence, transaction scrutiny, records, PEP controls, and higher-risk measures. It is implemented through local law, not used as a substitute for it. In Great Britain, enhanced due diligence applies to higher-risk relationships and transactions, and remote player protection is a continuing identify-act-evaluate process with timely monitoring and action even when third parties provide the systems.

For Great Britain launches, check the rule set against the actual go-live date. The second phase of RTS 12 changes takes effect on September 30, 2026. From that date, operators must offer gross deposit limits, reserve the name “deposit limit” for that type of limit, give it at least equal prominence, and offer it over fixed time frames. This is a dated UK requirement, not a universal casino-platform feature.

  1. 1
    Translate rules into owned decisions

    For every legal or policy requirement, define the trigger, data, system action, human role, deadline where applicable, evidence, escalation, and final decision authority.

  2. 2
    Run complete case simulations

    Use linked onboarding, payment, gameplay, marketing, support, AML, and harm-indicator events. Verify that alerts reach the right people, actions affect the account, decisions are reviewable, and evidence can be reconstructed.

  3. 3
    Retain operator oversight

    Give the accountable operator live access to cases and management information, audit and sampling rights, rule-change approval, manual intervention, incident escalation, and an exit export.

Compliance workflow acceptance under the exact target-market rule set.
WorkflowWhat must be designedEvidence to accept
Risk assessment and onboardingMarket, product, channel, customer, payment, geography, technology, and supplier risks; identity and eligibility gates; prohibited and escalation outcomes.Approved risk assessment, rule inventory, data sources, ownership, test population, decision logs, and blocked-path tests.
CDD, EDD, PEP, sanctions, and source reviewTrigger, required evidence, verification method, reviewer authority, senior approval, monitoring, rejection or exit, and reporting decision.Procedures, case templates, audit trail, sample completed cases, quality review, and evidence that higher-risk cases receive enhanced controls.
Transaction monitoring and suspicious activityData coverage, scenarios, alert ownership, investigation, disposition, reporting route, confidentiality, tuning, and management information.Traceable source events, generated alerts, completed investigation, reporting decision, access restriction, QA, and retained evidence.
Responsible gambling and customer interactionIndicators, timing, automated and manual actions, marketing suppression, limits and exclusions, vulnerability handling, evaluation, and escalation.End-to-end cases showing identify, act, and evaluate; human review where needed; customer communications; outcome measurement; and audit logs.
Third-party compliance servicesWhat the provider decides or recommends, data it can access, service limits, human review, incident duties, audit rights, and operator override.Responsibility schedule, due diligence, monitored service levels, case access, quality sampling, escalation drill, and termination export.

Sources for this section: [3], [8], [9], [10], [11]

08

Test the regulated system, security, and recovery

Use one acceptance matrix that links every legal, technical, financial, security, privacy, and operational requirement to a test, environment, build, owner, result, defect, and evidence file. Vendor unit tests and a penetration-test summary are inputs, not final acceptance. The operator must know which production configuration was tested, what was outside scope, and what changed afterward.

Regulatory testing and security assurance solve different problems. UKGC standards cover account information, transactions, rules, outcomes, RNG, interrupted play, limits, responsible product design, and other remote-gambling behavior; its testing strategy defines when independent testing and reports are required. PCI DSS addresses payment-account-data security. Where the EU GDPR applies, it requires security appropriate to privacy risk and regular testing. NIST CSF 2.0 supplies a governance and incident lifecycle, while OWASP ASVS 5.0 can turn application-security expectations into contract and verification requirements. None of these replaces the others.

  1. 1
    Baseline the exact release candidate

    Freeze component versions, configurations, suppliers, infrastructure, domains, game builds, payment routes, integrations, and evidence references. Define which changes invalidate or narrow previous testing.

  2. 2
    Test requirements, failures, and operations together

    Include normal journeys, abuse cases, degraded suppliers, network and queue failures, duplicated events, partial outages, rollback, security incidents, privacy events, restoration, and manual operations.

  3. 3
    Close with an evidence-based go or no-go

    Record each open defect, affected requirement, exposure, compensating control, owner, decision authority, and closure condition. Do not treat an untested production difference as a cosmetic exception.

Minimum acceptance layers for the release candidate.
LayerTest focusRequired evidence
Regulatory product and game behaviorAccounts, transactions, rules and return information, results and RNG, interrupted play, limits, responsible design, game versions, and required submissions.Requirement traceability, approved test-house or equivalent reports where required, games register, submitted records, and exact release build.
Wallet, ledger, payments, and reconciliationConcurrency, idempotency, duplicate and late events, reversals, incomplete rounds, adjustments, settlement, withdrawals, and exception handling.Dated end-to-end results, input records, reconciled totals, exception ownership, and regression tests tied to the build.
Cybersecurity and supplier riskGovernance, asset and supplier inventory, identity and access, protection, detection, response, recovery, logging, vulnerability handling, and change control.Target security profile, architecture and threat records, control tests, incident exercise, recovery result, open-risk acceptance, and supplier evidence.
Application securityAuthentication, session, authorization, input handling, APIs, files, cryptography, business logic, logging, and deployment controls at the agreed assurance level.ASVS-based requirement set, test scope and method, reproducible findings, remediation evidence, retest, and accepted residual risk.
Privacy and data resilienceProcessing instructions, subprocessor boundary, access, encryption or equivalent protection, retention and deletion, breach workflow, backup, restoration, and regular control testing.Role and data-flow record, processing terms, security test, restore test, breach exercise, retention actions, and export or deletion evidence.
Payment account dataCardholder-data environment and connected systems, third-party responsibilities, segmentation, secure development and operation, and validation route.Current scope diagram, responsibility matrix, provider status, applicable assessment or attestation evidence, scans or tests, and remediation closure.

Certificates have a scope

For every certificate or attestation, record the legal entity, product, version, environment, standard, test dates, exclusions, limitations, and current status. Supplier-level certification does not automatically extend to the casino's release candidate or operating controls.

Sources for this section: [5], [6], [7], [12], [13], [14], [15]

09

Turn launch dependencies into a cash-control plan

Do not reduce the launch budget to one setup price. The business may need to pay an expense, place refundable funds with a counterparty, maintain regulatory capital or security, safeguard player liabilities, and finance operating runway at the same time. Those uses of cash have different owners, release conditions, and failure consequences even when they share a currency.

Build the plan from the authorization matrix, signed supplier scope, current quotes, payment terms, staffing plan, test plan, and operating model. Give every line an amount status, currency, timing, owner, due date, and evidence or quote date. Keep applicant-specific and unknown amounts unpriced. A blank line is an open dependency; it is not zero and should not disappear inside an all-in total.

Cash treatments that must remain separate in the launch plan.
Cash treatmentDecision to recordAcceptance evidence
Regulatory and professional expenseIdentify application, annual, testing, legal, tax, audit, and filing charges for the exact entity and route. Separate fixed, recurring, variable, and applicant-specific lines.Current authority schedule, engagement letter or quote, calculation base, tax treatment, payment trigger, refundability, due date, and owner.
Supplier implementation and recurring spendSeparate implementation, migration, certification, integration, hosting, support, minimum commitments, and revenue-share cash effects by supplier and contract base.Named proposal, ordered scope, dependency schedule, fee definition, minimum or credit treatment, invoice trigger, acceptance gate, and exit charge boundary.
Payment reserve or held fundsRecord which entity provides the funds, who controls them, what exposure they secure, whether they are recoverable, and what releases or increases them.Executed merchant or payment terms, reserve calculation, settlement account, permitted use, release conditions, reconciliation owner, and counterparty confirmation.
Regulatory capital, security, and player liabilitiesKeep paid-up capital or security and the cash needed to meet player balances separate from spend. Do not count the same cash twice unless the applicable structure permits both uses.Applicable capital or security condition, corporate and bank records, player-funds policy, account evidence, balance forecast, control owner, and release restriction.
Working capital and contingencyModel payroll, operations, refunds, chargebacks, supplier settlement, incident response, delayed launch, and failed dependency scenarios over the chosen runway period.Board-owned scenario, timing assumptions, downside cases, cash source, decision thresholds, monitoring cadence, and documented action when the buffer falls below the approved level.

Keep unknown cash visible

Use the launch budget planner to separate currencies and cash treatments. Transfer a regulatory or supplier amount only when its route, entity, scope, calculation base, payment trigger, and evidence date are known; leave every other amount explicitly unresolved.

Build the launch cash plan

Sources for this section: [2], [3], [7], [13], [14]

10

Make launch a documented control decision

A launch plan is complete only when each gate has an accountable approver and a passing result in the production or release-candidate setup. Vendor acceptance covers only delivery of the contracted component; the relevant authority grants regulatory authorization. The operator's governance decides whether the assembled business is ready to launch, funded, controlled, tested, staffed, and recoverable.

Keep unresolved items visible. A planned license, pending merchant approval, sample game certificate, draft compliance procedure, untested restore, or unsigned data schedule is not a weaker form of completion; it is an open launch condition. The decision record should show what is complete, what is blocked, who accepted any residual risk, and what change would require the decision to be reopened.

Launch gates and the evidence expected at the decision meeting.
GatePass conditionDecision evidence
Market and authorizationThe exact entity, products, player locations, domains or apps, suppliers, and technical setup are covered or have the required approval or notification.Legal scope memo, issued authorization, register checks, conditions, and regulator correspondence. An application acknowledgment documents status only; it does not replace permission required before launch.
Entities and contractsPlayer, license, platform, games, payments, funds, data, compliance, support, incident, and exit responsibilities agree across documents and production flows.Signed contract set, responsibility map, due diligence, data terms, access rights, service levels, audit rights, and exit schedule.
Content and releaseOnly approved suppliers, titles, builds, channels, and configurations are in the release, with required testing and submissions complete.Games register, supplier and authorization records, test reports, submission records, release manifest, and rollback approval.
Payments and fundsThe casino entity has production capacity for every advertised method, withdrawals work, the required customer-funds treatment is documented and owner-signed, and reconciliations close. Regulator approval is a gate only where the applicable rule requires it.Merchant and provider evidence, production tests, PCI scope and validation route, bank and funds records, disclosures, and signed reconciliation.
AML and player protectionRequired checks, monitoring, cases, interventions, reporting, limits, exclusions, marketing controls, staffing, and operator oversight work end to end.Approved policies and risk assessment, rule inventory, simulation results, staff access and training evidence, QA, escalation, and management reporting.
Security, privacy, and recoveryThe release candidate meets the agreed controls, material defects are closed or explicitly accepted, incidents can be handled, and restoration has been demonstrated.Security and privacy acceptance, current findings and retests, incident exercise, backup and restore result, access review, and risk sign-off.
Live operations and exitNamed teams can support players, reconcile money, supervise suppliers, release changes, report events, preserve records, suspend service, and execute the initial exit steps.Runbooks, rotas and escalation contacts, control calendar, access records, service reporting, incident and exit exercises, and signed handover.

Sources for this section: [1], [2], [3], [5], [6], [7], [8], [9], [12], [13], [14], [15]

11

Operate the controls and keep a credible exit

The launch evidence pack becomes the operating control set. Keep authorizations, suppliers, games, payment routes, data flows, risk rules, access, security findings, reconciliations, incidents, and reporting obligations current. Material changes should reopen the affected legal analysis, testing, approvals, and acceptance evidence before release, not after a defect or regulator request.

Exit is part of operational resilience. The operator needs a tested path to preserve player access and balances, suspend affected products, move or close services lawfully, obtain usable data and records, continue mandatory retention, revoke access, and settle customer funds. Where the EU GDPR applies, Article 20 data portability is a defined data-subject right with conditions; it is not a substitute for a contractually required export of the complete operational record needed to migrate the casino.

  • + Domains, app accounts, certificates, keys, code and configuration rights, deployment artifacts, and infrastructure inventory
  • + Player, wallet, ledger, game, payment, KYC, AML, responsible-gambling, support, consent, communication, and audit records
  • + Documented schemas, field definitions, identifiers, timestamps, relationships, checksums, and reconciliation totals
  • + Open rounds, pending withdrawals, disputes, chargebacks, jackpots, bonuses, restricted accounts, exclusions, and customer-funds treatment
  • + Retention, legal hold, regulator access, privacy notices, processor deletion, access revocation, service continuity, and customer communication
  1. 1
    Run an owned control calendar

    Schedule license and supplier checks, regulatory submissions, game and payment reviews, reconciliations, access reviews, compliance QA, security work, backup and restore tests, incident exercises, and management decisions at the cadence required by the applicable rules and risk.

  2. 2
    Put every material change through impact review

    Check entity, ownership, market, product, domain, supplier, game, payment, data, infrastructure, security, and compliance changes for approval, notification, retest, contract, privacy, and operational consequences.

  3. 3
    Rehearse recovery and supplier exit

    Use a realistic dataset and open cases to test backup restoration, alternative operations, supplier suspension, data export, balance reconciliation, access revocation, and the handover of unresolved obligations.

  4. 4
    Close without abandoning players or evidence

    Plan withdrawals and customer-funds treatment, open rounds and disputes, regulator and player communications, mandatory records, processor instructions, data deletion after retention, and proof that privileged access was removed.

Test exit while the relationship is healthy

The first full export and exit exercise should not happen during a supplier dispute or outage. Treat a failed export, unowned domain, undocumented schema, unreconciled balance, or inaccessible compliance case as a current control defect.

Sources for this section: [2], [3], [6], [7], [12], [14]

FAQ

Should I choose a casino platform before choosing the target market?+

No. Player location, product, channel, entity, and technical setup determine the authorization and control requirements. A platform chosen first can force the wrong applicant, supplier chain, payment flow, hosting setup, or test plan. Freeze the market facts and authorization matrix first, then procure against them.

Sources: [1], [2]

Do I need my own online casino license?+

There is no universal answer. It depends on the target market, customer-facing entity, regulated activities, and delivery model. For Great Britain, providing remote gambling to British consumers requires a UKGC license even when the business is based abroad, and casino, host, and software activities are treated separately. Obtain target-jurisdiction advice on the exact facts rather than relying on a supplier's model name.

Sources: [1], [4]

Does a white-label agreement transfer regulatory responsibility to my brand?+

Do not assume that it does. In Great Britain, responsibility for white-label gambling sites remains with the license holder and cannot be transferred. Your contract still needs to define the brand's tasks, but the regulator-facing responsibility follows the applicable law and license, not a commercial allocation written as if it overrides them.

Sources: [3]

Does turnkey mean the license, games, payments, and compliance are included?+

No reliable conclusion follows from the word 'turnkey.' Require a schedule of legal entities, authorizations, included services, production dependencies, exclusions, data and money flows, acceptance evidence, and exit deliverables. A software license or compliant component does not by itself authorize the consumer-facing casino.

Sources: [4], [2]

How much does it cost to start an online casino?+

A single honest number does not exist before the market, entity, license route, product scope, delivery model, suppliers, payment terms, staffing, testing, security, working capital, reserves, and exit obligations are fixed. Build a line-item model from current regulator schedules, signed or validity-dated supplier quotes, payroll, tax advice, banking terms, and scenario assumptions. Keep one-time, recurring, usage-based, revenue-share, reserve, and contingent costs separate, and do not copy a vendor's headline setup fee as the project budget.

Sources: [1], [2], [7]

How long does an online casino launch take?+

There is no defensible universal launch range. The critical path depends on the jurisdiction and application completeness, ownership and funding review, operating policies, technical setup and audit, supplier and game evidence, production merchant approval, compliance operations, and defect closure. Plan from named dependencies and current authority or counterparty evidence, then update the forecast when one of those facts changes.

Sources: [2], [6]

If an aggregator offers a game, is it approved for my casino?+

Not necessarily. Commercial availability does not prove supplier authorization, market permission, channel coverage, build identity, testing, regulator submission, or inclusion in your controlled games register. Verify the chain and release evidence for the exact title and version before enabling it.

Sources: [4], [6], [5]

If the payment gateway is integrated, can the casino accept deposits?+

Message exchange in a tested setup is only one launch dependency. Launch also requires the correct entity's production merchant and acquiring route, production credentials, approved transaction and market scope, settlement and reserve terms, withdrawal handling, reconciliation, customer-funds treatment, and the applicable PCI validation path.

Sources: [13], [7]

Can the platform provider keep control of all player data?+

A provider can process and host data, but the legal roles, instructions, subprocessors, security, access, retention, export, incident, and deletion duties must be explicit. The operator should test that it can reconstruct and export the complete operational record. A data-subject portability feature is not the same as a full casino migration export.

Sources: [12], [14]

What is the final proof that the casino is ready to launch?+

A signed, dated go or no-go record tied to the exact release candidate and production entities. It should reference authorization, contracts, games, payments, customer funds, AML and player protection, testing, security, privacy, staffing, reconciliation, incident response, recovery, open defects, residual-risk approvals, and exit readiness. A vendor completion email is not a substitute.

Sources: [3], [5], [6], [14]

Sources

Primary documents and named publications used for the dated conclusions in this guide. Source links do not replace the requirements that apply to the exact entity, product, market, and contract.

Open 15 sources
  1. [1] Remote sector guidance

    UK Gambling Commission · Checked

  2. [2] Guidance Note: Application Process

    Malta Gaming Authority · Checked

  3. [3] Licensees' responsibilities for third parties

    UK Gambling Commission · Checked

  4. [4] Remote gambling software licence

    UK Gambling Commission · Checked

  5. [5] Remote gambling and software technical standards

    UK Gambling Commission · Checked

  6. [6] Testing strategy for compliance with remote gambling and software technical standards: procedure for testing

    UK Gambling Commission · Checked

  7. [7] Customer funds: segregation, disclosure to customers and reporting requirements

    UK Gambling Commission · Checked

  8. [8] Prevention of money laundering and combating terrorist financing: enhanced due diligence and ongoing monitoring

    UK Gambling Commission · Checked

  9. [9] Customer interaction guidance for remote gambling licensees

    UK Gambling Commission · Checked

  10. [10] Implementation extension for new deposit limit requirements

    UK Gambling Commission · Checked

  11. [11] The FATF Recommendations, as amended October 2025

    Financial Action Task Force · Checked

  12. [12] General Data Protection Regulation: consolidated text

    EUR-Lex · Checked

  13. [13] PCI DSS information for merchants

    PCI Security Standards Council · Checked

  14. [14] The NIST Cybersecurity Framework 2.0

    National Institute of Standards and Technology · Checked

  15. [15] OWASP Application Security Verification Standard 5.0

    OWASP Foundation · Checked

This guide is a procurement and operating-control framework, not legal, licensing, tax, accounting, payment, or security advice. Gambling, AML, data-protection, payment, advertising, consumer-protection, and technical rules vary by jurisdiction and change over time. Confirm the exact entity, player locations, products, channels, domains, suppliers, money flows, data flows, and release build with qualified local advisors, the relevant authorities, financial counterparties, and independent assessors before accepting players or funds.

More in Guides