1.1  General Cabinet Construction

1.1.1  The cabinet must be of rigid construction and must resist forced entry, tampering and wilful damage using force such as kicking, blowing and bending, or using small tools such as a screwdriver.

1.1.2  The cabinet design must be such that access to the inside is possible only by the use of a key.

1.1.3  There must not be any gaps or openings in the cabinet other than those intended for the operation of the Game.

1.1.4  Ventilation holes must not compromise the integrity and security of the Game.

1.1.5  All doors must resist forced entry and must retain evidence of any such attempts.

1.1.6  All doors must be secured with a lock and an electronic security Switch.

1.1.7  The main access door, cashbox access door and the cashbox each must have a separate lock/key used for that door that may only be opened by authorized personnel.

1.1.8  All Player Terminals must have a non-removable ID plate on the outside of the cabinet con- taining the following information:

1. Model number;
2. Unique serial number; and
3. Safety certification approval monogram.

1.1.9  Printed circuit boards (PCB) integral to the gaming cabinet must be identifiable.

1. Each PCB must be identifiable by a name/number and revision level, as applicable;
2. The top assembly revision level of the PCB must be identifiable; and
3. If track cuts and/or patch wires are added to the PCB, then a new revision number or level must be assigned to the assembly.

1.1.10  Security and communication-related wires and cables that are routed into secured areas within the cabinet must be securely fastened within the interior of the cabinet.

1.2  Accessory Cabinets and Top Boxes

1.2.1  If used to accommodate gaming logic, accessory cabinets and top boxes must be equipped with security features that allow access to the internal components to authorized personnel only.

1.3  Electro-Magnetic Immunity

1.3.1  All assembled Player Terminal cabinets, including integral hardware components such as printers, Bill Validators, as well as any Associated Equipment must be certified by an inde- pendent test lab (acceptable to the Registrar) that specializes in, and is accredited for, immu- nity testing to satisfy the requirements listed below. The impact of any subsequent hardware modifications must be evaluated by an expert test lab.

1. The cGaming Equipment must exhibit total electro static discharge (ESD) immunity, with no disruptions in Game performance for:
   
   1. air discharge of up to ±15kV and
   2. contact mode up to ±8kV;
2. The cGaming Equipment must recover from ESD and complete any interrupted Play without loss or corruption of any stored or displayed information for air discharge of up to ±27kV; and
3. The cGaming Equipment must exhibit total immunity to electrical fast transients (EFT) for a discharge of up to 2.0 kV burst pulses repeatedly into the power line between the hot and neutral at any phase.

1.4  Door Security Switches

1.4.1  Each door of a Player Terminal and its associated auxiliary cabinets must be equipped with one or more Switches for security purposes. Security Switches must be wired directly to the Player Terminal, and capable of detecting and communicating the following conditions, as applicable:

1. Main door open/close;
2. Belly door open/close;
3. Cashbox compartment door open/close;
4. Cashbox removed/returned;
5. Logic box door open/close; and
6. Topbox door open/close, if used to accommodate gaming logic.

1.4.2  Switches must be wired in a way that all door alarms can be reported under any operational conditions.

1.4.3  Disconnecting the wiring from a Switch or a malfunction of the Switch (e.g. magnet or opti- cal signal broken/missing) must result in notification of a “door open” condition.

1.4.4  In the attempt of illegal or forced entry, Player Terminal’s electronic security system must trigger an immediate alarm and log such event. The security system is comprised of hard- ware components including a security Switch and monitoring software.

2.1.1  The Game logic and any other circuitry affecting Game outcome, security and integrity in- cluding, but not limited to, Critical Game Software, RAM, ROM, Boot storage media and communication interfaces, must be secured in a separately locked logic box inside the main Player Terminal cabinet.

2.1.2  Access into game logic box from the inside of Player Terminal must be secured with a sepa- rate lock/key used for logic box only and electronic security Switch.

2.1.3  The function of all communication ports, software switches and/or jumpers must be clearly defined in supporting documents submitted with the equipment for approval.

2.1.4  Logic box physical design must comply with the following requirements from this docu- ment, as applicable: 1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.1.6 and 1.1.9.

3.1  Wagering Instruments

3.1.1  Only Canadian bills available for general circulation may be accepted after proper validation by the Bill Validator. A request to accept other types of currency must be submitted for approval by the Registrar and will be reviewed on a case-by-case basis.

3.1.2  The Bill Validator may accept other types of Wagering Instruments approved by the Registrar for such use, such as Vouchers and Coupons.

3.1.3  Wagering Instruments accepted by the Bill Validator, and the orientation for insertion must be clearly shown at the appropriate place on the Player Terminal if accepted only in a specific orientation.

3.1.4  The Bill Validator must provide the flexibility to select and deselect bill denominations and other types of Wagering Instruments such as Vouchers, provided they are approved by the Registrar. Optionally, the Game may also provide this capability.

3.1.5  The Bill Validator must authenticate the bills at the security level to reject any counterfeits while maintaining high acceptance rate of good bills.

3.1.6  The Bill Validator must reject Wagering Instruments that are stacked atop one another during insertion.

3.2  Interaction with the Game

3.2.1  The Game must not issue credits until:

1. the Wagering Instrument has been stacked in the cashbox after proper validation;
2. the Bill Validator has sent the “irrevocably stacked” message to the Game; and
3. the Game software has performed a validity check of all actions performed by the Bill Validator to ensure all required logical actions have taken place, i.e. bill stacked message was preceded by all other messages.

3.2.2  The Bill Validator must communicate with the Player Terminal using a bidirectional protocol.

3.2.3  Any Voucher that cannot be verified against the appropriate validation system for any reason must be rejected.

3.2.4  A Player Terminal that uses a Bill Validator must retain in its memory and display, at mini- mum, the denominations of the last ten bills inserted.

3.3  Tilt Conditions

3.3.1  The Player Terminal must be disabled and Play must not occur until the following error condi- tions have been cleared:

1. Bill jam;
2. Cashbox access door opened;
3. Illogical sequence of events sent by the Bill Validator that are detectable by the Player Terminal, e.g. bill stacked message issued prior to bill denomination message; and
4. Bill Validator firmware Hash failure.

3.3.2  The Bill Validator must be automatically disabled and not be re-enabled until the following conditions have been cleared:

1. Cashbox Removed;
2. Cashbox Full;
3. Hardware/Software Error;
4. Validator Communication Error;
5. Host Player Terminal is in Tilt, disabled or Administrative Mode; and
6. Stolen bill where the bill was read and stacked without the communication of the “irrevocably stacked” message to the Player Terminal.

3.3.3  The Bill Validator must be designed to prevent the successful use of cheating methods such as stringing, the insertion of foreign objects and any other manipulation that may be deemed as a cheating technique.

3.3.4  The Bill Validator must be automatically disabled and not be re-enabled while:

1. the Game has started active Play and has not displayed the final result of the current Wa- ger to the player, or
2. the credits are being cashed out.

3.4  Software Integrity

3.4.1  The Bill Validator must perform a self-test at each power up. In the event of a self-test fail- ure, the Bill Validator must automatically disable itself and send a signal to the host Game until the error state has been cleared.

3.4.2  Host Games using Bill Validators whose software contents is modifiable must display the Hash value of the Bill Validator code on demand.

3.4.3  During the programming operation on Bill Validators with modifiable software, each byte programmed must be verified by a comparison program controlled by the programming device.

3.4.4  The Bill Validator software must be capable of authentication on demand to ensure the contents match the approved version.

3.4.5  The authentication of Bill Validator software can be performed either by external tools,  such as an EPROM verifier, or internally by the host Game, in which case the methodology implemented must have the probability of error detection equal to or better than that with 16-bit CRC verification.
 
3.5    Hardware Integrity

3.5.1  The cashbox must be housed in a separate lockable cashbox compartment inside the Play- er Terminal. Access into cashbox compartment from the inside of Player Terminal must be secured with a separate lock/key used for cashbox compartment and electronic security Switch.

3.5.2  The cashbox itself must be equipped with a lockable door with a separate lock/key used for cashbox door that is required to remove the Wagering Instruments from within.

3.5.3  Wagering Instruments must not be physically retrievable from the cashbox upon acceptance and stacking, e.g. by “stringing” or “fishing”.

4.1  Ticket Reader

4.1.1   The Ticket Reader must accurately read the unique identifiers of physical Tickets, such as barcodes.

4.1.2  Ticket misreads must Tilt (disable) the affected ticket reader and be logged.

4.1.3  Ticket misreads must not communicate any incorrect information to the player.

4.1.4  Player Terminals utilizing a single Ticket Reader must disable themselves upon misreads. If the Player Terminal utilizes multiple Ticket Readers to dispense tickets from multiple games it is permissible for the Player Terminal and the unaffected Ticket Readers and their respective games to remain available for Play.

4.1.5  Operator action is required to enable any Ticket Reader or Player Terminal which has been disabled due to a misread.

4.2  Ticket Dispensing Mechanism

4.2.1  Tickets must be completely and precisely dispensed to avoid partial Tickets or multiple Tick- ets dispensed from a single Play.

4.2.2  The dispensing process must not negatively impact the integrity of Tickets by damaging Tickets or voiding security features.

4.2.3  Tickets may only be dispensed after Ticket information has been successfully verified against electronic Game Results Set (Deal).

5.1  Interaction with the Game

5.1.1  Printers must only print a Voucher upon communication initiated by the Player Terminal.

5.1.2  The entire amount of player’s cashable credits must be redeemable, e.g. printer cash-out voucher.

5.1.3  The Player Terminal must only update the relevant meters and transaction logs upon suc- cessful printing of the Voucher.

5.1.4  Voucher validation number must be printed at the Voucher leading edge.

5.1.5  A Player Terminal that uses a Voucher printer must retain in its memory and display, at a mini- mum, the following information for the last thirty-five Vouchers to resolve player disputes:

1. Date and time of Voucher issuance or acceptance;
2. Alpha and/or numeric dollar amount; and
3. Sufficient information to uniquely identify the Voucher that was printed (e.g. a partial set of uniquely identifying digits of the validation number). Player Terminal must not display complete validation numbers for unredeemed Vouchers.

5.1.6  The Player Terminal or printer must make an audible alarm or display a message to the player when the Voucher is ready for collection and must not allow the printing of another Voucher until the previous Voucher has been collected.

5.1.7  The printer must be automatically disabled as a cash-out device under any of the following conditions:

1. Player Terminal is in Game Play mode;
2. Player Terminal is in test mode other than test Ticket; and
3. Empty paper tray.

5.2  Tilt Conditions

5.2.1  The Player Terminal must disable itself under any of the following conditions until they are cleared.

1. Printer mechanism paper jam;
2. Print failure (a failed attempt to print a complete or incomplete Voucher), if the Player Terminal has no other means to make a payout. A replacement Voucher may be printed once the failure condition has been cleared;
3. Printer mechanism paper out, if the Player Terminal has no other means to make a payout; and
4. Printer disconnected, which may only be detected when a print attempt is made.

5.2.2  The Player Terminal must enter an error condition under any of the following conditions until the error condition is cleared. Game Play may continue if an alternative method is available to complete the transaction or the condition does not prohibit the transaction from being com- pleted.

1. Printer mechanism paper out;
2. Voucher presentation error, where a complete or incomplete Voucher has been printed, however, the Voucher is not presented to the player for removal; and
3. Print failure.

5.3  Printing Integrity

5.3.1  At minimum, the following information must be printed or displayed on the Voucher:

1. The name of the cGaming Site issuing the Voucher;
2. Player Terminal or printer station identifier, as applicable;
3. Date and time of issuance;
4. Payment amounts in both alphabetic and numeric characters;
5. Sequence number;
6. Unique validation number;
7. Second printing of validation number on the leading edge of the Voucher;
8. A magnetic strip or bar code consisting of at least the validation number;
9. Transaction type or other acceptable method of differentiating between Voucher/Coupon types;
10. Expiration date or period when the Voucher will expire, if applicable; and
11. At least one anti-counterfeiting measure (may be imbedded in paper stock).

5.3.2  The printer must not print duplicate Vouchers.

5.3.3  Printers must be located in a locked area of the Player Terminal, but not in the logic area.

5.3.4  In case of Player Terminal shutdown by the Backend System, the printer must complete printing of valid Voucher.

6.1.1  All significant events must be communicated from Player Terminal to the Backend System in real time or as soon as it becomes technically possible. The significant events include, but are not limited to: Player Terminal security events and error conditions, Game transactions and Game configuration changes.

6.1.2  The data communicated to/from the Player Terminal must be validated for proper logic and/ or sequence, before the Player Terminal determines its action, e.g. a bill stacked message cannot be the first message for bill acceptance and crediting.

6.1.3  Any loss of communication with Associated Equipment that impacts Game operation must be reported on Player Terminal and logged automatically.

6.1.4  During the loss of communication with external Associated Equipment, any critical informa- tion related to revenue, integrity, and security of the cGaming Equipment must be preserved and transmitted as soon as the communication resumes.

6.1.5  All Associated Equipment internal to the Player Terminal must immediately disable itself upon loss of communication with the Player Terminal.

6.1.6  All Associated Equipment internal to the Player Terminal and capable of executing a software authentication/validation process and communicating the result must have a means to do so when initiated by the Player Terminal. Player Terminal must initiate such authentication/valida- tion processes upon Game reset as a minimum.

6.1.7  Any Critical Game Data communication between Player Terminal and Backend System, such as player input, Game outcome, financial transactions, and Game recall information must be secured, e.g. encrypted using a strong encryption.

6.1.8  After program interruption (e.g. processor reset), upon program resumption, any Game func- tion or communications to an external device must not begin until the program resumption routine, including self-tests.

7.1  General Requirements

7.1.1  The Player Terminal may only accept Wagering Instruments for credit Play that are approved by the Registrar.

7.1.2  Cashable credits may be accumulated from wins, bills, Vouchers, electronic funds transfers or any other credits approved by the Registrar.

7.1.3  The total of all cashable credits accumulated from currency must not exceed $3,000.

7.1.4  It is preferred that maximum credits accumulated from currency have a separate settable limit from the other cashable credits.

7.1.5  The Player Terminal must incorporate a credit meter, which will display the player’s current credits in dollars and cents, unless the player chooses to display the current credits in credit amounts. The credit meter must default to display credits in dollars and cents for each new player.

7.1.6  The credit meter must be incremented by the proper value of credits after acceptance of a valid bill, Voucher or other Wagering Instrument approved by the Registrar, or by the value of credits won. The value of credits wagered on the Game or the value of credits redeemed by the player must be subtracted from the player’s credit meter.

7.1.7  The credit meter must be displayed to the player, at minimum, at the beginning and end of Game Play, in Idle mode and any time the player is given an option to make a Wager.

7.2  Credit Wagering

7.2.1  Wagering credits available for Play must be wagered in the following order:

1. Non-cashable credits;
2. Promotional cashable credits; and
3. All other credits defined.

7.2.2  Wagering Instruments that are less than the Player Terminal’s smallest denomination, or not evenly divisible by any of the Player Terminal’s denominations may be accepted by the Player Terminal provided either:

1. The Player Terminal has meters that record in cents and
2. The Player Terminal is capable of printing a Voucher for the remainder; or
3. The Player Terminal is capable of immediately printing a change Voucher.

Note: For clarification, 7.2.2 may be complied with by either satisfying both a) and b), or by satisfying c) on its own.
 
7.3  Credit Redemption

7.3.1  The cash-out button or its equivalent must be operational at all times when credits are displayed on the Player Terminal except:

1. During Game Play;
2. During processing of bill or Voucher;
3. When the Player Terminal is in test or Administrative Mode;
4. When the Player Terminal has an error that does not allow the collection of credits;
5. When the Player Terminal is in “out of service” mode;
6. When the Game is in jackpot (hand-pay) mode;
7. When the Player Terminal credit meter or win meter is incrementing, unless the entire amount is added to the meters when the cash-out button is pressed; or
8. When the Player Terminal is displaying a help screen, if the player’s current available cred- its are not displayed.

7.3.2  If a player attempts to redeem available credits and the total value of these credits is less than the attendant pay limit, then the Player Terminal must dispense the appropriate number of credits from the printer or by other means approved by the Registrar.

7.3.3  Whenever the amount won by a player matches or exceeds the jackpot limit, or the amount matches or exceeds the maximum payout amount (printer, or attendant pay limit, as applica- ble) during cash out, the Player Terminal must automatically lockup the Game and enter into a hand-pay mode and must not exit from this mode until the Game has been reset by the use of a reset key or other methods approved by the Registrar. The player must be alerted by a conspicuous display viewable from the front of the Player Terminal that alerts the player to see an attendant to receive full payment.

8.1  General Requirements

8.1.1  Meters must provide sufficient information to calculate Payback and to audit Wagering Instru- ments in and out at Player Terminal.

8.1.2  The Player Terminal must retain all meters required by Section 8.2.1 in a way that preserves the data after power fluctuations and for a minimum of three days after a power loss to the Player Terminal.

8.1.3  The Player Terminal must communicate meter information with the Backend System used to collect accounting information.

8.1.4  All accounting meters must be capable of being displayed on demand.

8.2  Accounting Meters

8.2.1  All Player Terminals must be equipped with electronic digital storage meters of at least 10 digits capable of displaying the information listed in this section on demand. These meters, listed below, must accumulate the following information in units equal to the denomination of the equipment or in dollars and cents. Equipment configured for multi-denomination Play must display the required information in dollars and cents.

1. Total Bet (AKA Coin In): Accumulates the total value of all Wagers, whether the wagered amount results from the insertion of currency, Vouchers, deduction from a credit meter or any other means.
2. Total Win (AKA Coin Out): Accumulates the total value of all amounts directly paid by the Player Terminal as a result of winning Wagers, whether the payout is made from the print- er, to a credit meter or by any other means. This meter will not record amounts awarded as the result of an external bonusing system or a Progressive payout, or for bills/Vouchers inserted and cashed out;
3. Total Drop (AKA Coin Drop): Accumulates the total value of all bills and Vouchers inserted into the Bill Validator for Play (NOTE: it is acceptable to have separate ‘drop’ meters for bills and Vouchers);
4. Attendant Paid Jackpots: Accumulates the total value of credits paid by an attendant re- sulting from a single winning alignment or combination, the amount of which is not capa- ble of being paid by the Player Terminal itself. This does not include Progressive amounts or amounts awarded as a result of an external bonusing system;
5. Attendant Paid Cancelled Credits: Accumulates the total value of credits paid by an atten- dant when Player Terminal is unable to make the proper payout;
6. Bill In: Accumulates the total value of currency accepted. Additionally, the Player Terminal must have a specific meter for each denomination of currency accepted that records the number of bills accepted of each denomination;
7. Voucher In: Accumulates the total value and number of all Vouchers accepted by the Play- er Terminal;
8. Voucher Out: Accumulates the total value and number of all Vouchers and payout receipts issued by the Player Terminal;
9. Non-Cashable Electronic Promotion In: Accumulates the total value of non-cashable cred- its electronically transferred to the Player Terminal from a Promotional Account by means of an external connection between the Player Terminal and a Cashless Wagering system;
10. Cashable Electronic Promotion In: Accumulates the total value of cashable credits elec- tronically transferred to the Player Terminal from a Promotional Account by means of an external connection between the Player Terminal and a Cashless Wagering system;
11. Cashable Promotion Credits Wagered: Accumulates the total value of promotional cash- able credits which are wagered. This includes credits that are transferred to the Player Terminal electronically or through the acceptance of a Wagering Instrument;
12. Non-Cashable Electronic Promotion Out: Accumulates the total value of non-cashable credits electronically transferred from the Player Terminal to a Promotional Account by means of an external connection between the Player Terminal and a Cashless Wagering system;
13. Cashable Electronic Promotion Out: Accumulates the total value of cashable credits elec- tronically transferred from the Player Terminal to a Promotional Account by means of an external connection between the Player Terminal and a Cashless Wagering system;
14. Coupon Promotion In: Accumulates the total value of all promotional Coupons accepted by the Player Terminal;
15. Coupon Promotion Out: Accumulates the total value of all promotional Coupons issued by the Player Terminal; and
16. Such other meters as may be required by the Registrar.

8.2.2  For a Player Terminal that does not use the associated functionality in the field, the Registrar may waive Section 8.2.1 i) through o).

8.2.3  No accounting imbalance may exist due to rounding.

8.2.4  Electronic meters must only be available for display in audit mode.

8.2.5  Electronic meters must be updated at the Player Terminal and replicated at the Backend Sys- tem at the time of transactions with the actual date and time stamp.

9.1.1  The Player Terminal must provide the following Administrative Modes:

1. Audit mode - used for the purposes of verifying the last Game including any status indicators and meters;
2. Game option mode - for setting and verification of Game options; and
3. Diagnostic mode - for the testing of terminal hardware, software and communication with Associated Equipment.

9.1.2  The Player Terminal must have the following minimum diagnostic functions, if applicable:

1. Game and Associated Equipment software/firmware identification;
2. Printer test;
3. Bill Validator test; and
4. Touch screen calibration and test.

9.1.3  While the Game is in Administrative Mode, the Player Terminal must clearly indicate that it is in an Administrative Mode and not in normal Play.

9.1.4  The Player Terminal must maintain all current states of the Game, including any credits, while in Administrative Mode and must restore these states upon exiting Administrative Mode.

9.1.5  The Player Terminal must not increment any electronically stored digital meters during Ad- ministrative Mode.

9.1.6  Any credits obtained during diagnostic mode must be automatically cancelled when the Game is returned for normal Play.

9.1.7  The Administrative Mode must not allow any changes to the operation and data of the Game that will compromise security or integrity of the Player Terminal or Game.

10.1.1  The Player Terminal and/or Backend System must have the capability to set and display specific Game options. If Player Terminal is utilized, restricted technical procedures must be followed, e.g. require the use of a separate configuration program, as applicable.

Restricted Game options are those options that, if configured incorrectly, would result in a violation of one or more of these Standards in this document, or introduce a risk to the integrity, security and accounting capability of the Game that is not mitigated through other controls.

10.1.2  The Player Terminal and/or Backend System must have the capability to set and display the following Game options, as applicable:

1. Credit Limit (cash in);
2. Printer Limit (cash out); and
3. Jackpot limit (payout).

10.1.3  Once set, the Game options in 10.1.2 must only be available to be changed while the Game is in Idle mode and while there are no credits on the Player Terminal.

10.1.4  Player Terminal must be capable of being remotely disabled by a disable command issued from the Backend System.

11.1.1    Player Terminal must be capable of immediately detecting, displaying, recording in a Game error log and communicating to the Backend System, if technically possible, the conditions listed in 11.1.2.

11.1.2  The Player Terminal and all peripherals must be disabled under the following conditions, and may only be enabled after the condition has been resolved:

1. RAM error (RAM defective or Critical Game Data corrupted);
2. Critical Game Software errors, in cases such as:
   
   1. Defective Software Storage Media (SSM);
   2. Hash failure;
   3. Player Terminal application crash; and
   4. Communication errors, e.g. loss of communication with the Backend System;
3. Buffer full;
4. Ticket Reader error (the individual column dispensing Tickets may be disabled instead the entire Player Terminal);
5. Ticket dispensing jam (the individual column dispensing Tickets may be disabled instead the entire Player Terminal);
6. Ticket runaway (more than expected number of Tickets dispensed);
7. Bill Validator jam;
8. Printer mechanism paper jam;
9. Printer cassette out of paper, if there is no alternate means for the Player Terminal to make the payment;
10. Low RAM battery (this condition may be cleared by an attendant as an interim measure until the battery is replaced); and
11. Bill Validator CRC error.

11.1.3  If the Player Terminal is powered down while in an error condition listed in section 11.1.2, then upon restoring power, the error message shall still be displayed and the terminal shall remain disabled, unless power down is used as part of the error reset procedure, or if on power up the terminal checks for the error condition and detects that the error is no longer in existence.

11.1.4  The Player Terminal must, at minimum, upon completion of the current Game inform the player if there is a loss of communication with the Associated Equipment internal to the Play- er Terminal. This message must be visible to the player at all times and may only be removed after the condition has been resolved.

11.1.5  The integrity of Critical Game Data stored in Critical Memory must be continuously moni- tored for corruption by methodology that enables failure detection, backup and recovery of Critical Game Data.
 
11.1.6  In cases when a Player Terminal is disabled by the Backend System, or communication is lost with Associated Equipment, or any other unplayable error condition, the Game must com- plete current Play, print a Voucher for outstanding credits if able, and display an explanatory message. Optionally, the Game may lockup in hand-pay mode without printing the Voucher, and must not exit from this mode until it has been reset by the use of a reset key or other methods approved by the Registrar. The player must be alerted by a conspicuous display viewable from the front of the Player Terminal that alerts the player to see an attendant to receive full payment.

12.1  Game Play

12.1.1  The Player Terminal may only initiate Game Play:

1. While in Idle mode and with all doors closed;
2. After credits have been registered;
3. After the player has selected the number of credits to be bet on that Game; and
4. After the player initiates Game Play by pressing a Play button, or similar.

12.1.2  Any single Wager initiating Game Play must produce the outcome (result) from a single Tick- et only, and for one player only, regardless of associated Game features, such as Extended Play and any additional bonusing.

12.1.3  Electronic Tickets must be displayed to players upon purchase, e.g. video display. If a physical Ticket is used for Game outcome presentation, the information shown on the Ticket must match the information from video display.

12.1.4  Following the Play, any Prizes must be added to the Player Terminal’s credit meter or dis- pensed in the form of a redeemable Voucher.

12.1.5  There must be no hidden or undocumented buttons or touch points (if applicable) that affect Game Play anywhere on the screen.

12.1.6  The result of Game Play must be selected through a random selection process satisfying applicable requirements from section 21.

12.1.7  Any Game with skill factor will be evaluated on case-by case basis.

12.1.8  The theoretical probabilities, features, actions and visual representation of the Game in live Games must be preserved (the same) in electronic Games (e.g. paper bingo Games), unless otherwise disclosed to the player.

12.1.9  The Player Terminal and Backend System must not automatically alter paytables or any func- tion of the equipment based on internal computation of the hold percentage or the playing history.

12.1.10  The Player Terminal must accurately display the Game outcome as stored in the electronic database of cGaming System.

12.1.11  The following information must be clearly displayed on the Player Terminal:

1. Once Wagering options are modified and during Game Play:
   
   1. Each individual Wagering option (e.g. Wager category, amount Wagered, denomination being played) so that the player is in no doubt as to which options are being played;
2. After the Game is completed and until the player interacts with the Game again (e.g. Wa- ger placed, Wagering Instrument accepted) or the Game enters an attract mode:
   
   1. The player options selected (e.g. amount Wagered, Wager category, denomination being played) and the amount won for each individual bet for the last complete Game;
   2. The winning combinations; if a Progressive was awarded, it is sufficient to indicate the Progressive was awarded and not display the value; and
3. Whenever the player redeems credits:
   
   1. The number of credits paid (until the player interacts with the Game again or the Game enters attract mode).

12.1.12  After clearing Critical Memory, the Game must not initialize at a Top Prize or Extended Game Play trigger.

12.1.13  Player Terminal must provide players with a method to request assistance from the Operator,
e.g. auditable alarm and a message during Tilt.

12.1.14  The Game must not be adversely affected by the simultaneous or sequential activation of the various inputs and outputs, such as “Play buttons”, which might cause malfunctions or invalid results. The Registrar may request evidence from the cGaming Supplier that this has been tested.

12.1.15  Player Terminal that utilizes physical or touch screen buttons to initiate a Wager must imple- ment edge triggered activation of all buttons used to initiate Game Play or commit Wagers (i.e. buttons cannot be held down to auto initiate Wagers).

12.2  Multigames

12.2.1  The methodology employed by a player to select a particular Game for Play on a multigame Player Terminal must be clearly explained to the player and be easy to follow.

12.2.2  Multigame paytable Prizes and rules of Play must be available to the player at the Player Ter- minal, prior to the player committing to Play the Game.

12.2.3  The player must at all times be made aware of which Game has been selected for Play and is being played, as applicable.

12.2.4  The player must not be forced to Play a Game just by selecting that Game. The player must be able to return to the Game selection menu.

12.2.5  There must be no integrity impacts on Play from one Game to another Game.

12.3  Ball Drawing Games

12.3.1  Games depicting balls being drawn from a barrel (e.g. bingo) must satisfy the following re- quirements:

1. At the start of each Play only balls applicable to the Game are to be depicted;
2. Balls removed from the barrel must not be returned to the barrel except as provided by the rules of the Game;
3. The barrel must not be re-mixed except as provided by the rules of the Game; and
4. As balls drawn from the barrel must be immediately used as directed by the rules of the Game (i.e. not discarded due to adaptive behaviour by the Player Terminal).

12.4  Progressive Games

12.4.1  All Progressive, linked, standalone and mystery Prizes must be accumulated and awarded in a manner that does not disadvantage any player participating in the Game, and the integrity of such Prizes must be maintained.

12.4.2  Linked Progressive Games that are eligible for a shared Prize must have the same expecta- tion of winning that shared Prize, unless otherwise disclosed to the player. For example, if $1 Wager has a chance of one (1) in 1,000 to win the shared Prize, a $2 Wager must have the chance of winning the same shared Prize proportional to the Wager amount, i.e. (1) in 500..

12.4.3  Progressive meters must be available to all players participating in Progressive Game to view prior to committing to a bet..

12.4.4  Progressive Prize must be attainable in each Play for any of participating players, except at Wager categories that are not eligible. Such Wager categories must be disclosed to players.

12.4.5  The Progressive jackpot odds may only be capable of being changed by using Restricted Technical Procedures to make software or hardware changes

12.4.6  The changes of Progressive pools must be accurately tracked by the Backend System. The following Progressive Game audit log must be available, at a minimum:

1. Reset Prize amount;
2. The amount transferred to and from Progressive pool, if applicable;
3. The rate of increment;
4. Games played, time and date of Progressive hit; and
5. Progressive jackpot Prize awarded.

12.4.7  The Wide Area Progressive (WAP) reports on linked Player Terminals integrity, security, ac- counting and operational status must provide sufficient information to support the intended purpose. On-demand reports must be available.

12.4.8  In case of WAP Progressive jackpot event, there must be a clear audible and visual indica- tion, or another method to draw attention at the central cGaming Site providing the following information:

1. Date and time of jackpot;
2. Jackpot amount;
3. Jackpot ID (if applicable);
4. Local cGaming Site ID where the jackpot is hit; and
5. Winning Player Terminal ID.

12.4.9  In the case of WAP communication loss between local site and central site, there must be a clear indication or alarm at the central site of the specific local site, which went off-line to draw attention to the central site Operator. All Player Terminals at the off-line local site may stay in play; however, all of its Progressive information during this time must be preserved, and updated at the central site upon communication recovery. Specifically, the Progressive
Prize must be reconciled for contributions from all off-line and on-line local sites. When a Pro- gressive jackpot is hit while one of local sites is off-line, the Backend System must have the capability to reset the Progressive jackpot meter at the central site.

12.4.10  Any adjustments to the WAP Progressive meters must be performed through a procedure approved by the Registrar. At minimum, the WAP system must have additional security fea- tures to perform this function and maintain a log of all changes.

12.4.11  In the case that the central site is unavailable and the WAP Progressive jackpot cannot be processed at local sites, the linked Player Terminals at the local sites must be disabled and the appropriate message displayed to players on Progressive meters.

12.5  Other Games

12.5.1  Game behaviour of other Games such as horse/car/animal racing, golf/football and virtual re- ality will be assessed on a case by case basis based on their representation, and any associ- ated rules, of the corresponding live Games.

12.6  Extended Play

12.6.1  Player Terminals offering a bonus Game or Extended Play feature that requires player interac- tion, is prohibited from automatically making selections or initiating Games or features unless it clearly explains the auto-initiation or selection mechanism and meets one of the following requirements:

1. The player is presented with a choice and specifically acknowledges the intent to have the Player Terminal auto-initiate the bonus or Extended Play feature by means of a button press or other physical/Player Terminal interaction; or
2. The bonus or extended feature provides only one choice to the player i.e., press button to spin wheel.

12.6.2  If the Game contains a ‘bonus feature’, including a Game-within-a-Game, the following rules must be met:

1. The Game must clearly instruct the player how to proceed through the current Game state;
2. The Game must display to the players sufficient information to indicate the current prog- ress towards triggering the next bonus Game; and
3. The Game must make it clear to the player that they are in this mode to avoid the possi- bility of the player walking away from the Player Terminal not knowing the Game is in a bonus mode.

12.7  Scripting

12.7.1  Scripting may be permitted if:

1. It does not display any unachievable result; and
2. It is not otherwise deceptive in a manner that adversely affects the patron.

13.1.1  Player Terminals and/or Backend System must have the capability to display a complete Play history for the most recent Game played and nine Games prior to the most recent Game. Retention and display of prior Games is also preferred. The display must indicate the following information in a clear and understandable manner, and in the same sequence as the original Game Play:

1. Game outcome (or a representative equivalent);
2. Intermediate Play steps;
3. Information necessary to determine the credits available at the start and end of Game;
4. Wagers placed per each category, if applicable;
5. Credits won;
6. Credits cashed out; and
7. Any Progressive awarded.

13.1.2  The last Game recall must include all Extended Play activities. Player Terminals and/
or Backend system offering Games with a variable number of intermediate Play steps per Game may satisfy this requirement by providing the capability to display the last 50 Play steps.

13.1.3  The last Game recall on Player Terminal must be available in Game Idle mode, including when the Game is in an error condition, except during critical error conditions (e.g. Game freeze).

13.1.4  The Player Terminal must clearly indicate when it is in Game recall mode.

14.1  Integrity

14.1.1  Both one-ply and two-ply physical Tickets must have tamper proof design in order to pre- vent determination of winning or losing Tickets. In addition, two-ply physical Tickets must be designed with sufficient opacity of layers, adhesive, Ticket size and cuts, pull-tabs covering results and printing variations to prevent determination of winning or losing Tickets without leaving signs of tampering.

14.1.2  All symbols on the Play area of two-ply physical Tickets must be uniquely identifiable, as well as match with symbols on the Player Terminal screen and anywhere the Prize structure is displayed, including on Player Terminal help screens, sell sheets and Point of Sale materials.

14.1.3  Upon dispensing of two-ply physical Tickets, the Game result must be available to players in readable format in designated windows.

14.2  Security

14.2.1  Tickets for Play must be enrolled through restricted technical procedures, and in a way that prevents determination of Game results.

14.2.2  Player Terminal must restrict and minimize information about Tickets which could be used to predict location of large winners or the payout of a set of Tickets in Play.

14.3  Auditability

14.3.1  Two-ply physical Tickets must display the following information (parameters):

1. Ticket price;
2. Ticket unique identifier;
3. Deal (Game Results Set) unique identifier;
4. Paytable unique identifier;
5. Game Play result;
6. Winning amount, if applicable and
7. Security code/feature for high tier wins.

14.3.2  One-ply physical Tickets must display at a minimum the following information (parameters):
14.3.1 b), c) and d).

14.3.3  There must be a mechanism in place to check that no identical tickets can be sold at Player Terminals. To be considered identical, the Tickets will have all parameters from 14.3.1 the same.

14.3.4  Player Terminals must not display audit information on Tickets that would compromise Game integrity, e.g. prediction of Prizes.

15.1.1  Game Results Sets (Deals) and Subsets (Decks, Rolls) must be specified on Tickets and/or in cGaming System, as applicable with the following parameters, at a minimum:

1. Game name (theme);
2. Unique identifier;
3. Ticket price;
4. Paytable unique identifier; and
5. Theoretical Payback percentage.

15.1.2  There must be no variations of pre-defined parameters when Game Results Set and Tickets are duplicated for extended sales.

15.1.3  Electronic Game Results Sets and Subsets of Tickets must meet the following minimum requirements:

1. Finite number of Tickets; and
2. Same base Ticket price.

16.1.1  Game Results Sets must have a Fixed Paytable Structure. Variable Prizes, e.g. shares depen- dent on the number of Tickets sold are not permitted, except as additional bonuses.

16.1.2  The theoretical Payback percentage and Prize odds of Game Results Sets must be constant (a fixed number), as determined by the Fixed Paytable Structure.

16.1.3  The actual Payback of Game Results Sets for Tickets drawn without replacement must be possible to reconcile from accounting meters for tracking of Tickets (sold and unsold, winning and losing) for all Player Terminals where offered, and equal to the theoretical Payback when all tickets are accounted for.

16.1.4  The actual Payback of Game Results Sets for Tickets drawn with replacement must satisfy recognized statistical tests with respect to theoretical Payback.

16.1.5  A higher Wager must not pay less than a lower Wager for the same paytable and Wager cate- gory.

16.1.6  For multi-denomination Games, the Payback percentage for any denomination must be the same or higher than all lower denominations for the identical Game, unless the player is informed of the difference.

16.1.7  The rules of Play must clearly indicate that some Prizes may not be available from Player Terminal due to finite Deal distribution.

This section contains general Backend System requirements which apply to electronic bingo card and Ticket Games.

17.1.1  User input fields must be validated to prevent any security breaches.

17.1.2  Backend System must have ability to enable/disable Player Terminal.

17.1.3  cGaming System must not have hardcoded passwords.

17.1.4  Management, administration or configuration of the Backend System from Player Terminal must not be allowed.

17.1.5  Backend Systems must record and store complete Game events and accounting data.

17.1.6  Backend Systems must provide reports for complete inventory and status audit of activated Deals, sold and unsold Tickets, Bingo Cards etc. which are used in electronic Games.

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

1. Cashier Transactions - Information on all cash transactions handled by the system, including: cash-in, cash-out, transaction location, time and user name of the cashier performing the transaction and invalid transactions;
2. Game and player (Wagering Account) transactions – Any sales and wagering information must be tracked for full reconciliation including: terminal location of the sale, product details, cashless and currency flow, cost and Game result;
3. Security Events – any information on access and attempted authentication including: component accessed, username, success or failure of authentication, time, any changes made; and
4. Error Logs – All critical errors, such as terminal or system application crashes, failed software authentication and communication errors.

18.1  General Requirements

18.1.1  The Backend System must require player interaction to call a bingo.

18.1.2  The Backend System must detect a failure or loss of communication with any participating Player Terminal during session Play and notify the Operator.

18.2  Bingo Cards

18.2.1  If there is a data corruption or modification in the Bingo Card database, the Backend Sys- tem must have a method to detect and notify the Operator of any discrepancy and mark the cards unplayable.

18.2.2  Any changes to, or removal of card Perms from the database must not impact the log of card faces from previously played session bingo Games.

18.2.3  The Backend System must have a secure and reliable method of validating called bingos for all bingo paper products. This validation requires manual Operator acceptance for payout of paper products.

18.2.4  The Backend System must track paper products inventory and sales for reconciliation of sales values and to match inventory values, when paper products are used in electronic Game. The system must reasonably ensure that sufficient information is provided to the Op- erator to identify missing paper products prior to a session starting.

18.2.5  If the Bingo Cards used are pulled from a Perm, the data storage mechanism of the Perm must have integrity check. If the Bingo Card is generated at the time of Play by using RNG, the RNG must satisfy requirements set out in 21.1.1 and 21.1.2 of this document.

18.3  Session Bingo Game

18.3.1  Session bingo Game results may be generated by either electronic or physical RNG, which must satisfy section 21.1 or 21.2 respectively.

18.3.2  The Backend System must provide functionality to recall a drawn ball. All instances of ball re-calls must be logged. Ball recalls must be communicated to all paper and electronic bingo players.

18.3.3  All Game results must be logged.

18.4  Single-Player Bingo Game

18.4.1  All Game results generated must adhere to section 21.1 of this document

18.4.2  If the Game uses traditional 5x5 Bingo Cards with a results set of 75 balls, the odds of achieving a pattern must be the same as session bingo unless otherwise communicated to the player.
 
18.4.3  The Game may allow player to re-select their Bingo Card face prior to retrieving Game results.

18.4.4  Paytables must be protected from modifications and must also have integrity check.

18.5  Flashboard Display

18.5.1  Flashboard display is required if the system supports paper Play.

18.5.2  Estimated Prizes advertised on the flashboard display must be disclosed immediately when modified.

18.5.3  Results must be displayed on both Player Terminals and flashboard displays in real time.

18.5.4  Flashboard display must contain all information required for paper players to participate in the Game. This includes:

1. Called balls;
2. Graphical representation of winning pattern;
3. Prize of current Game;
4. Game and session name;
5. Ordinal number, if used;
6. Pre-called balls for outstanding Games for which sales are open; and
7. Any other non-standard information required for Play.

18.5.5  The Backend System must automatically detect any failure in the flashboard display, e.g. communication failure or any other that can be detected, and halt session Play until the fail- ure is resolved.

18.6  Prizing

18.6.1  Prize adjustments may only be performed through restricted means.

18.6.2  Any Prize adjustments made, or other changes to Prize structure must be logged sufficiently for audit purposes, including: user making the change, date/time and details on the change.

18.6.3  Session bingo Prizes must pay out according to the advertised Game rules.

18.6.4  Progressive Prize contributions and Ordinal balls must increment as designed and be accu- rately communicated.

18.6.5  The changes of Progressive pools and Ordinal ball values must be tracked by the Backend System to show the details of the change including: time of change, associated session, val- ue of contribution or increment change and when the value is reset to the default value.

18.6.6  The Backend System must provide functionality to either enable a “must-go” situation for Progressive Prizes to force the Prize to be paid out, or to transfer contributions to a new Prize pool. If used, this function must be logged in reports.

18.7  Reporting

18.7.1  Where the Backend System is used to track asset inventory, the following paper inventory information must be available in the reporting interface:

1. Inventory delivered to the hall;
2. Inventory assigned to cashiers or runners;
3. Inventory returned by cashiers or runners;
4. Inventory reported as damaged;
5. Sold inventory;
6. Inventory Price;
7. Date/time of the above actions; and
8. User responsible for initiating the above actions.

18.7.2  The following information must be available for each session played by the Backend System, including both electronic and paper sales for a minimum of 1 year:

1. Card face information for all participating players;
2. Ball call order including ball recalls;
3. Winning card(s);
4. User name of the caller;
5. Prizes won;
6. Sales; and
7. Progressive Prize contributions.

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:

1. Results are transmitted to the database in a fashion which preserves confidentiality of results and verifies the results came from a trusted source;
2. 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;
3. 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;
4. 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:

1. Play results;
2. Prizes paid;
3. Amount wagered;
4. Unique identifier for the Player Terminal;
5. Unique identifier for the finite set; and
6. Date/time.

20.1  Wagering Account at POS

20.1.1  Wagering Accounts must use a method of authentication to access or transfer player funds or associated information such as player activity. This authentication requires a Wagering Ac- count identifier, as well as a player supplied authentication method, such as a PIN.

20.1.2  Wagering Accounts must have a unique and non-predictable identifier. Either the player must choose this identifier, or the system will assign it pseudo-randomly. This identifier may be associated with a player, or a specific player session.

20.1.3  At the time a Wagering Account is created, a player receipt must be issued with the following information, at a minimum:

1. Location of issuance;
2. Date and time;
3. Receipt number;
4. Player ID;
5. The amount in dollars and cents;
6. Time period the funds can be used at Player Terminal; and
7. The expiry date after which the funds cannot be redeemed.

20.1.4  There must be a method of identifying a player in the event that their account PIN is lost.

20.1.5  All Wagering Account activities including transactions, changes to the account and success- ful and unsuccessful logins must be tracked at the Backend System including Wagering Account number, location of activity and activity.

20.2  Vouchers and Coupons

20.2.1  Voucher and Coupon status during transactions and on-demand must be displayed on Player Terminals and Backend System. Once redeemed, they must not be redeemable again.

20.2.2  The Backend System must be equipped to capture and store all Cashless Wagering meters. The following meter information must be captured, as applicable:

1. Voucher in;
2. Voucher out;
3. Cashable electronic promotion in;
4. Cashable electronic promotion out;
5. Non-cashable electronic promotion in;
6. Non-cashable electronic promotion out;
7. Coupon promotion in; and
8. Coupon promotion out.

20.2.3  The Backend System must have a mechanism in place to record all required meters, as specified above in Section 20.2.2 of this document, at the time a drop box is removed or on demand.

20.2.4  Vouchers and Coupons must contain the following information at a minimum:

1. Name and address of cGaming Site;
2. Value;
3. Machine readable, unique identifier;
4. Plaintext identification number;
5. Location where it was generated;
6. Message indicating how long it is redeemable for; and
7. Date and time of issuance.

20.2.5  In the event of a communication disruption, the Player Terminal may issue a single offline Voucher to clear player’s balance, which must be communicated to the Backend System im- mediately on reconnection, or lockup in hand-pay.

20.2.6  Validation numbers of unredeemed Vouchers must be appropriately masked when viewable through any display to prevent generation of counterfeit vouchers.

20.3  Reporting

20.3.1  Sufficient accounting information must be captured by the Backend System to allow for full reconciliation and audit of all Cashless Wagering transactions.

20.3.2  Reports must be available to provide information on all activities on electronic Wagering Ac- counts including purchases, Wagers and cash-outs:

1. Action performed;
2. Player balance at the time of action;
3. Date/time of action;
4. Location of action;
5. Wagering Account identifier.

20.3.3  Reports must be available to track information on all Voucher transactions, including:

1. Voucher issuance by date and identification of Player Terminal where issued;
2. Voucher redemption by date, time, and means of redemption (such as, Player Terminal and cashier station);
3. Voucher liabilities by date and time issued and by sequence number;
4. Voucher expired by date and time issued, sequence number, and identification of Player Terminal where it was issued;
5. Voucher voided by date and time issued, sequence number, and identification of Player Terminal where it was issued;
6. Voucher count in each category;
7. Player Terminal meter cashable electronic promotion in vs. Backend System cashable electronic promotion in;
8. Player Terminal meter cashable electronic promotion out vs. Backend System cashable electronic promotion out;
9. Player Terminal meter non-cashable electronic promotion in vs. Backend System non-cashable electronic promotion in;
10. Player Terminal meter non-cashable electronic promotion out vs. Backend System non-cashable electronic promotion out;
11. All cashiering activities including log on, redemptions, adjustments to Wagering Accounts deposits/withdrawals, and log off, by cashier;
12. All system generated adjustments;
13. All exceptions to include:
    
    1. Date and time of exception;
    2. Player Terminal number or user identification number and location where the exception occurred; and
    3. A description of the exception or a unique code that identifies the exception.

21.1  Software Random Number Generator

The following requirements are applicable to software Random Number Generators and their implementation.

21.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.

21.1.2  The range of random numbers must match the range used in the particular Game, or Deal size for Tickets, 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 out- comes, or Deal size, as applicable.

21.1.3  The RNG must be capable of generating all possible Game outcomes (winning and losing combinations) in each Play.

Note: due to the nature of draw, this requirement does not apply to Games with Tickets drawn without replacement.

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

21.1.5  The RNG output and its corresponding Game outcome must not be dependent upon the amount wagered, style or method of Play.

21.1.6  The RNG and/or cGaming System must implement a mechanism to prevent the determina- tion of RNG seeds.

21.1.7  RNG seed must be reinitialized, if corrupted.

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

21.1.9  Where there is a failure of the mechanism used to select Game elements, the Player Termi- nals that rely upon that mechanism must be made unavailable for Play until the failure has been rectified.

21.1.10  The cGaming System must use secure communication protocols to protect RNG and ran- dom selection process.
 
21.2  Physical Random Number Generator

In addition to the requirements 21.1.1, 21.1.2 and 21.1.10, the following are specific requirements that apply to physical RNG, which use physical properties of number designators (e.g. balls, wheels, dice) to randomly generate Game results.

21.2.1  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 (e.g. 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. The designators used must be designed to resist physical degradation. Where the desig- nators have a defined life cycle, they must be replaced within their life cycle.

22.1.1  A mechanism shall be built into the cGaming System to verify the integrity of the Critical Game Software stored at SSM that is deployed to production, including before changes are implemented, as well as on an ongoing basis to ensure the approved software is being used, and to ensure no unauthorized changes are made to the approved software.

At a minimum, the cGaming System must be successfully authenticated:

1. Immediately prior to startup;
2. Automatically at regular intervals during operation; and,
3. On demand by the Operator, or AGCO.

Note: The authentication method will be evaluated on a case-by-case basis and approved by the Registrar based on good industry practices, e.g. calculation of software SHA-1 values which are compared against a protected master list of signatures (i.e. encrypted SHA-1 values).

22.1.2  If the self-authentication fails per 22.1.1 a) and b), the software that fails authentication must enter an error condition, safely stop operation and notify the Operator.

22.1.3  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.

23.1.1  Backend System must initiate independent verification on any client device or Player Terminal Critical Game Software upon establishment of a connection with the system. When a thresh- old of unsuccessful verification attempts is reached, such client device or Player Terminal must be disabled.

Note: An alternative method based on good industry practices that mitigates this risk may be evaluated on a case-by-case basis and approved by the Registrar.