General Construction

1.1.1 All Lottery Terminals and Self-Service Terminals must be securely constructed to prevent unauthorized access to all stored products, assets, Critical Game Data, and Critical Software.

1.1.2 Access to the interior of the Lottery Terminal and Self-Service Terminal must be automatically detected.

1.1.3 For Lottery Terminals, access to the interior must result in the following actions being automatically taken:

1. The date and time of access is logged;
2. The access is reported to the Backend System in real time for Operator monitoring and audit purposes; and
3. The Lottery Terminal is promptly disabled.

1.1.4 For Self-Service Terminals, access to the interior of the device must result in the following actions being automatically taken:

1. A clearly visible and clearly audible alarm must be set off in real time;
2. The date and time of the access is logged;
3. The access is reported to the Backend System in real time for Operator monitoring and audit purposes; and
4. The Self-Service Terminal is promptly disabled.

Inventory Tracking and Safety

1.1.5 The following information must be displayed on Lottery Terminals and Self-Service Terminals, at minimum:

1. Model identifier(s);
2. Unique serial identifier(s); and
3. Safety certification monogram established by an appropriate agency such as Canadian Standards Association (CSA).

Electro-Magnetic Immunity

1.1.6 All assembled Lottery Terminals and Self-Service Terminals must exhibit electro-magnetic immunity in accordance with good industry practices for IT equipment. This means the equipment must be independently reviewed to demonstrate compliance with the following standards or their equivalent:

1. CAN/CSA-CEI/IEC 61000-4-2 for Electrostatic Discharge; and
2. CAN/CSA-CEI/IEC 61000-4-4 for Electrical Fast Transient/Bursts.

1.1.7 In conducting the independent review contemplated in standard 1.1.6, the independent review must be certified by an individual or group not directly involved in the development of the Lottery Terminal or Self-Service Terminal who is authorized by the Gaming-Related Supplier for such certification, or an independent testing laboratory with ISO/IEC 17025 accreditation for such work.

Communications

1.1.8 The integrity and security of all information must be maintained during communication between all Lottery Terminals, Self-Service Terminals, Associated Equipment, and Backend Systems.

1.1.9 Significant Events must be communicated from Lottery Terminal and Self-Service Terminal to the Backend System in real time or as soon as it becomes technically possible.

1.1.10 Lottery Terminal and Self-Service Terminal applications must control and monitor or be notified on all ports that are used to transmit or receive any data or signals to or from the Associated Equipment.

1.1.11 All Lottery Terminals and Self-Service Terminals must be appropriately hardened to prevent unauthorized access, including having all unused ports disabled at all times.

1.1.12 Interruptions in communication between Lottery Terminals, Self-Service Terminals, Associated Equipment, or Backend Systems must:

1. Not impact the integrity, security, nor accounting of any transactions, purchases, or wagers; and
2. Be recovered from as soon as technically possible.

Diagnostic Mode

1.1.13 Lottery Terminals and Self-Service Terminals must have the following minimum diagnostic functions to ensure proper operation of the devices:

1. Identification of Critical Software name, version and signature;
2. Printer test;
3. Scanner tests, for example for bet slip readers and age verification scanners;
4. Communications test with Backend System;
5. Burster test for devices that have a Burster; and
6. Touch screen calibration and test for devices that have touch screen(s).

1.1.14 Lottery Terminals and Self-Service Terminals must clearly indicate their current operational state.

Error Conditions

1.1.15 Impacted Lottery Terminal and Self-Service Terminal functions, peripherals, or both must be disabled under the following conditions, and must not be enabled until the condition has been resolved:

1. Critical Software errors, such as:
   1. Defective Software Storage Media,
   2. Software authentication failure,
   3. Application crash, and
   4. Communication errors, such as loss of communication with the Backend System;
2. Significant Events buffer full;
3. Printer failure;
4. Failure to dispense purchased Lottery Ticket; and
5. Scanner error, including bet slip reader and age verification scanner.

1.1.16 Lottery Terminals and Self-Service Terminals must immediately detect, display, and record in an error log the conditions listed in section 1.1.15.

1.1.17 Whenever it is technically possible, Lottery Terminals and Self-Service Terminals must communicate at a minimum the error conditions 1.1.15 a) and b) to the Backend System.

1.1.18 Lottery Terminals and Self-Service Terminals must, at minimum, immediately inform the user if there is a loss of communication with Associated Equipment or the Backend System. This message must be visible to the user at all times and may only be removed after the condition has been resolved.

Printer

1.1.19 There must be manual or automated mechanism(s) to mitigate incomplete printing of Lottery Tickets or vouchers. For example, in the case of printing errors such as partial printing, duplicate printing, or jams, the Backend System must void such Tickets and vouchers.

1.1.20 In case of Lottery Terminal or Self-Service Terminal Remote Disable, the Lottery Terminal or Self-Service Terminal must display an explanatory message and the printer must complete the printing of a valid Lottery Ticket.

1.1.21 The printer must not print duplicate Lottery Tickets. If reprint features are offered, such a Lottery Ticket must be clearly marked as “reprint”.

Scanner

1.1.22 The scanner must be able to read accurately and communicate the appropriate results.

1.1.23 The outcome of the operation of using a scanner must be clear to the Seller and to the player, as applicable.

Age Verification Reader

1.1.24 Self-Service Terminals must utilize a mechanism to validate the identification provided by the player which indicates they are of legal age prior to permitting the purchase of a Lottery Ticket.

1.1.25 Self-Service Terminals that have validated the identification of the player to indicate they are of legal age must have a suitable mechanism in place to prevent another player from purchasing Lottery Tickets based on the age validation of the previous player.

General Requirements

2.1.1 POS applications must display sufficient information to be identifiable, such as the software name and version.

2.1.2 The ELS must only allow purchase of Lottery Tickets when conflicts will not occur, such as to prevent tickets from being purchased during the Draw time that will therefore not be included in the Draw.

2.1.3 POS applications must ensure all Lottery transactions are completely and accurately forwarded to the Backend System.

2.1.4 POS applications must clearly communicate all relevant information messages to Sellers and players during Lottery transactions, such as wagering, cancellations, validations, redemptions, and when a Lottery transaction is being rejected.

2.1.5 Lottery transactions must be securely, completely and accurately communicated between the POS application and Backend System:

1. In real-time whenever possible; and
2. As soon as possible when not possible in real-time such as during power or communication interruption.

2.1.6 All accepted payment mechanisms must be compliant with the applicable Payment Card Industry (PCI) Security Standard(s) as confirmed by a laboratory recognized by PCI Standards Security Council to make this determination.

2.1.7 All Personally Identifiable Information (PII) captured must be securely protected from unauthorized access.

2.1.8 There must be no hidden or undocumented buttons or touch points (if applicable) that affect any of the POS approved functions anywhere on the Lottery POS interface used for Game Play.

2.1.9 POS applications must not be adversely affected by the simultaneous or sequential activation of the various inputs and outputs.

2.1.10 There must be no negative integrity impacts from one Lottery Game to another Lottery Game.

2.1.11 User input fields must be validated to prevent invalid data from being entered which could potentially impact the integrity of the Game.

2.1.12 When POS limits on Lottery Ticket transactions configured in the Backend System are reached, there must be clear and accurate messaging to inform Sellers and players. The limits themselves must not negatively impact to the integrity of Lottery Games.

2.1.13 Sufficient reports must be available to review at minimum thirty (30) days’ history of Lottery Ticket transactions, accounting, and security logs.

2.1.14 A Remote Disable mechanism must be provided to disable the Lottery Terminal and Self-Service Terminal in real-time.

Lottery Terminal Applications

2.1.15 Lottery Terminal usage must be monitored by the Operator. The Lottery Terminal must be disabled when unlawful or non-compliant usage occurs, or any integrity or security issues occur.

Self-Service Terminal Applications

2.1.16 Self-Service Terminal usage, integrity, and security must be monitored by the Seller. The Self-Service Terminal must be disabled by the Seller to prevent unlawful or non-compliant usage, and to mitigate any detected integrity or security issues.

2.1.17 Self-Service Terminal usage, integrity, and security must be monitored by the Operator. The Self-Service Terminal must be disabled by the Operator when unlawful or non-compliant usage is detected, and to mitigate any integrity or security issues, when not already mitigated by the Seller.

2.1.18 Self-Service Terminals must limit a single purchase transaction to $300 or less.

2.1.19 Self-Service Terminals must limit redemption of prizes in a single transaction to non-cash prizes only having a combined value of $300 or less.

Wagering

3.1.1 The method of wagering must be straightforward with all relevant selections included in and verified by ELS before being accepted. This verification process must detect and block all invalid selections and in the event a wager is rejected must return a message explaining why the wager was rejected.

3.1.2 Clear indication must be issued when a wager has been accepted or rejected, along with the accurate cost of wager and credit balance.

3.1.3 The ELS must accurately issue a Lottery Ticket to the player per selected wagering options.

3.1.4 The ELS must provide functions, such as retry and cancel to mitigate Incomplete Wagers. Player transactions and accounting must remain accurate.

3.1.5 The ELS must prevent transactions that would exceed pre-set wagering limits from being completed and inform the player (directly or indirectly) of the reason. Examples of pre-set wagering limits include liability limitations for Sport and Event Betting on unique combinations of events, or products with fixed prizes where limits on chosen outcomes are in place.

3.1.6 Wagering must not be possible once the wagering period has been closed.

3.1.7 The ELS must make a complete and accurate record of wagered transactions available to players.

Lottery Tickets Integrity, Security and Auditability

3.1.8 Lottery Tickets must display the following information (where applicable):

1. Cost of the Lottery Ticket, including when the Lottery Ticket has no associated cost;
2. Game name and unique identifier;
3. Game specific information for which the bet was placed, for example Lottery numbers;
4. Draw date and Draw time indicator;
5. Date and time of issuance;
6. Lottery Terminal or Self-Service Terminal identifier;
7. Unique Validation Number;
8. Security code/feature(s), for example a barcode for Lottery Ticket recreation; and
9. Any other Lottery Ticket specific information, such as expiration period.

3.1.9 Lottery Tickets must completely and accurately represent player’s wager.

3.1.10 The ELS must have an independent function to authenticate Lottery Tickets, for example to retrieve all relevant data about the Lottery Ticket in order to facilitate investigations and validation when required. This function is not required to be available on every Self-Service Terminal and Lottery Terminal.

3.1.11 All Lottery Ticket information and related transactions must be accurately captured in the Backend System reports to provide auditable trail of events.

Voiding Lottery Tickets

3.1.12 The act of voiding Lottery Tickets must be recorded with an auditable trail of events.

3.1.13 The ELS must ensure that the voiding of Lottery Tickets by players and Operators is secure.

3.1.14 It must not be possible to re-sell voided Lottery Tickets nor to reissue the corresponding Validation Numbers.

Lottery Draw

3.1.15 The Lottery Draw must be conducted through a random selection process satisfying applicable requirements from section 5. The Draw must include all valid Lottery numbers or Lottery Tickets, as applicable.

3.1.16 All Lottery Draws activities must be recorded with an auditable trail of events.

Validation/Redemption

3.1.17 The Lottery POS must provide clear instructions on how to redeem Lottery Tickets after validation, where validation functionality is available.

3.1.18 The ELS must provide accurate winning selection information.

3.1.19 There must be a mechanism made easily available to players to enable self-checking of their Lottery Ticket.

3.1.20 The ELS must process winning Ticket validation and Award redemption securely.

3.1.21 For Lottery POS where Lottery Ticket validation functionality is available, upon validation, the Lottery POS must produce a notification of Award (i.e. audio and visual).

3.1.22 The ELS must log redemption of a winning Lottery Ticket with audit trail details.

3.1.23 The ELS must prevent payment of previously redeemed Lottery Tickets.

3.1.24 If a free Lottery Ticket as part of the winning prize cannot be printed due to printer error, the ELS must be able to mitigate the consequences, for example by reissuing such a Lottery Ticket.

3.1.25 The Lottery POS must issue the customer a receipt upon successful validation/redemption with the following information at a minimum:

1. Location identifier;
2. Unique Lottery Ticket Identifier which matches the Lottery Ticket being redeemed;
3. Date and time; and
4. Win Amount, if applicable and win category (for example free Lottery Ticket).

3.1.26 For winning Lottery Ticket with Draw(s) remaining, upon redemption, the ELS must have a mechanism to enable future redemption for remaining Draws.

3.1.27 Only a valid Lottery Ticket can be redeemed.

3.1.28 The ELS must detect invalid, tampered with or duplicated Lottery Tickets, where technically possible.

Draw Games

3.1.29 The ELS must provide clear separation between adjacent Draws, for example Draw close between Draw purchase periods.

3.1.30 The ELS must clearly indicate all information necessary to track the progress of bonus features, for example the instant component of Draw Games such as Watch n’ Win.

3.1.31 POS must notify players on any instant win (i.e. synchronized audio and visual) at the time of Lottery Ticket purchase.

3.1.32 Instant win information, for example winning symbols and Award printed on Lottery Ticket must match the information on Watch n’ Win display.

3.1.33 Instant win for a Draw Game with Watch n’ Win must be selected through a random selection process satisfying applicable requirements from section 5.

3.1.34 Lottery Ticket printing and Watch n’ Win animation must be coordinated in a way that Game integrity is not compromised, for example utilizing simultaneous animation and Lottery Ticket printing.

Sport and Event Betting

3.1.35 The Lottery POS, where applicable, must have capability to provide all the necessary Sport and Event Betting information in a clear and accurate manner. At the minimum, the following shall be provided:

1. Information regarding markets available for betting;
2. Sport and event lists;
3. Payout odds and clear rules as to how the payouts are calculated;
4. Specific rules of play for each category of betting;
5. Conditions under which bets may be canceled or voided;
6. Event date and time, including clear time-zone indication; and
7. Any liability limits.

3.1.36 Sport and Event Betting shall only be possible after the information in 3.1.35 is available at the Lottery POS and not after the sport or event begins, is closed or suspended.

3.1.37 The ELS must be able to suspend on demand the following, at a minimum:

1. All Sport and Event Betting;
2. Betting on individual sports or other events;
3. Betting on individual Sport and Event Betting markets; and
4. Individual POS devices offering Sport and Event Betting.

3.1.38 Online slip builder functions must ensure accurate presentation of betting options in the electronic selection slip.

3.1.39 The ELS must implement good industry practices to ensure the security and integrity of betting utilizing electronic selection slips.

3.1.40 Electronic selection slips must be designed with good industry practices to ensure their security and integrity.

3.1.41 The ELS must have audit capability for electronic selection slips, including when they are saved for ticket issuance. At a minimum, this audit information must include betting options selected and the wager.

3.1.42 The ELS must have audit capability for the odds used in Sport and Event Betting. At a minimum, this must include the odds and the time, date and duration of odds posted for betting.

3.1.43 The Awards corresponding to Sport and Event Betting winning tickets must be based on the odds at the time when the bet was placed.

3.1.44 Notifications regarding odds changes for an individual sport or event must be provided promptly and clearly to players when the odds change after creation of electronic selection slips but prior to the bet being placed. In addition, the ELS must be updated accordingly.

3.1.45 The ELS must be designed to minimize any negative impacts on betting related to dynamically changing odds due to communication delays and system interruptions.

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.

Authentication of Critical Software

6.1.1 A mechanism shall be built into the ELS to verify the integrity of the Critical Software that is deployed to production, including before changes are implemented as well as on an ongoing basis, to ensure approved software is being used with no unauthorized changes.

6.1.2 At a minimum, the ELS must be successfully authenticated:

1. Immediately prior to startup;
2. Automatically at regular intervals during operation;
3. Before Lottery Draw for jackpot prizes; and
4. On demand by the Operator, or AGCO.

6.1.3 The authentication method must be based on good industry practices to ensure security and integrity. An example of an authentication method is calculation of software SHA-1 values which are compared against a protected master list of signatures (i.e. encrypted SHA-1 values).

6.1.4 If the self-authentication fails, the software that fails authentication must enter an error condition, safely stop operation and notify the Operator. The AGCO must be immediately notified of the failure, including the details of the failed authentication.

6.1.5 The results of each authentication must be recorded in an unalterable report which is available to the AGCO. This report must include a pass/fail condition with details on which software did not pass the authentication.

6.1.6 Modifiable files such as configuration settings do not need to be included in any of these software verifications required by 6.1.1 and 6.1.2. However, the configurations that are critical must only be settable in a way that does not compromise Game integrity.

Self-Authentication of Critical Software in Volatile Memory

6.1.7 Critical Software components, excluding graphics and sound components, must be fully authenticated at the time of loading into electrically erasable or volatile memory (prior to execution), and at minimum, following any Lottery Terminal and Self-Service Terminal resets and power up. Impacted functions must be disabled if an invalid component is detected.

Remote Authentication of Lottery POS Critical Software

6.1.8 Backend System must initiate independent authentication on all Lottery Terminal and Self-Service Terminal Critical Software upon initial establishment of a connection with the system. When a threshold of unsuccessful authentication attempts is reached, the Lottery Terminal or Self-Service Terminal must be disabled.

Critical Game Data Integrity

6.1.9 The ELS must accurately maintain the integrity of Critical Game Data to ensure the Lottery Game operates as expected and is auditable.

6.1.10 The ELS must employ methods to detect corruption and unauthorized alteration to its Critical Game Data to prevent integrity issues from occurring.

6.1.11 Detection of corrupted or unauthorized alteration of Critical Game Data that cannot be recovered must cause Lottery Ticket sales at impacted Lottery Terminals and Self-Service Terminals to be halted immediately, and must cause the POS to enter into an error condition and not resume Lottery Ticket sales until the condition has been addressed.

6.1.12 The integrity of Critical Game Data at the Lottery Terminal and Self-Service Terminal must be maintained by methodology that enables failure detection, backup and recovery of Critical Game Data.

6.1.13 It must be possible to extract Critical Game Data at the Lottery Terminal and Self-Service Terminal through Restricted Technical Procedures without contaminating the data in the original storage media.

6.1.14 Clearing of Critical Game Data must only be performed through a Restricted Technical Procedure.

6.1.15 Lottery Terminal and Self-Service Terminal applications must preserve the integrity of any Critical Game Data stored in Critical Memory by a methodology that enables failure detection and recovery of Critical Game Data. If recovery is not possible, the impacted ELS functions must enter an error condition, safely stop operation, and alert the Operator of the failure.

Network Infrastructure

7.1.1 Communication protocol among ELS components over network infrastructure must be secure, must maintain Lottery Game integrity, and must prevent any unauthorized access to Personally Identifiable Information (PII).

7.1.2 Network components must have synchronized time to preserve logging and auditing capability.

7.1.3 All gaming related network traffic exposed to public networks must be secured using industry standard methods proven to prevent unauthorized access or alteration of information.

7.1.4 Network architecture must be designed in a way to prevent a large volume of communications from causing a security or integrity issue.

Security

7.1.5 The ELS must be designed for immunity against security attacks. This includes, but is not limited to implementing security in depth (multiple layers of security so that if one layer is bypassed the attack still has to get through the next layer), and active monitoring of potential threats together with effective automated controls to prevent attacks from being effective (such as preventing attacks from moving between components of the system or to other systems).

Independent Security Assessment

7.1.6 Publicly exposed ELS’ (for example Web applications accessible through public networks) must be protected with adequate security measures to prevent any integrity or security issues.

7.1.7 New ELS’ that are publicly exposed must be independently assessed by qualified individuals in accordance with industry good practices to ensure that security vulnerabilities are identified and addressed, and residual risks are confirmed to be negligible.

7.1.8 At the discretion of the Registrar, certain modifications to publicly exposed ELS’ will require independent security assessment, for example when the complexity or volume of changes from the previously approved ELS is expected to impact security risks.

Submission Requirements

7.1.9 Gaming-Related Suppliers must provide necessary information, training and tools pertaining to the ELS for which the approval is being requested to help facilitate AGCO assessment, testing, and issuing decisions in a timely manner.

7.1.10 All requests for approval of ELS must adhere to the submission requirements, “AGCO Gaming Technology Submission Requirements”.

Ensuring the Ongoing Integrity of Approved Electronic Lottery Systems

7.1.11 Gaming-Related Suppliers and Operators must promptly notify each other, and the Registrar per the Gaming Notification Matrix, of any integrity, security or accounting capability concerns with the approved ELS.