System Requirements

4.1.1 The ELS components must have synchronized time when providing the following, at a minimum:

1. Time stamp for Ticket sales and Draws;
2. Time stamp for Significant Events; and
3. Referent time for logging and reporting.

4.1.2 User input fields must be validated to prevent any integrity and security breaches.

4.1.3 The ELS must be designed and tested to operate with integrity under anticipated load (for example, total volume of sales and peaks of Lottery Ticket transactions per minute) and communication bottlenecks in production environment.

4.1.4 The ELS and sensitive data must be secured and protected from unauthorized access or use at all times using industry good practices.

4.1.5 ELS components must not have access to and must not be accessible from the Internet beyond what is required by the ELS to support the Lottery solution.

4.1.6 The ELS must have the ability to enable and disable Lottery Terminals, Self-Service Terminals, and Games.

4.1.7 Management, administration or configuration of the Backend System from Lottery Terminals and Self-Service Terminals must be prohibited.

Data Governance

4.1.8 All Lottery Ticket transactions from POS must be completely and accurately captured in the Authoritative Data Store as permanent records.

4.1.9 Backend Systems must record and store complete Lottery Ticket transactions and Draw accounting data for all valid and voided Lottery Tickets, including at a minimum:

1. Name of Operator conducting Lottery Game, if applicable;
2. POS ID where the Lottery is conducted, for example retail location;
3. Lottery Game identifier;
4. Draw date(s) or sport or events date(s), as applicable;
5. Date and time of Lottery Ticket transactions;
6. Lottery Ticket price;
7. Financial information sufficient to reconcile Lottery Ticket sales;
8. Game results, winning Lottery numbers, or both;
9. Individual Lottery Ticket information per section 3.1.8;
10. Type of transaction or other method of differentiating Lottery Ticket types;
11. Player ID, if applicable; and
12. Lottery Ticket Status.

Lottery Terminal and Self-Service Terminal Management

4.1.10 The Backend System must have the ability to manage Lottery Terminals and Self-Service Terminals, such as:

1. Game configuration;
2. Operational state, for example enabled or disabled state;
3. Financial transactions and security; and
4. Authorization to connect and perform Lottery transactions.

4.1.11 The ELS must maintain an inventory list of Lottery Terminals and Self-Service Terminals to include at a minimum:

1. Unique identifier;
2. Location;
3. Device description; and
4. Software version.

Draw Games Management

4.1.12 The Backend System must have the ability to setup Draw Games, including Draw date/time, Awards and any related promotions through Restricted Technical Procedures.

4.1.13 Any Draw Game configurations made, or changes to Award structure must be logged sufficiently for audit purposes, at a minimum: user making the change, date/time and details of the change.

4.1.14 The Backend System must have the ability to close off the Lottery Draw. The Draw may only be conducted after:

1. Closure of Lottery sales and voided purchases;
2. All wagers managed outside the ELS (for example subscriptions) are accurately captured and completely recorded in the ELS prior to the Draw; and
3. Full reconciliation of sales figures between the Independent Audit System (IAS) and Backend System, except for quick draw games which may be reconciled daily.

4.1.15 Winning Lottery Ticket from the Draw must be verified as a valid Lottery Ticket before the prize is paid.

4.1.16 The Backend System must not allow Lottery Ticket wagering and cancellation for a Draw that has been closed. However, the Backend System may allow for the reissuance of a Lottery Ticket for a closed Draw.

Sport and Event Betting Management

4.1.17 The Backend System must only set information from 3.1.35 for Sport and Event Betting through Restricted Technical Procedures.

4.1.18 The Backend System must have the capability to administer Sport and Event Betting, at the minimum:

1. Any changes to odds, availability for purchase, or both,
2. Betting and event irregularities, and
3. Event status.

4.1.19 The Backend System must support cancellation and redemption of player’s bets for cancelled events, where the availability for purchase has changed, or both.

4.1.20 The Backend System must not allow Lottery Ticket transactions beyond the cut-off time for each event.

Logging and Reporting

4.1.21 The Backend System must at a minimum contain the following information in reports for complete audit trail, capable of being generated on-demand, for specific time periods, and for specific activities:

1. Lottery Transactions - Information on all Lottery Ticket transactions and Draw accounting handled by the system, including, where applicable: Lottery Ticket issuance, cancellation, reprint, validation and redemption; all valid and void Lottery Tickets with Lottery Numbers and Validation Numbers, Lottery Ticket price, Lottery Ticket status, Lottery POS identifier, date and time of transaction and name of person (user) performing the transaction, winning Lottery Numbers and total sales & paid outs.
2. Security Events: any information on access and attempted authentication including: component accessed, username, success or failure of authentication, date and time, any changes made; and
3. Error Logs – All critical errors where technically possible, such as Lottery Terminal, Self-Service Terminal, or system application crashes, failed software authentication and communication errors.

Software Random Number Generator

5.1.1 Random numbers must be:

1. Statistically independent;
2. All values within the desired range must have an equal chance of being generated;
3. Able to pass various recognized statistical tests; and
4. Unpredictable.

5.1.2 The range of random numbers must correspond to the range used in a particular Game including both high and low-end range of sales, as applicable. Specifically, the random numbers must produce statistics that lie within the 99% confidence interval for various Game specific, empirical statistical tests, including but not limited to frequency test, runs test and serial correlation test. The applicable tests are chosen in a way to match the grouping of random numbers to form Game outcomes.

5.1.3 The RNG output must not exhibit detectable patterns or correlation with any previous RNG output.

5.1.4 The RNG, ELS, or both must implement a mechanism to prevent the determination of seeds.

5.1.5 The RNG seed must be reinitialized, if corrupted.

5.1.6 Where the selection process of Game elements is interrupted, the original selection must be preserved until full system recovery.

5.1.7 Where there is a failure of the mechanism used to select Game elements, the ELS’ impacted function that rely upon that mechanism must be made unavailable for Play until the failure has been rectified.

5.1.8 The ELS must use secure communication protocols to protect the RNG and random selection process.

5.1.9 RNG pools of selections must be stored securely.

Physical Random Number Generator

In addition to the requirements 5.1.1, 5.1.2 and 5.1.8, the following are specific requirements that apply to physical RNGs, which use physical properties of number designators (for example balls, wheels, or dice) to randomly generate Game results.

5.1.10 RNG designators must satisfy the following:

1. All designators must be of equal size and mass homogeneously distributed to ensure that they are not weighted to a specific outcome;
2. Game results must be clearly displayed on the designator and be distinguishable from all other results (for example 6 and 9 must be clearly marked);
3. Designators must contain a method of identifying the set to which each individual designator belongs; and
4. Designators used must be designed to resist physical degradation. Where the designators have a defined life cycle, they must be replaced within their life cycle.