19.1 General Requirements
19.1.1 All Game Results Sets must be reviewed and approved by the Registrar for integrity of Pay- back and Play results. In addition, the integrity of sets must be verifiable on demand before offered for Play.
19.1.2 Tickets may be drawn from electronic Game Results Sets secured on Backend System with or without replacement.
19.1.3 Functionality must exist to place entire Game Results Sets into an unplayable state (deacti- vation of Deals) through restricted technical procedure. The use of this functionality must be logged and fully auditable.
19.1.4 Removal of a Game Results Set from Play must not impact audit trail or reports for any past Game Plays.
19.2 Tickets Drawn with Replacement
19.2.1 RNG used for random draw of Tickets must satisfy section 21.1 of this document.
19.2.2 Tickets drawn must be statistically independent, that is sufficiently random, so that there are no negative impacts on any Game aspects, e.g. Game Payback.
19.2.3 There must be no patterns or correlation of drawn Tickets.
19.3 Tickets Drawn without Replacement
19.3.1 RNG utilized to randomly sequence Tickets must satisfy requirements 21.1.1 and 21.1.2 of this document.
19.3.2 The position of Tickets within a Deal/Deck must be statistically independent, that is suffi- ciently random, so that winning Tickets cannot be determined along any given sequence of Tickets.
19.3.3 There must be no patterns or correlation of Tickets within a single Deal or Deck and across Deals and Decks.
19.3.4 If a shuffling algorithm is used to sequence Tickets, it will be evaluated on case-by-case basis for approval by the Registrar.
19.3.5 Any shuffled sequence of Tickets for Deals with the same contents (Deal duplication) must satisfy the requirements 19.3.2 and 19.3.3.
19.3.6 Where physical Tickets are used to communicate Game results to the player, the Backend System must contain a function to remove from Play and void unplayable Tickets that cannot be sold properly, e.g. damaged tickets.
19.3.7 All voided Tickets must be logged and fully auditable.
19.3.8 Play status of all Tickets must be tracked in the Backend System for audit purposes.
19.3.9 The Backend System must have a check to prevent sale of a ticket that has already been sold.
19.3.10 cGaming System must restrict and minimize information available which could be used to predict the winnings, such as current payout of a set which is still in Play.
19.3.11 When enrolling new Game Results Set (Deal), the following must be ensured:
- Results are transmitted to the database in a fashion which preserves confidentiality of results and verifies the results came from a trusted source;
- Addition or removal of Game Results Set from Play must be logged in a way that cap- tures information regarding user, date/time of action, and Deal parameters;
- The Backend System must verify the integrity of a pre-determined Game Results Set through use of a Hash function. The pre-determined Game Results Set must not be en- abled for Play until this Hash is calculated and verified;
- Removal or replacement of an existing pre-determined Game Results Set must not inter- fere with Game Play, e.g. it is not in Play, or made unavailable for Play.
19.3.12 Game Results Sets (Deals) may be created on systems outside the Backend System. Once created, Deal results must be protected to preserve the integrity of the Game.
19.4 Reporting
19.4.1 Information regarding all Ticket Plays must be available for audit. These reports must contain the following information at a minimum:
- Play results;
- Prizes paid;
- Amount wagered;
- Unique identifier for the Player Terminal;
- Unique identifier for the finite set; and
- Date/time.