Buyer-owned selection framework · no lead form

iGaming platform selection matrix

Select the procurement scope before comparing suppliers. Each scope below defines the evidence, acceptance condition and disqualifier that a buyer needs to resolve—without inventing one composite platform score or treating an unknown as a negative fact.

Open the scope matrix Download evidence matrix Build a shortlist

5 procurement scopes30 evidence requirementsLast materially updated 2026-08-13

The five scopes are not one product taxonomy

Turnkey and white-label describe delivery arrangements; modular PAM describes an architecture and engagement boundary; sportsbook and aggregation describe product procurement. They are compared here because each changes the buyer's evidence burden. A provider can enter more than one table, and the table sizes are neither rankings nor mutually exclusive shortlists.

Run the decision in the right order

Choose the procurement boundary

Decide whether you are awarding an integrated turnkey perimeter, a modular PAM core, a sportsbook service, casino aggregation, or a hosted white-label route. A provider can appear in several scopes because these choices are not mutually exclusive classifications.

Resolve disqualifiers

Test the permission chain, state authority, transaction integrity, control ownership, operational evidence, economics and exit rights that can make a proposal ineligible. Never average a failed gate into a feature total.

Use the site record as orientation

The provider tables show only current public projections: active verified credential relationships, public capability states, pricing and reliability readouts, and deployment records confirmed beyond the supplier.

Issue scope-specific evidence requests

Carry the requirement IDs into one response matrix. Replace every unknown with a buyer question and require the exact entity, product, market, configuration, test, exception, owner and contract destination.

Rules for reading the provider evidence tables

A recorded delivery model or capability decides which scope table a profile enters; it does not prove eligibility for an award.

Not confirmed remains an open diligence question. It is neither a supplier failure nor evidence that a feature is unsupported.

Market counts describe active verified credential relationships in the current site snapshot, not global licence counts or permission for the buyer's exact launch.

Published deployment records require evidence beyond a supplier-controlled claim. Zero records means the current site does not publish one, not that the supplier has no clients.

The matrix intentionally has no overall score, automatic winner or cross-scope rank. Award decisions must stay inside the chosen scope and the buyer's accepted gates.

Procurement scope

Turnkey iGaming platform

One prime supplier is expected to deliver the core account platform and coordinate most launch dependencies, while the operator remains accountable for regulated operation.

Buyer retains

Legal accountability, risk appetite, approval decisions, control acceptance, financial oversight, and the final go/no-go decision.

Supplier boundary to define

Named platform modules, integrations, managed services, environments, implementation responsibilities, and subcontractors must form one explicit delivery perimeter.

Swipe horizontally to view all columns.

Evidence requirements, acceptance conditions and disqualifiers for Turnkey iGaming platform
ID	Decision domain	Buyer decision	Required artifacts	Accept when	Disqualifier	Contract destination
TK-01	Permission chain	Can the exact supplier entity, product and operating arrangement support every proposed market and vertical?	Current authority records; entity and product map; operator dependencies; term dates; approval and change-control plan.	Each launch entity, product and market maps to a current permission or to a buyer-owned approval action with an accountable owner and stop condition.	Any launch-critical entity, product or permission route remains assumed, belongs to an unconnected group company, or cannot be completed before the corresponding launch gate.	Regulatory responsibility and conditions schedule
TK-02	Prime delivery perimeter	Which platform modules and third parties sit inside the supplier's accountable end-to-end service?	Product bill of materials; responsibility matrix; subcontractor register; integration ownership; escalation and service-boundary diagrams.	Every launch dependency has one accountable party, an interface owner, an acceptance test and a remedy without gaps between supplier and subcontractor obligations.	The supplier markets a turnkey service but excludes a launch-critical dependency from both delivery accountability and buyer-controlled ownership.	Services, subcontractors and responsibility schedule
TK-03	Wallet and control authority	Which system is authoritative for identity, balances, bonus liability, limits, exclusions, transaction history and regulatory reporting?	System-of-record map; wallet sequences; control precedence; reconciliation output; access model; witnessed failure and replay tests.	One authority is named for every state, conflict resolution is deterministic, and debit, credit, rollback, limit and exclusion tests reconcile end to end.	Competing systems can independently alter player eligibility or financial state without a deterministic authority, audit trail and reconciliation path.	Architecture, controls and reconciliation schedules
TK-04	Launch product set	Are the exact casino, live, sportsbook, bonus, CRM, fraud and reporting modules production-ready for this configuration?	Versioned module inventory; environment and market availability; configuration register; certification delta; acceptance scripts and results.	Every required module and substitute integration passes the buyer's exact market, version, data-flow and control tests in the proposed environment.	A launch-critical module is roadmap, demo-only, tied to another product version, or dependent on an integration with no accepted owner and test result.	Product scope and acceptance schedule
TK-05	Operational record	Can the supplier support the combined service boundary through incidents, recovery, peak load and supplier-chain failure?	Scoped incident history; component telemetry; RCA samples; capacity evidence; RTO/RPO tests; support rota; SLA formula, exclusions and remedies.	History and tests cover the proposed components and failure modes, while contractual measures can be reproduced from buyer-accessible records.	The supplier will not provide a bounded incident record, cannot demonstrate recovery of the proposed stack, or offers an SLA that cannot be measured or remedied.	SLA, resilience, support and incident schedule
TK-06	Economics and exit	Does the commercial perimeter cover every module, environment, third party, volume step, managed service, migration and exit event?	Three normalized demand scenarios; complete rate card; pass-through register; indexation; minimums; change rates; exit inventory and priced transition plan.	All proposals reconcile to the same scope and demand assumptions, and data extraction, transition assistance, residual fees and termination events are enforceable.	A material charge, revenue basis, third-party dependency, minimum commitment, data extraction right or termination cost remains undefined at award.	Charges, data portability and exit schedules

Current public evidence orientation

Shows profiles carrying a recorded Turnkey delivery-model label. That label is a discovery boundary, not proof that the proposed launch scope is ready. The 15 profile contexts below can overlap with other scopes. Open questions must be resolved against the exact proposed product and contract.

Browse the Turnkey provider hub

Altenar

Included because: Turnkey

Credential relationships

4 recorded markets: Alberta, Denmark, Malta (MGA), UK (UKGC). Permission kinds: B2B supplier approval.

PAM / core platform: Recorded
Reporting & BI: Not confirmed
Live casino: Not confirmed

Pricing transparency: Not recorded
Reliability record: Incident history unavailable for a complete count
Published non-supplier-only deployment records: 1

Open diligence questions

• Reporting & BI is not confirmed.
• Live casino is not confirmed.
• Public commercial structure is not recorded.

ID	Decision domain	Buyer decision	Required artifacts	Accept when	Disqualifier	Contract destination
PAM-01	State authority	Exactly which player, wallet, session, control, bonus and reporting states does the PAM own?	Field-level system-of-record map; write permissions; state transitions; override controls; immutable audit examples; retention rules.	Every mutable field has one authority, permitted writers are bounded, and conflicts, replay, correction and audit behaviour pass witnessed tests.	The proposed design permits ambiguous or competing authority over balance, identity, limit, exclusion or regulatory-reporting state.	Architecture and data-authority schedule
PAM-02	Interface contract	Can the PAM operate as a modular service across the required synchronous APIs, events, exports and administrative workflows?	Versioned specifications; event catalogue; idempotency and ordering rules; error model; limits; sandbox parity; deprecation policy; sample logs.	Buyer tests cover success, duplicate, late, out-of-order, timeout, partial-failure and version-change paths with deterministic recovery.	A critical state transition depends on a private manual process, undocumented interface, non-replayable event or change policy the buyer cannot test.	API, event and lifecycle schedule
PAM-03	Ledger and reconciliation	How do product, payment and bonus postings become one authoritative financial record?	Wallet protocols; journal model; idempotency retention; round and payment lifecycle; daily control totals; unmatched-item ageing and correction workflow.	All enabled transaction types post exactly once, preserve history, close to signed totals and expose every exception with an owner and ageing state.	The operator cannot independently reconcile balances and liabilities or recover a partial posting without direct database intervention.	Wallet, accounting and reconciliation schedule
PAM-04	Cross-supplier controls	Do limits, exclusions, AML actions, fraud decisions and responsible-gambling controls propagate across every connected product?	Control precedence; event timing; fail-closed rules; product acknowledgements; exception queues; audit output; multi-product test results.	A control change reaches and is enforced by every required product within an agreed bound, with deterministic treatment during dependency failure.	A launch product can accept activity after a mandatory player restriction because propagation, acknowledgement or fail-closed behaviour is unresolved.	Player-protection and financial-crime control schedule
PAM-05	Change isolation	Can either party upgrade a component without silently breaking events, reports, integrations or control semantics?	Compatibility policy; contract tests; schema registry; feature flags; release rings; rollback; end-of-life notices; dependency inventory.	Backward-compatibility and breaking-change rules are automated, release evidence is visible, and rollback preserves transaction and audit continuity.	The supplier can impose a breaking interface or data change without a tested migration path, adequate notice and buyer-controlled release gate.	Change, compatibility and release schedule
PAM-06	Portability	Can the operator extract a complete operational record and replace the PAM without reconstructing critical state from reports?	Canonical data dictionary; bulk and delta exports; attachments and audit trails; deletion rules; migration rehearsal; exit API and assistance plan.	A buyer-run rehearsal reconstructs active and historical state in a target schema, reconciles totals and preserves legally required lineage.	Critical balances, player-control history, transaction lineage, documents or configuration cannot be exported in a usable and contractually assured form.	Data rights, migration and exit schedule

ID	Decision domain	Buyer decision	Required artifacts	Accept when	Disqualifier	Contract destination
SB-01	Product permission	Does the exact supplier entity and sportsbook product hold the required permission or product approval in each proposed market?	Authority records; entity-product-market map; manufacturer, supplier and operator roles; term dates; certification and change submissions.	The proposed engine, delivery route and responsible entities reconcile to current market-specific permissions and the implementation schedule.	A group-level licence, unrelated product approval or pending filing is the only support for a launch-critical sportsbook role.	Sports-wagering permission and product schedule
SB-02	Engine and trading authority	Who owns the engine, compiles prices, accepts or rejects bets, changes limits and carries trading decisions?	Component and legal-role map; trading authority matrix; manual override controls; risk limits; feed lineage; decision and audit samples.	Every automated and human trading action has one accountable party, a bounded permission, timestamped input and reproducible audit trail.	Engine ownership, trading accountability or subcontracted feed and risk responsibilities remain materially ambiguous.	Sportsbook service and trading-responsibility schedule
SB-03	Bet lifecycle	Are placement, acceptance, cash-out, resettlement, cancellation, abandonment and dispute states deterministic?	Bet-state model; wallet sequences; idempotency; event and market identifiers; result lineage; rules versions; replay and resettlement tests.	Every bet and wallet movement reaches one explainable final state under duplicate, delayed, corrected, suspended and failed-dependency scenarios.	The supplier cannot reproduce the accepted price, rule, result, settlement and financial corrections for a disputed bet.	Bet lifecycle, settlement and rules schedule
SB-04	Feed and event integrity	How are event identity, feed conflict, latency, suspension, correction and abandonment controlled across suppliers?	Feed inventory; event mapping; freshness thresholds; conflict precedence; monitoring; suspension tests; correction workflow and audit output.	The system detects stale or conflicting data, suspends deterministically, records overrides and reconciles every correction to bets and balances.	A feed failure or event-identity conflict can continue accepting bets without a bounded automated or supervised control.	Data feeds, integrity and monitoring schedule
SB-05	Player and risk controls	Do player limits, exclusions, affordability, fraud, AML and trading-risk interventions work across pre-bet and in-play paths?	Control matrix; decision timing; limit hierarchy; acknowledgement events; fail-closed tests; manual-action permissions; audit and report samples.	Every mandatory control applies before acceptance within its required time bound and remains enforceable during partial platform failure.	A restricted player or disallowed wager can be accepted because risk, PAM and sportsbook control ownership or timing is unresolved.	Player protection, AML and risk-control schedule
SB-06	Peak resilience and economics	Can the proposed service and price survive event peaks, feed disruption, settlement bursts and managed-trading escalation?	Peak-load profile; capacity and failover tests; incident history; recovery objectives; support model; complete price basis and event-volume scenarios.	Capacity, recovery, support and price are tested against buyer volumes and event shapes, with measurable service levels and remedies.	The service has no accepted peak-load boundary, recovery evidence or comparable commercial basis for the proposed event and bet volumes.	Capacity, SLA, support and charges schedules

ID	Decision domain	Buyer decision	Required artifacts	Accept when	Disqualifier	Contract destination
AGG-01	Content permission	Can each proposed supplier, studio, game and aggregator role be used by the operator entity in the target market?	Entity and permission map; studio authorisations; game approval inventory; certificate/version mapping; jurisdiction and brand eligibility.	Every enabled game version traces through the aggregator and studio entities to the required current permissions and operator release approval.	A launch game or studio depends on a permission, certificate, entity connection or market approval that cannot be matched to the exact version.	Content eligibility and regulatory schedule
AGG-02	Wallet protocol	Is ledger authority, debit, credit, rollback, replay and open-round handling deterministic across every studio adapter?	Protocol versions; studio exception matrix; idempotency retention; sequence diagrams; open-round rules; failure, retry and rollback results.	Each adapter passes duplicate, timeout, late-result, rollback, resettlement and failover tests without an unmatched balance or round.	Any material studio path relies on unbounded retries, non-idempotent posting, silent balance correction or irrecoverable open rounds.	Wallet, round-state and protocol schedule
AGG-03	Release inventory	Can the buyer identify exactly which game binary, math, certificate, metadata, configuration and jurisdiction rule is live?	Immutable game/version IDs; certificates; RTP and configuration variants; release manifests; change notifications; disable and rollback workflow.	The live inventory reconciles to approved versions, changes are buyer-gated, and a single game or version can be disabled and rolled back safely.	The aggregator cannot produce a version-level live inventory or can change regulated game configuration without an accepted buyer release control.	Game inventory, release and change schedule
AGG-04	Financial reconciliation	Do the operator, aggregator and studio agree on rounds, stakes, wins, jackpots, bonuses, refunds, adjustments and settlement periods?	Transaction-level export; daily control totals; jackpot and bonus liability; unmatched-item ageing; correction entries; invoice-to-ledger reconciliation.	Independent buyer totals reconcile all three layers and every variance retains source transaction, reason, owner, action and closure evidence.	The buyer cannot independently reconstruct GGR and liabilities or resolve a variance below provider-level aggregate reports.	Financial records, settlement and invoice schedule
AGG-05	Failure containment	Can one studio, game, region or protocol fail without disabling unrelated content or corrupting wallet state?	Dependency topology; component health; isolation controls; circuit breakers; queue limits; studio-level incident history; recovery and replay tests.	Failures are detected and isolated at the smallest safe scope, player and financial states remain consistent, and recovery is observable and rehearsed.	A single dependency can create platform-wide content failure or financial uncertainty without a tested isolation and recovery path.	Resilience, incident and recovery schedule
AGG-06	Commercial chain	Are aggregator fees, studio charges, minimums, jackpots, promotional tools, certification, data and exit treatment comparable?	Per-studio and platform rate card; calculation basis; minimums; pass-throughs; excluded tools; content removal; data retention; direct-integration exit plan.	Every scenario reconciles invoice logic to wallet and game data, while content continuity, data access and transition rights survive termination.	A material studio charge, calculation basis, minimum, liability, content-removal consequence or exit restriction remains undefined.	Content charges, settlement and exit schedules

ID	Decision domain	Buyer decision	Required artifacts	Accept when	Disqualifier	Contract destination
WL-01	Legal operating model	Which entity is operator, licence holder, contracting party, merchant, funds holder and accountable party for each regulated duty?	Entity and responsibility map; authority records; player terms; funds flow; data roles; subcontractors; legal analysis for the exact market.	Every regulated and customer-facing role maps consistently across authority records, contracts, terms, payments, systems and operating procedures.	The arrangement depends on an assumed licence umbrella or leaves operator, funds, player-contract, merchant or data-controller identity inconsistent.	Legal entities and regulated-responsibility schedule
WL-02	Player and funds control	Who controls onboarding, KYC, balances, withdrawals, limits, exclusions, complaints, account closure and customer redress?	End-to-end operating procedures; decision rights; service targets; escalation; funds safeguarding; audit access; exception and complaint samples.	Each player and funds decision has one accountable entity, enforceable response time, buyer visibility and an evidence trail across supplier boundaries.	The buyer carries brand or legal exposure but cannot inspect, escalate or contractually control a critical player or funds decision.	Player operations, funds and complaints schedule
WL-03	Market and brand perimeter	Are domain, app, brand, product, language, payment, marketing and geographic boundaries approved and technically enforced?	Brand-market matrix; domain and app inventory; product eligibility; geo rules; payment routes; marketing approvals; release and change controls.	Only approved combinations can be configured or exposed, and every change requires the correct supplier, buyer and regulatory approvals.	A brand can accept players, payments or gameplay outside its approved entity, market, product or distribution boundary.	Brand, territory, product and distribution schedule
WL-04	Control operations	Can AML, fraud, responsible-gambling, payments, safer-gambling and reporting teams operate one coherent control framework?	Control ownership; thresholds; case workflow; data access; decision timing; reporting calendar; audit logs; breach and regulator-notification procedure.	Controls are tested on the proposed brand and products, material cases remain visible, and escalation and reporting duties are contractually allocated.	A regulated control is delegated without buyer visibility, auditable decisions, response commitments or a lawful responsibility allocation.	AML, safer-gambling, payments and reporting schedules
WL-05	Data and brand portability	What can the buyer retain and migrate if it changes platform, licence route or service model?	Ownership matrix; export schema; player consents; domain and app rights; creative and configuration inventory; migration rehearsal; deletion certificates.	The buyer can lawfully transfer the agreed brand assets and complete player, balance, control, transaction and audit records within tested time bounds.	Termination strands the brand or makes material player, balance, control or transaction history unavailable, unusable or legally non-transferable.	IP, data rights, migration and exit schedule
WL-06	Unit economics and termination	Does the model remain viable after revenue share, payment cost, content, bonuses, tax, chargebacks, support, minimums and exit costs?	NGR waterfall; three volume and mix scenarios; pass-through register; negative-month treatment; reserves; minimums; suspension and termination model.	Both parties reproduce every scenario from the same definitions and data, with bounded liabilities and an operable termination transition.	Revenue basis, deductions, negative carry, reserves, minimums, pass-throughs, suspension rights or post-termination liabilities remain ambiguous.	Commercial definitions, charges and termination schedules

iGaming platform selection matrix

Run the decision in the right order

Rules for reading the provider evidence tables

Turnkey iGaming platform

Current public evidence orientation

Modular PAM / API platform

Current public evidence orientation

Sportsbook platform

Current public evidence orientation

Casino game aggregator

Current public evidence orientation

White-label operating platform

Current public evidence orientation

Carry the result into evidence and contract work