9. Gaming Device Control Programs

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 Source Code Review

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:

  1. Control Programs must perform in a manner that complies with section 3 entitled, “Critical Software and Data Integrity";
  2. Flow of code from calling the RNG or gathering the skill-based player input to the determination of the Game outcome: the RNG result, skill-based player input, or a combination thereof must be the only result used to determine the Game outcome.  No other routines may exist that modify the outcome, or that bypass the RNG result or skill-based player input in exchange for something else;
  3. All other procedures that use the RNG or skill-based player input: All calls to the RNG or to gather skill-based player input must be determined and accounted for, e.g. shuffling, pick both with and without substitution, pick from bonus table, input from a device based on the player’s Skill, etc.  Each call must use the output from the RNG, skill-based player input, or a combination thereof appropriately, without modification, so that the scaled output is as expected; and
  4. Redundant code or implementation of cheat code: There must not be any code that can affect the proper operation of the software (e.g. cheating, “Easter egg”, etc.).

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.

9.2 Game Randomness

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:

  1. Statistical independence;
  2. Uniform distribution over their range, for intended Game(s); and
  3. Unpredictability.

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.

Software-Based Random Number Generators (RNGs)

9.2.7 All software-based RNGs must be cryptographically strong such that the following requirements are met:

  1. Given an initial state or a sequence of past values produced by the RNG, it must be computationally impossible to predict or estimate future values;  and
  2. The RNG must periodically modify its state through use of an external source of entropy.

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

Mechanical and Hardware-Based Random Number Generators (RNGs)

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 Game Options and Limits

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:

  1. Credit Limit;
  2. Jackpot Limit;
  3. Printer or Attendant Pay Limit; and
  4. Maximum limit a player may Bet using a Gamble Feature, if applicable.

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 Diagnostic and Test Modes

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:

  1. Identify all Critical Software installed, including the name, version and cryptographic Hash or CRC value of the Critical Software;
  2. Identify the Bill Validator software name and version installed as provided by the Bill Validator with the Bill Validator software name and version displayed by the Gaming Device required to be the same as was approved, or provide an alternate method that enables the Operator to determine whether the approved Bill Validator software name and version is being utilized by the Gaming Device; and
    Note:  This standard will become effective July 1, 2020.
  3. Perform player input device (e.g. touch screen, joystick, etc.) calibration tests to enable the proper functioning of the device to be assessed against its intended operation.

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:

  1. The operation of the Game must not be affected;
  2. The security, integrity, and accounting capability of the Gaming Device must not be compromised;
  3. The Gaming Device must clearly indicate when it is in diagnostic mode, test mode, or both; and
  4. The Gaming Device must return to its original state upon exit from the diagnostic mode, test mode, or both.

9.5 Error Conditions

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 Gaming Device Remote Disable Capability

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