iGaming platform RFP template and evidence checklist

What should an iGaming platform RFP accomplish?

An iGaming platform RFP should produce comparable evidence about fit, scope, responsibility, implementation, operation, cost, risk, and exit. It should also let a supplier decline or qualify requirements rather than disguising uncertainty behind a blanket “yes.”

Before issuing it, use the build, buy, or integrate framework to decide which capabilities are candidates for external delivery. Assign one owner to the RFP version, question log, response format, scoring record, and conflict process.

Section 1 — Business and market scope

State the business model, intended customers, products, launch definition, target jurisdictions, entity and license assumptions, languages, currencies, channels, expected operating model, and phased roadmap. Separate confirmed requirements from decisions that still need discovery.

Ask the supplier to identify jurisdictional exclusions, product constraints, third parties, approvals, and assumptions. Require qualified review for legal or regulatory conclusions.

Section 2 — Capability and responsibility matrix

List each required capability and ask whether it is native, configured, custom, integrated, partner-delivered, roadmap, or unsupported. For every included capability, record who owns configuration, data, testing, operation, support, change, and evidence.

Include accounts, identity, wallet or ledger, payments, content, games or betting, promotions, responsible-gambling controls, reporting, back office, customer operations, data, security, and observability as applicable.

Section 3 — Architecture and integration evidence

Request a current architecture, deployment model, tenancy boundary, data-flow diagram, interface catalog, authentication model, event model, versioning policy, limits, sandbox approach, failure behavior, retry and idempotency rules, and observability contract.

Use the RGS, aggregator, platform, and operator explainer to identify boundaries that often disappear inside commercial labels.

Section 4 — Security, privacy, and control evidence

Ask for the applicable control framework, independent assessment scope and date, vulnerability-management process, secure-development controls, access model, encryption and key responsibilities, incident process, recovery evidence, subprocessors, locations, retention, deletion, and customer audit rights.

Require the supplier to distinguish organization-wide evidence from evidence that covers the proposed product, hosting model, and services.

Section 5 — Delivery, migration, and acceptance

Ask for phases, deliverables, dependencies, staffing, governance, environments, configuration process, data migration, integration plan, testing, evidence preparation, training, cutover, rollback, hypercare, and acceptance criteria.

Require a responsibility matrix and a sample delivery plan based on the stated assumptions. A timeline without buyer staffing, external approvals, and decision deadlines is incomplete.

Section 6 — Service operation and incident ownership

Define service levels by critical journey, support hours, severity, response, restoration, communication, maintenance, capacity, data reconciliation, monitoring, recovery objectives, and evidence retention. Ask for recent, appropriately redacted proof that recovery and incident processes have been exercised.

Section 7 — Commercials, change, and exit

Normalize setup, license, usage, minimums, third-party fees, environments, support, professional services, travel, taxes, price changes, and termination costs. Ask how forecast errors and traffic spikes affect charges.

Require contract positions on ownership, license rights, data export, configuration export, source access where applicable, transition assistance, deletion evidence, service continuity, and the cost and time of exit.

What response format makes proposals comparable?

Field	Required response
Requirement	Unique ID and exact question
Position	Meets, partially meets, roadmap, partner, or does not meet
Evidence	Document, demonstration, environment, customer reference, or test
Assumptions	Buyer, supplier, third-party, market, and timing dependencies
Exception	Gap, workaround, consequence, and proposed resolution
Commercial impact	Included, optional, usage-based, or separately priced
Owner and date	Accountable respondent and validity date

Do not score an unanswered requirement as neutral. Mark it unknown, request clarification, and preserve the response history.

How should the final decision be recorded?

Record the selected model and supplier, rejected alternatives, decisive evidence, gaps, conditions, total-cost range, implementation owners, contract exceptions, review triggers, and exit plan. The platform delivery-model comparison provides a parallel decision view.

If a custom or hybrid platform is in scope, Wizards describes its platform-development services. Evaluate that option through the same evidence request as every other supplier; Wizards operates GEN, and that relationship does not waive the methodology.