RNG, Draw Integrity and Audit Trails: Operator Checklist
Front-end polish does not prove integrity. In lottery, trust ultimately rests on how outcomes are generated, controlled, evidenced, and defended under scrutiny.
Front-end polish does not prove lottery integrity. Buyers need to understand how outcomes are generated, which entries can participate, who can change the rules, and how a disputed result can be reconstructed. An RNG certificate is an important input, not a substitute for checking the complete draw and settlement journey.
Start with the actual draw model
A platform distributing tickets for an official external lottery has different responsibilities from an operator running its own digital draws or RNG-based Keno. For an external draw, review the authorised result source, draw identifier, publication status and correction handling. For an owned game, include randomness, outcome mapping, game rules and operational approvals.
The UK Gambling Commission’s RTS 7 on random outcomes addresses randomness, external-event verifiability and implementation against published rules. It is a useful market-specific reference, not a universal licence or proof that every platform component has been approved.
Separate RNG testing from game and platform assurance
A pseudorandom generator uses an algorithm and internal state; a true random source derives randomness from a physical process. Neither label, by itself, establishes the fairness of the final game. Inspect how raw values are converted into permitted outcomes, how seeds or source failures are handled, and which rule and payout versions apply. The TRNG product information provides a starting point for discussing the randomness component.
Ask what a test report actually covers: laboratory, report identifier, component version, game configuration, testing date and applicable market. Match that scope to the intended deployment. A report covering an RNG does not automatically cover ticket acceptance, wallet settlement, administration permissions or every later software release.
Connect sales cutoff evidence to result corrections
Draw integrity includes the accepted entry population, not only the source of randomness. Define the authoritative sales cutoff, clock and draw identifier. Preserve the eligible ticket set and its link to the closed draw. A late request, retry or disconnected terminal must not silently add an entry after closure.
Keep the published result version linked to settlement records. A correction needs an approved reason, responsible role and new version rather than an overwritten history. Test with synthetic tickets: show recalculation, linked financial adjustments and protection against duplicate credits. Record how affected players and operating teams are informed.
Operator acceptance checklist
| Control | What to demonstrate |
|---|---|
| Rules and configuration | Approved rule version, draw parameters and the change that introduced them. |
| Sales closure | Closing event, clock source and exclusion of a deliberately late entry. |
| Outcome source | Applicable RNG report or authoritative external result, including its version. |
| Result correction | Reason, approval, original result and corrected settlement without double credit. |
| Audit reconstruction | Ticket-to-result-to-wallet trace, access history and an export reviewers can interpret. |
Include these demonstrations in the provider evaluation checklist. Screenshots of a successful draw do not replace a controlled test of an exception.
Define access, retention and change control
Separate configuration, approval and review responsibilities. Document who may alter draw parameters, release a correction or inspect records, and whether they can also change the evidence. Record actor, timestamp, permissions, before-and-after values and financial effect. Set retention and export requirements around the operator’s market obligations and dispute process.
Review privileged access and logging alongside the security and SLA checklist. Agree which changes trigger reassessment or further testing; a version change must not silently inherit an unrelated report.
Rehearse failures before launch
Test unavailable results, duplicate messages, interrupted settlement and a conflicting result version. Define whether the system pauses participation, holds settlement or requests review. The operator should know who owns each decision and how work resumes without losing history. Map these dependencies against the platform modules, rather than treating integrity as one isolated feature.
Discuss your draw and audit requirements
Bring your draw model, target market and example exception scenarios. CONTACT to discuss the platform scope, operating responsibilities and acceptance evidence your team needs.