Lottery Platform Provider Evaluation Checklist: A Practical RFP Brief

Compare lottery platform providers using workflow requirements, ownership questions, demo scenarios and measurable acceptance criteria.

A lottery platform request for proposal (RFP) should describe the operator's workflows, integrations, data access, controls, delivery responsibilities and acceptance evidence. Separate mandatory launch requirements from preferences, ask each provider how they will be delivered, and test the difficult scenarios before committing. The result should be a versioned requirements brief that carries through to the contract and implementation plan.

This checklist helps a buying team prepare that brief and compare responses. It does not rank vendors or assume that a particular platform already supports the capabilities listed below. Each item is a requirement to investigate and verify.

1. Define the operating scope before requesting a demo

Start with the decisions your project has already made, the assumptions that remain open and the people authorised to resolve them. Record:

• Intended products: external-draw tickets, your own draws, Keno, custom games or the specific mix you need.
• Intended customer markets, brands, languages, currencies, devices and distribution channels.
• The entities and parties expected to operate the brand, provide the platform and handle each external service.
• Launch phases, estimated transaction volumes, expected peak periods and the evidence behind those estimates.
• Existing systems or data that must be connected, retained or migrated.
• Operating restrictions and requirements supplied by the operator's qualified advisers and relevant counterparties.
• Budget assumptions, decision owners and the dependencies that may affect delivery dates.

An unresolved input should have an owner and a decision date. Recording it as an assumption is more useful than asking a provider to quote an apparently complete scope that will change during implementation.

Selecting a platform does not resolve market permissions, licensing or tax questions. Have the appropriate advisers define those requirements, then translate them into the workflows, system controls and evidence the RFP must cover.

2. Write requirements as workflows and acceptance evidence

A feature name rarely explains the outcome you need. For example, “wallet” does not tell a provider how balances, settlements, reversals and disputed transactions must behave.

Use a requirements matrix that connects the journey to the evidence you will accept:

Give each requirement an identifier, priority, acceptance owner and dependency. Add a short explanation of why it matters. Product, finance, security, compliance and customer-operations owners should be able to review their sections without needing to infer the intended workflow from a list of module names.

For payment-specific requirements, use the lottery payment-stack guide alongside this matrix.

3. Make provider responses comparable

Ask every shortlisted provider to use the same response categories. These describe the proposed delivery route, not a quality score.

For each row, request the delivery owner, assumption, evidence reference, commercial treatment and timing dependency. Keep unanswered questions visible. A roadmap statement should not be recorded as delivered capability.

Where more than one party is involved, name the person or team that will coordinate the complete journey. Otherwise, a technically valid integration can still leave the operator without an owner for exceptions or incidents.

4. Include data, integrations and exit requirements from the start

Data access is an operating requirement as well as an exit concern. Specify which records you need, who may access them, the identifiers that connect them and how exports will be delivered.

Integration boundaries

For each required connection, document the systems on both sides, the data exchanged, event timing, authentication approach, versioning, monitoring and support ownership. Describe what should happen after a timeout, a delayed message, a duplicate callback or an unavailable partner.

Ask for representative interface documentation and test data. An integration logo or a successful sales demonstration does not establish the behaviour of your intended end-to-end workflow.

Ownership, access and portability

Request an inventory of player, order, transaction, result, support and audit records. Define the fields needed by each operational role, export formats, frequency, expected volume and treatment of corrections. Record access during normal operations, implementation, an incident and termination.

Separate contractual ownership, practical access and data-handling responsibilities. Have the responsible parties assess retention, access and transfer requirements for your circumstances. The player-data ownership guide provides additional procurement questions.

Example: purchases work, but transaction history cannot be exported

In this hypothetical evaluation, a demo completes registration, deposit and ticket purchase. The provider cannot yet produce a complete transaction export with stable identifiers linking the player, order, payment and settlement records.

Ask the provider to demonstrate the export using representative volumes and explain the fields, timing, limitations and any additional work. Finance and operations should check whether the result supports their reconciliation and investigation needs. If the gap remains, decide whether a tested alternative can meet the requirement or whether the proposal should remain outside the shortlist.

Treat this as a current operating dependency, not a question to postpone until migration becomes urgent.

5. Specify security, performance and service expectations

Write down the security and operational outcomes the project needs: administrative permissions, access logging, monitoring, backups, recovery, support escalation and change management. Include availability and performance measurement, capacity assumptions, accessibility and localisation requirements.

Ask what will be measured, over which period, by whom, and with which exclusions. Document recovery objectives and the evidence expected from a recovery exercise. Avoid treating an uptime percentage or security badge as a substitute for understanding the proposed scope and its dependencies.

The NIST Cybersecurity Framework is a primary reference for structuring cybersecurity-risk discussions. Use it to organise questions and requested evidence; this guide does not claim that a provider has been assessed against it.

For payment-card data, the PCI Security Standards Council's PCI DSS resources describe technical and operational security requirements. Ask the relevant payment and security specialists to identify the applicable scope, responsibilities and validation evidence for the proposed architecture. An external payment integration alone does not answer those questions.

6. Script the demo around exceptions

Give providers the same scenarios before the evaluation session. Include a successful journey and the cases that expose hand-offs between systems:

• A verification case requiring additional information and a clear support response.
• A payment callback arriving late or more than once.
• A purchase attempted near the configured sales cut-off.
• A corrected or unavailable external result.
• A restricted account attempting a relevant transaction.
• A manual adjustment that requires an authorised user and a traceable record.
• A report or export that finance must reconcile to the platform records.

Record the product version, assumptions, observed behaviour and unresolved questions. If a scenario cannot be demonstrated, agree what further evidence is needed rather than marking it as accepted.

7. Use a decision matrix that keeps mandatory gaps visible

Set your priorities before reviewing proposals. A suggested decision record is:

Score preferences separately if the buying team finds that useful. Do not let a high score for design or optional features conceal a missing mandatory requirement. Keep evidence quality and unresolved assumptions alongside any score.

8. Approve a numbered requirements baseline

After clarification, freeze a version that lists mandatory, deferred and rejected items, plus the assumptions still open. Use the same requirement identifiers in the proposal, agreed contract scope, implementation work and acceptance record.

For each change, record the effect on cost, timing, dependencies and controls. Define who may approve the change and who will test the outcome. This keeps an important operating requirement from disappearing between a workshop, a sales proposal and the release checklist.

Before you send the RFP

• Confirm the product, market, channel and operating-model inputs, with unresolved items clearly identified.
• Assign an identifier, priority, evidence requirement and acceptance owner to each workflow.
• Request a common delivery-status response from every provider.
• Include integration exceptions, reporting, data access, security and support.
• Ask for the full commercial scope and the dependencies behind delivery dates.
• Provide scripted demo scenarios and record the observed evidence.
• Resolve mandatory gaps before treating a proposal as ready for selection.
• Carry the approved baseline into implementation and the go-live checklist.

Use the lottery software pricing and TCO guide to clarify fee definitions before comparing commercial responses.

Discuss your platform requirements with WhiteLotto

Bring your product scope, required workflows, integrations, data needs and unresolved dependencies to a platform-scoping conversation. Ask which items are available in the proposed platform scope, which require configuration or other work, and which depend on external parties.

Contact WhiteLotto about platform scope.

Licensing, legal and tax decisions should be handled by the appropriate qualified advisers. A platform-scoping conversation does not establish market authorisation or replace their advice.

Adapted by WhiteLotto from an AGM requirements-brief article originally published on 19 August 2026. This version focuses on lottery platform procurement.