Kody Nexov
Published 
Original research - checked 2026-07-25
Research question
Which launch responsibilities remain with the operator, and what evidence should close each white-label dependency before go-live?
Methodology
- Scope: the named product sample or control areas in the evidence matrix below.
- Sources: current official supplier pages, regulators, government standards, open standards, and testing guidance.
- Classification: Yes is explicit support; Partial is incomplete support; Not found is no evidence in the reviewed public source; Unknown is not evaluated.
- Checked: 2026-07-25. This is a point-in-time public-evidence record.
- No inference: a general standard does not prove a supplier implementation, and a missing public disclosure does not prove a missing capability.
Evidence matrix
| Launch workstream | Primary anchor | Public support | Evidence before launch | Acceptance gate | Unknown until | Primary source |
|---|---|---|---|---|---|---|
| Licence and market scope | UKGC RTS | Partial | Entity, product, market, licence, and supplier responsibility map | Counsel and compliance approve the exact model | Local authority and contract confirm scope | UK Gambling Commission |
| Product and retained duties | Supplier product pages | Partial | Included, optional, partner, and operator-owned RACI | Every critical workflow has one accountable owner | Proposal and contract fix the boundary | BetConstruct |
| Software testing and release | UKGC testing strategy | Yes | Applicable test plan, evidence, approvals, and release controls | Critical tests pass with retained records | Market rules determine required assurance | UK Gambling Commission |
| AML and customer due diligence | FATF Recommendations | Yes | Risk assessment, CDD, monitoring, cases, reporting, and recordkeeping | Normal, high-risk, and exception cases are traceable | Local law and operating model fix controls | FATF Recommendations |
| Payment security | PCI DSS | Yes | Payment flow, PCI scope, PSP roles, reconciliation, and incident ownership | Money and card-data flows reconcile under failure | Payment design determines applicability | PCI Security Standards Council |
| Application security | OWASP ASVS | Yes | Versioned requirements, independent test results, and remediation | Agreed controls pass on the release candidate | Buyer sets risk-appropriate verification level | OWASP |
| Reliability and incident response | AWS Reliability Pillar | Yes | SLOs, capacity, dependencies, recovery objectives, and drills | Peak and dependency-failure exercises pass | Contract supplies measured commitments | AWS Well-Architected |
| Data and exit | ICO controller-processor guidance | Partial | Roles, instructions, subprocessors, export, deletion, audit, and transition terms | Bulk export and termination runbook are tested | Contract and data map define full scope | UK ICO |
Findings
1. White label does not remove operator accountability
The retained duty depends on entity, licence, market, product, data role, and contract; the label alone cannot define it.
2. Launch evidence spans several control systems
Product configuration, testing, AML, payments, security, operations, data, and exit need separate owners and gates.
3. Supplier scope is proposal-specific
Official product pages help identify a delivery model, but the precise included services and responsibilities remain commercial evidence.
4. Exit belongs in the launch plan
Data export, transition, deletion, and replacement support should be proven before dependency becomes operational.
How to use the evidence
- Remove fields that are not applicable to the target entity, market, product, and operating model; document why.
- Assign one accountable owner and one evidence artifact or test to every retained field.
- Keep Yes, Partial, Not found, and Unknown separate through RFP, demo, test, reference, and contract review.
- Convert supplier-specific gaps into versioned proposal, implementation, SLA, data, security, and exit schedules.
- Re-check source versions and effective dates before a procurement or launch decision.
Limitations
This crosswalk is not legal advice and does not define a universal white-label licence model. Requirements change by entity, jurisdiction, product, payment flow, supplier role, data role, and contract.
Primary sources
- BetConstruct - official white-label iGaming solution - Supplier-published white-label casino and sportsbook proposition. Private scope, commercials, service levels, and implementation evidence remain outside the page.
- Playtech 2025 annual report - business model - Supplier-reported platform, content, services, SaaS, conventional B2B licence, and structured-agreement delivery models.
- UK Gambling Commission - Remote gambling and software technical standards - Great Britain remote gambling software controls and current technical-standard verification questions.
- UK Gambling Commission - Testing strategy for remote gambling software - Testing, release, audit, change-control, and independent-assurance expectations for relevant Great Britain licensees.
- FATF Recommendations - Risk-based AML/CFT, customer due diligence, monitoring, recordkeeping, reporting, and country-implementation questions.
- PCI Security Standards Council - PCI DSS - Payment-account data security requirements for relevant merchants, processors, service providers, and connected systems.
- OWASP - Application Security Verification Standard - Versioned and testable web-application security requirements that can be used in procurement and verification.
- AWS Well-Architected - Reliability Pillar - Reliability design, failure recovery, change management, capacity, testing, and dependency-management questions.
- UK ICO - Contracts and liabilities between controllers and processors - Controller-processor contract fields, instructions, confidentiality, security, sub-processors, assistance, audit, and end-of-contract provisions.
Frequently asked questions
Does a Yes classification prove that a supplier complies?
No. Yes means the cited primary source explicitly supports the control or disclosure field. Supplier implementation still requires current product evidence and buyer verification.
Does Not found mean a capability is absent?
No. It means the reviewed public sources did not expose the evidence. Authenticated documentation, tests, proposals, or contracts may change the classification.
Can the CSV be used as an RFP starting point?
Yes, after adapting applicability, ownership, evidence, tests, and legal requirements to the target entity, jurisdiction, product, and operating model.
Concept map
Related concepts and decision guides
- research
- Use dated primary-source crosswalks and downloadable evidence matrices to turn software claims into buyer-owned verification tasks.
- Crypto Casino Control Crosswalk 2026 guide
- Map current FATF, gambling-regulator, payment-security, and application-security sources to crypto casino control evidence without presenting no-KYC or anonymity as a compliance...
- Crypto Casino Software guide
- Scope: This page explains the technology infrastructure used to build cryptocurrency-enabled iGaming platforms, including software architecture, security, and compliance capabil...
- White Label Casino Solutions for Online Gambling Operators comparison
- White label casino solutions enable businesses to launch online casinos without building proprietary software or infrastructure.
- White Label Casino Operator Responsibilities
- Separate provider services from the legal and operational duties that remain with the operator.
Evidence layer
Primary references and verification limits
Sources were checked on . They support the standards and verification questions used in this guide. They do not prove a supplier-specific price, market eligibility, implementation result, or private product claim; buyers should request current, versioned evidence for those points.
- BetConstruct - official white-label iGaming solution Supplier. Supplier-published white-label casino and sportsbook proposition. Private scope, commercials, service levels, and implementation evidence remain outside the page.
- Playtech 2025 annual report - business model Corporate filing. Supplier-reported platform, content, services, SaaS, conventional B2B licence, and structured-agreement delivery models.
- UK Gambling Commission — Remote gambling and software technical standards Regulator. Remote gambling software controls, security requirements, player-facing technical controls, and jurisdiction-specific verification questions.
- UK Gambling Commission — Testing strategy for remote gambling software Regulator. Testing, release control, audit evidence, change management, independent review, and production assurance questions.
- FATF Recommendations Intergovernmental standard setter. Risk-based AML/CFT controls, customer due diligence, monitoring, recordkeeping, and country-specific implementation questions.
- PCI Security Standards Council — PCI DSS Industry standards body. Payment account data security requirements for merchants, processors, service providers, and systems that can affect the cardholder data environment.
- OWASP - Application Security Verification Standard Open application-security standard. Versioned and testable web-application security requirements that can be used in procurement and verification.
- AWS Well-Architected - Reliability Pillar Cloud architecture guidance. Reliability design, failure recovery, change management, capacity, testing, and dependency-management questions.
- UK ICO - Contracts and liabilities between controllers and processors Data-protection regulator. Controller-processor contract fields, instructions, confidentiality, security, sub-processors, assistance, audit, and end-of-contract provisions.
