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.

Keep a requirements register with stable IDs and a dated change log. If a requirement changes after issue, send the same clarification to every participating supplier and record whether price, timing, evidence, or risk changed. Comparability depends on a common question and response state, not merely a common deadline.

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.

Do not accept “partner ecosystem” as an ownership answer. Name the contracted party, underlying service, integration owner, data recipient, evidence source, support route, change process, replacement path, and consequence if the partner is unavailable or removed.

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.

Translate those interface questions into wallet retry and rollback acceptance cases when the scope includes a seamless wallet. Request both the ledger result and the caller response for each injected failure.

Require a timed audit-log and incident-reconstruction drill for material cross-system events. A logging or dashboard promise is incomplete unless the accountable team can map identities, explain time skew, detect evidence access or alteration, and retrieve the scoped record.

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.

GLI’s current catalogue demonstrates why the request needs exact product and jurisdiction scope: it lists separate standards for interactive gaming systems, client-server systems, event wagering, security and change management, and says each jurisdiction retains authority over its standards. The catalogue does not establish which standard, approval, test plan or certification applies to a buyer’s project.

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.

For a bounded Great Britain example, the UK Gambling Commission says relevant remote operating and gambling-software licence holders must comply with its remote technical standards and testing requirements. Use that as a prompt to ask who owns the applicable licence, product version, testing scope, evidence and change process. Do not treat it as a universal market rule or as evidence that selecting a supplier transfers accountability.

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.

NIST’s current supply-chain guidance supplies a useful technology-procurement lifecycle: define requirements, understand how products and services are developed, integrated and deployed, assess risk, monitor the relationship, and preserve mitigation or termination paths. GEN applies that lifecycle as a general procurement control, not as an iGaming licence, certification or legal conclusion.

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.

Normalize commercials against explicit usage scenarios and a shared currency and time horizon. Separate setup, recurring, minimum, variable, pass-through, environment, support, professional-service, change and exit charges. Preserve exclusions and confidence ranges; a lower headline fee with different scope is not necessarily a lower comparable cost.

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.

Frequently asked questions

What is the minimum useful platform RFP?

At minimum, publish a versioned business and market scope, capability and responsibility matrix, architecture and interface request, control and evidence requirements, delivery and acceptance plan, service model, normalized commercial template, response states, decision owners, and exit requirements. Separate confirmed facts, assumptions, and unresolved decisions.

Should suppliers answer each requirement yes or no?

No. Require a normalized state such as meets, partially meets, roadmap, partner-delivered, or does not meet, followed by evidence, assumptions, exceptions, commercial impact, an accountable respondent, and a validity date. An unsupported “yes” is not comparable evidence.

How should platform prices be compared?

Apply the same usage scenarios, scope, currency, tax treatment, time horizon, environments, support level, third-party assumptions, change volume, and exit scenario to every response. Compare ranges and cost drivers as well as totals, and keep excluded or separately priced work visible.

Does a supplier certification prove the proposed platform is compliant?

No. Ask which organization, product, version, hosting model, interfaces, services, locations, and assessment period the evidence covers, then map it to the applicable authority and buyer obligations. Certification can support diligence; it does not prove that the proposed configuration or operating process is acceptable or transfer the buyer’s accountability.