iGaming platform RFP checklist

Name every contracting, supplying, hosting, support, payment, and operating legal entity in the proposed structure.

Accept when: The answer uses full legal names and company identifiers, and distinguishes group brands from contracting entities.

Map legal entity × product or module × jurisdiction × credential, including status, scope, source, and checked date.

Accept when: Each row supports the proposed activity and exposes any product, entity, or market limitation; the buyer can verify the source independently.

Identify the operator of record, licence holder, party named in player terms, holder of player funds, and owner of regulatory reporting for each market.

Accept when: No responsibility is implied by the labels white-label, turnkey, managed, or licensed; every role is assigned in the responsibility schedule.

List buyer licences, market access, product approvals, registrations, policies, and third-party appointments that remain prerequisites to launch.

Accept when: The supplier separates its deliverables from buyer and regulator dependencies, with an owner and decision date for each dependency.

Provide corporate-registration evidence, ownership or control details, signatory authority, and the proposed contracting chain.

Accept when: The entities in the proposal, credentials, invoices, data-processing terms, and contract schedules reconcile.

Explain any reliance on affiliates, partners, resellers, sublicences, market-access counterparties, or third-party operating structures.

Accept when: The underlying agreement, permission, duration, termination exposure, and replacement plan are disclosed for each dependency.

Define the implementation baseline: products, markets, brands, channels, environments, integrations, data migration, custom work, and exclusions.

Accept when: The delivery plan and price use the same baseline, and every excluded item has an owner or later decision point.

Provide a milestone plan with deliverables, entry criteria, owners, dependencies, dates, and buyer decision deadlines.

Accept when: The plan identifies the critical path and separates supplier work from buyer, regulator, content, payment, and other third-party work.

Include licensing, payments, game or sportsbook approvals, front end, data migration, security review, testing, training, and operational readiness in the critical path.

Accept when: No launch-critical dependency sits outside the integrated plan merely because another party owns it.

Define objective acceptance criteria, test data, evidence, defect severity, retest rules, and acceptance authority for each deliverable.

Accept when: Payment is tied to accepted deliverables where appropriate, and silence or production use does not create accidental acceptance.

State the re-planning, cure, fee, service-credit, and termination consequences for supplier-caused delay or failed acceptance.

Accept when: The contract distinguishes supplier delay, buyer delay, dependency delay, and mutually agreed change, with evidence and notice rules.

Document pilot, migration rehearsal, cutover, rollback, go/no-go authority, hypercare, and transition into business-as-usual support.

Accept when: Named people own each decision, rollback is practical, and open defects have an agreed treatment before launch.

Itemise setup, configuration, custom development, integrations, migration, platform, hosting, minimums, revenue share, usage, third-party, support, and exit charges.

Accept when: Every charge has a unit, trigger, frequency, currency, tax treatment, responsible entity, and included volume or service level.

Define every commercial measure, including the revenue base, deductions, netting, reporting source, dispute process, and invoice timing.

Accept when: The buyer can independently reproduce a sample invoice from operational data and the contractual definitions.

Disclose pass-through costs, supplier mark-ups, rebates, credits, foreign-exchange rules, taxes, minimums, and third-party price-change exposure.

Accept when: The contract states which changes can be passed through, what evidence is supplied, and whether the buyer receives corresponding rebates or credits.

Price downside, baseline, and growth scenarios using the buyer's stated brands, markets, modules, volumes, payment mix, support, and term.

Accept when: The same workbook and assumptions are used for every supplier, with one-off, recurring, variable, and contingent costs separated.

State out-of-scope rates, change-control pricing, indexation, tier resets, ramp periods, minimum-commitment treatment, and audit rights.

Accept when: No material price adjustment can be applied without a defined formula, evidence, notice, and buyer remedy.

Include termination, parallel run, data export, migration assistance, knowledge transfer, account transfer, and deletion charges.

Accept when: Exit costs are priced or capped before signature and feed the same total-cost model as implementation and operation.

Define each measured component, service boundary, formula, data source, measurement interval, reporting owner, and dispute process.

Accept when: The measure covers the buyer-critical journey and cannot be satisfied while a material dependent component is unavailable.

State service windows, maintenance allowances, exclusions, force-majeure treatment, third-party dependencies, and degraded-service rules.

Accept when: Exclusions are narrow, evidenced, time-bounded, and do not remove failures that the supplier can control or mitigate.

Define severity by user and business impact, with acknowledgement, update, workaround, restoration, resolution, and root-cause targets.

Accept when: Severity cannot be unilaterally downgraded without evidence and the response clock is clear across support hours and time zones.

Set recovery point and recovery time objectives for each critical service, plus backup, failover, restoration, and disaster-recovery test obligations.

Accept when: The objectives match the architecture and the supplier supplies dated test results, findings, remediation, and next-test dates.

Set credits, fee-at-risk, cure plans, escalation, and termination rights for missed targets, repeated breach, or a material incident.

Accept when: Remedies are claimable from supplier reporting, are not the sole remedy for severe failures, and address patterns as well as single months.

Provide a defined-period service history: measured results, severity-one and severity-two incidents, impact, cause, restoration, and corrective actions.

Accept when: Advertised, proposed contractual, and observed measures are labelled separately and use comparable component definitions.

Map controller, joint-controller, and processor roles by data flow, purpose, legal entity, product, and jurisdiction.

Accept when: The data terms match the actual operating model, player terms, integrations, support access, and regulatory responsibilities.

Define permitted and prohibited supplier uses of player, transaction, behavioural, support, derived, aggregated, and model-training data.

Accept when: Use is limited to agreed purposes; sale, cross-client activation, marketing, and training use require explicit treatment rather than silence.

Document residency, transfers, retention, legal holds, deletion, backups, subprocessors, and access locations for every material dataset.

Accept when: Requirements are mapped to the proposed hosting and support model and changes follow contractual notice and control procedures.

Specify buyer access to player, wallet, ledger, bet, game, payment, bonus, consent, KYC, AML, safer-gambling, support, and audit records.

Accept when: APIs, streams, reports, audit logs, latency, history, rate limits, schemas, environments, and access costs are stated per record type.

Define full and incremental export content, format, schema, identifiers, frequency, encryption, delivery method, validation, and cost.

Accept when: The export supports reconciliation and migration without relying on undocumented supplier transformation or manual reconstruction.

Run a representative test export and reconciliation before signature, then repeat it on a contractual schedule and before exit.

Accept when: The buyer receives the test files, schema, reconciliation result, exceptions, remediation plan, and repeat-test right.

Classify supplier background technology, buyer materials, custom code, configuration, adapters, content, design, data, and documentation.

Accept when: Ownership, licence scope, territory, duration, transfer, modification, sublicensing, and post-termination use are stated for each class.

Assign control of source repositories, build and deployment pipelines, domains, certificates, app-store accounts, analytics, tags, cloud accounts, and secrets.

Accept when: The buyer has the access needed for its operating model and a documented transfer or continuity path for supplier-controlled accounts.

Define delivery, documentation, support, reuse, maintenance, escrow, and continuity rights for custom work and buyer-funded integrations.

Accept when: The rights support the buyer's intended operation and exit; any supplier reuse or third-party restriction is explicit and priced.

Document API coverage, authentication, environments, limits, service levels, versioning, deprecation, backward compatibility, and change notice.

Accept when: Critical integrations can be built and maintained against stable documentation, with enough notice and support to adopt breaking changes.

List every integration, adapter, configuration set, theme, rule, report, and operational document needed to run or migrate the service.

Accept when: The responsibility and portability of each asset are assigned; no critical asset exists only in an individual or supplier-controlled workspace.

Define product-roadmap governance, custom-change control, security patches, regression testing, and compatibility of custom work with upgrades.

Accept when: The buyer can assess the cost and operational impact of a change before approval and is protected from avoidable customisation dead ends.

Provide current independent audit or certification reports with entity, service, system, location, period, exclusions, exceptions, and remediation scope.

Accept when: Coverage maps to the proposed service and material exceptions have owners, deadlines, compensating controls, and closure evidence.

Provide recent penetration-test scope and results for relevant applications, APIs, infrastructure, and tenant boundaries, plus remediation status.

Accept when: Testing is independent, critical paths are in scope, material findings are retested, and residual risk is disclosed.

Describe identity, privileged access, multifactor authentication, least privilege, segregation, joiner-mover-leaver, logging, and review controls.

Accept when: Supplier, buyer, support, and emergency access are separated and produce retained, buyer-accessible audit evidence where required.

Describe encryption in transit and at rest, key ownership and rotation, secrets management, backups, immutability, and restoration controls.

Accept when: Algorithms, key boundaries, access, rotation, backup scope, retention, and restore testing match the proposed architecture.

Define security-incident detection, severity, notice, updates, evidence preservation, regulator and player support, forensics, and post-incident review.

Accept when: Notification starts from a clear trigger, is time-bounded, and gives the buyer the information and cooperation needed to meet its obligations.

Map hosting regions, availability zones, tenant model, dependencies, failover, backup, recovery objectives, capacity, and disaster-recovery testing.

Accept when: The design, SLA, data-location commitments, test evidence, and business-continuity plan describe the same production service.

Provide the subprocessor and material technology-supplier register, services, data, locations, assurance, change notice, objection, and replacement process.

Accept when: The buyer can evaluate changes before they take effect and has a proportionate remedy if an unacceptable dependency cannot be replaced.

Build a launch matrix by market, legal entity, brand, product, supplier, credential or approval, status, owner, dependency, cost, and target date.

Accept when: Every launch-critical row is either ready with scoped evidence or has an owned approval and activation path in the implementation plan.

For casino, list required studios and titles by market, permitted entity, certification or approval, RTP or configuration, device, restriction, and commercial route.

Accept when: The proposed launch set—not the supplier's global catalogue—is confirmed, priced, approved, and technically available for the target setup.

For sportsbook, define feeds, trading and risk model, markets and event types, integrity controls, settlement and void rules, restrictions, and approvals.

Accept when: The exact managed or operator-controlled scope, data dependencies, pricing, jurisdictional constraints, and incident responsibilities are documented.

For payments, map PSP, method, acquiring or merchant entity, country, currency, flow, settlement, reserve, chargeback, refund, reporting, and approval status.

Accept when: Each required deposit and withdrawal flow has confirmed onboarding ownership, technical availability, settlement economics, and operational controls.

Assign content, feed, and PSP contracting, certification, onboarding, integration, testing, monitoring, support, invoicing, and replacement responsibilities.

Accept when: The responsibility schedule and pricing model capture every party needed for the launch and ongoing service.

Label each item as production-ready for the proposed scope, requiring configuration, requiring contracting or approval, in development, roadmap, or unavailable.

Accept when: Roadmap and unapproved items are treated as unavailable for the award decision unless the buyer explicitly accepts that gap.

State support hours, time zones, languages, channels, response coverage, monitoring coverage, and any after-hours restrictions by service tier.

Accept when: The proposed tier covers the buyer's operating hours and critical services without relying on unpriced or undefined escalation.

Assign L1, L2, and L3 responsibilities across buyer, supplier, content, payment, data, hosting, and other third parties.

Accept when: A single operating matrix defines intake, diagnosis, ownership, hand-off, communication, workaround, resolution, and closure.

Provide severity, escalation, duty-manager, executive escalation, regulator-support, and emergency-change paths with named roles and authority.

Accept when: Contacts are maintained, tested, and empowered to make time-critical decisions; escalation does not reset the service clock.

Define monitoring, alerting, ticketing, status communication, incident, problem, release, change, and maintenance processes.

Accept when: The buyer receives timely operational visibility and can audit ticket, incident, change, and service-performance records.

Scope implementation support, launch hypercare, training, runbooks, knowledge transfer, service transition, and refresher training.

Accept when: Deliverables, audiences, timing, acceptance, materials, recordings, environments, and extra charges are stated.

Define service reviews, roadmap and capacity governance, risk and action logs, change prioritisation, and standard versus premium account-management scope.

Accept when: Meeting cadence, participants, inputs, decisions, records, and pricing match the level of governance assumed in the proposal.

Define signature, effective, implementation, acceptance, launch, billing, minimum-commitment, initial-term, renewal, and expiry dates.

Accept when: No fee, minimum, renewal, or notice period starts from an ambiguous event or before the corresponding service is accepted.

State ramp periods, minimum fees or volumes, tiers, shortfall treatment, carry-forward, credits, true-ups, and consequences of market delay.

Accept when: Downside, delayed-launch, baseline, and growth outcomes can be reproduced in the commercial model.

Set renewal mechanics, notice windows, price review, indexation, currency, foreign-exchange, tax, third-party change, and rejection or termination rights.

Accept when: Dates and formulas are explicit, reminders are operationally manageable, and material changes give the buyer a proportionate remedy.

Define exclusivity by product, module, content, payment method, jurisdiction, channel, brand, entity, duration, performance condition, and exception.

Accept when: There is no implied group-wide or future-market restriction, and failure to perform releases the affected exclusivity.

Define assignment, change of control, subcontracting, affiliate use, novation, divestment, new-brand, and new-jurisdiction rights.

Accept when: The contract supports foreseeable corporate and operating changes without unpriced consent leverage or accidental termination.

Limit suspension rights by trigger, affected service, notice, cure, proportionality, regulatory need, player protection, data access, and continuity.

Accept when: Suspension is no broader or longer than necessary and preserves access needed to protect players, reconcile funds, and comply with obligations.

Define termination rights, triggers, notice, cure, insolvency, regulatory failure, security event, repeated SLA breach, illegality, and force-majeure longstop.

Accept when: Critical failures create usable rights and the buyer is not forced to remain solely because migration is operationally impossible.

State fees, refunds, prepaid amounts, minimums, work in progress, disputes, player balances, reserves, settlements, and in-flight transactions on exit.

Accept when: Financial treatment is defined for normal expiry, buyer convenience, supplier breach, regulatory exit, and insolvency scenarios.

Set transition period, service levels, change limits, parallel run, migration support, knowledge transfer, named resources, rates, and cooperation with a successor.

Accept when: The period and resource commitment match a realistic migration plan and cannot be withheld because the supplier is being replaced.

Define full and incremental exports, schemas, identifiers, history, media, documents, audit records, delivery timing, encryption, validation, and reconciliation.

Accept when: The buyer can run parallel validation, correct exceptions, and receive final deltas before service and access end.

List code, configuration, domains, certificates, accounts, credentials, content, integrations, reports, runbooks, and other assets to transfer or continue.

Accept when: Each asset has an owner, transfer mechanism, dependency, delivery format, date, cost, and fallback if direct transfer is impossible.

Define post-exit access, retention, legal hold, return, deletion, backup expiry, deletion certificate, audit, confidentiality, and residual licences.

Accept when: The schedule preserves required records and access while creating a verifiable end state for data and supplier rights.

Run a tabletop exit before signature using a named scenario, successor, timeline, data set, asset list, responsibilities, and continuity constraints.

Accept when: Gaps become contract actions with owners and dates; the exit schedule is updated before award rather than deferred to termination.