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.