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:
- the Wagering Instrument has been stacked in the cashbox after proper validation;
- the Bill Validator has sent the “irrevocably stacked” message to the Game; and
- 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:
- Bill jam;
- Cashbox access door opened;
- 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
- 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:
- Cashbox Removed;
- Cashbox Full;
- Hardware/Software Error;
- Validator Communication Error;
- Host Player Terminal is in Tilt, disabled or Administrative Mode; and
- 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:
- the Game has started active Play and has not displayed the final result of the current Wa- ger to the player, or
- 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”.