The objective of the requirements in this section is to ensure functions typically performed by Gaming Device Control Programs operate in a manner that maintains the integrity of the Game.
9.1.1 New Control Programs must undergo an independent review of the submitted source code, and the results of this review must be included with the submission of the new platform. The review must include the following topics, as a minimum:
9.1.2 Modifications to Gaming Device Control Programs that impact on one or more of the topics in standard 9.1.1 may require that an independent source code review be performed on the modifications, depending on the complexity and number of changes. These will be identified by the AGCO on a case-by-case basis.
9.1.3 The Registrar may require additional independent reviews of source code, as deemed necessary depending on the complexity of changes made, the timing of the last review, etc.
9.1.4 In conducting the independent reviews contemplated in standards 9.1.1, 9.1.2, and 9.1.3, the independent review must be certified by an individual or group not directly involved in the development of the Gaming Device who is authorized by the Gaming-Related Supplier for such certification, or an independent test lab with ISO/IEC 17025 accreditation for such work.
Guidance:
This section applies only to the aspects of a Game that are chance-based.
9.2.1 Games must draw upon a random source to select, from the complete set of possible Game outcomes, which Game outcome is provided to the player.
9.2.2 Valid output from the random source must be used for Game outcome without alteration or secondary decision by the Game.
Guidance:
The output from the random source includes all necessary scaling performed such that the output is usable by the Game.
9.2.3 The random source output(s) used in the determination of the Game outcomes must be capable of producing all possible Game outcomes required by the Game design.
9.2.4 The outputs provided by the random source must pass applicable statistical tests of Randomness, and demonstrate:
9.2.5 The random source and its outputs must not be capable of being influenced by any means (e.g. by the amount Bet, style or method of Play, Play history, etc.).
9.2.6 Gaming Devices must not alter any function of the Gaming Device based on the actual hold percentage.
9.2.7 All software-based RNGs must be cryptographically strong such that the following requirements are met:
Note: Early adoption of the above standard is encouraged. Newly developed Control Programs submitted for approval after July 1, 2020 must meet this standard.
Guidance:
Cryptographic RNGs are only required for RNGs used in the exclusive determination of game outcome (E.g. not intended for RNGs to control a fan to blow a ball onto a roulette wheel).
9.2.8 The Gaming Device must prevent RNGs used in electronic Games from being configured such that the RNG would violate standard 9.2.4 when deployed in that configuration.
9.2.9 RNGs used in electronic Games must be constructed of suitable materials and have appropriate measures in place to maintain Randomness throughout their operation, including replacement and calibration of necessary components.
Guidance:
Replacement parts may be required after a predetermined amount of time has passed in order for the RNG to comply with this requirement, and the device may require periodic maintenance to ensure the ongoing integrity of the RNG.
9.2.10 The player must not have the ability to physically interact with, come into physical contact with, or otherwise manipulate RNGs except where necessary to play the Game.
9.2.11 Gaming Devices must be able to determine if there is statistical evidence that a RNG is not performing as expected for the Game in question, and appropriately communicate this to the Operator for prompt action.
9.3.1 Mechanisms must be in place, as applicable, to set Critical Game Options and limits in a manner that ensures and maintains Game integrity, enabling the Operator to control limits for internal Controls.
9.3.2 The Gaming Devices must have the capability to set the following limits:
9.3.3 Total accumulation of all cashable credits from currency must not exceed three-thousand dollars ($3,000).
9.3.4 The Gaming Device must be designed so that setting and changing the limits specified in standards 9.3.2 and 9.3.3, and setting and changing Critical Game Options can only be performed by authorized personnel, through the use of a Restricted Technical Procedure.
9.3.5 Changes made to Game options (Game configurations) are considered significant events and these changes must be stored securely with the appropriate time stamp in one or more logs which maintain at minimum the last 100 significant events since the last memory clear was performed.
9.4.1 Gaming Devices must provide the ability to view Game configuration and to verify proper operation of the Game without compromising Game integrity.
9.4.2 Gaming Devices must provide the capability to perform the following activities at minimum, as applicable:
9.4.3 The Game must limit entry into the diagnostic or test mode through a mechanism that is accessible only to the Operator’s authorized personnel.
9.4.4 When diagnostic or test mode is entered:
9.5.1 The Gaming Device must be capable of immediately detecting, recording, and displaying error conditions that could affect the Game’s integrity (e.g. door open, memory corruption, Critical Software authenticity check failure, cashbox removed, low Random Access Memory battery, reel spin errors, etc.).
9.5.2 Immediately upon an error condition from standard 9.5.1 being detected, the Gaming Device and all peripherals must be Disabled and may only be enabled after the error condition has been resolved.
9.5.3 The Gaming Device must be capable of immediately detecting, recording, and displaying appropriate error conditions that could affect the operational capabilities of the Game (e.g. Bill Validator jam, printer paper out, cashbox full, etc.).
9.5.4 Immediately upon an error condition from standard 9.5.3 being detected, the affected peripherals must be Disabled and may only be enabled after the error condition has been resolved.
9.5.5 Immediately upon an error condition from standards 9.5.1 or 9.5.3 being detected, the Gaming Device must accurately communicate the error condition to the Slot Monitoring System connected to the Gaming Device, if technically possible.
9.5.6 A mechanism must be in place to ensure when error conditions from standards 9.5.1 or 9.5.3 occur, that Gaming Site surveillance is alerted (e.g. via tower lights, etc.).
9.5.7 Error conditions from 9.5.1 and 9.5.3 are considered significant events and these error conditions must be stored securely with the appropriate time stamp in one or more logs which maintain at minimum the last 100 significant events.
9.6.1 Gaming Devices must be capable of being remotely Disabled by a Disable command issued from the Slot Monitoring System.
9.6.2 In the event the Slot Monitoring System communicates to the Gaming Device that the Gaming Device is to be Disabled (e.g. through the protocol), the Gaming Device must disable itself without impacting the integrity of the Gaming Device, and allow cash out of any credits