RNG, Draw Integrity and Audit Trails: Operator Checklist

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

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.

Separate draw presentation from result authority

A live draw broadcast is a presentation channel, not automatically the record that authorises settlement. Define which source supplies the result, which state makes it final and which team resolves disagreement between video, displayed numbers and the result record. A stream ending does not establish that a result has been confirmed.

Keep the draw identifier, scheduled time, display status and result version aligned across the player screen and operator records. Where a stream is delayed, distinguish the time shown in the broadcast from the current service status. The draw and results integration guide explains the underlying result lifecycle; presentation must communicate that lifecycle rather than create a separate outcome.

Specify what players see during an exception

Agree who publishes each message and how the operator checks that it reached every language and device. Review access to these changes against the security and service checklist.

Ask for a connected presentation demonstration

Include a normal broadcast, interruption, delayed confirmation and result correction in the provider evaluation brief. Use synthetic draws and show the player message beside the underlying draw state, not only a successful video. Record the environment, configuration and responsible roles; requested presentation functions still need a defined proposal scope.

Track presentation incidents separately from draw completion and financial settlement using the operator KPI framework. Add the agreed checks to UAT acceptance, then share your broadcast, language and exception requirements through CONTACT.

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.