PART 547—MINIMUM TECHNICAL STANDARDS FOR CLASS II GAMING SYSTEMS AND EQUIPMENT Authority: 25 U.S.C. 2706(b). Source: 77 FR 58479, Sept. 21, 2012, unless otherwise noted. § 547.1 What is the purpose of this part? The Indian Gaming Regulatory Act, 25 U.S.C. 2703(7)(A)(i), permits the use of electronic, computer, or other technologic aids in connection with the play of Class II games. This part establishes the minimum technical standards governing the use of such aids. § 547.2 What are the definitions for this part? For the purposes of this part, the following definitions apply: Account access component. Account access medium. Advertised top prize. Agent. Audit mode. Cancel credit. Cashless system. Cashless transaction. CD-ROM. Chair. Class II gaming. Class II gaming system. Commission. et seq. Coupon. Critical memory. DLL. Download package. DVD. Electromagnetic interference. Electrostatic discharge. Enroll. EPROM. Fault. Financial instrument. Financial instrument acceptor. Financial instrument dispenser. Financial instrument storage component. Flash memory. Game software. Gaming equipment. Hardware. Interruption. Modification. Non-cashable credit. Patron. Patron deposit account. Player interface. Prize schedule. Program storage media. Progressive prize. Random number generator (RNG). Reflexive software. Removable/rewritable storage media. Server. Test/diagnostics mode. Testing laboratory. TGRA. Unenroll. Voucher. Voucher system. § 547.3 Who is responsible for implementing these standards? (a) Minimum standards. (b) No limitation of technology. (c) Only applicable standards apply. (d) State jurisdiction. § 547.4 What are the rules of general application for this part? (a) Fairness. (b) Approved gaming equipment and software only. (c) Proper functioning. § 547.5 How does a tribal government, TGRA, or tribal gaming operation comply with this part? (a) Gaming systems manufactured before November 10, 2008. (i) The Class II gaming system software that affects the play of the Class II game, together with the signature verification required by § 547.8(f) was submitted to a testing laboratory within 120 days after November 10, 2008, or October 22, 2012; (ii) The testing laboratory tested the submission to the standards established by §§ 547.8(b), 547.8(f), and 547.14; (iii) The testing laboratory provided the TGRA with a formal written report setting forth and certifying to the findings and conclusions of the test; (iv) The TGRA made a finding, in the form of a certificate provided to the supplier or manufacturer of the Class II gaming system, that the Class II gaming system is compliant with §§ 547.8(b), 547.8(f), and 547.14; (v) The Class II gaming system is only used as approved by the TGRA and the TGRA transmitted its notice of that approval, identifying the Class II gaming system and its components, to the Commission; (vi) Remote communications with the Class II gaming system are only allowed if authorized by the TGRA; and (vii) Player interfaces of the Class II gaming system exhibit information consistent with § 547.7(d) and any other information required by the TGRA. (2) For so long as a Class II gaming system is made available for use at any tribal gaming operation pursuant to this paragraph (a) the TGRA shall: (i) Retain copies of the testing laboratory's report, the TGRA's compliance certificate, and the TGRA's approval of the use of the Class II gaming system; (ii) Maintain records identifying the Class II gaming system and its current components; and (iii) Annually review the testing laboratory reports associated with the Class II gaming system and its current components to determine whether the Class II gaming system may be approved pursuant to paragraph (b)(1)(v) of this section. The TGRA shall make a finding identifying the Class II gaming systems reviewed, the Class II gaming systems subsequently approved pursuant to paragraph (b)(1)(v), and, for Class II gaming systems that cannot be approved pursuant to paragraph (b)(1)(v), the components of the Class II gaming system preventing such approval. (3) If the Class II gaming system is subsequently approved by the TGRA pursuant to paragraph (b)(1)(v) as compliant with paragraph (b) of this section, this paragraph (a) no longer applies. (b) Gaming system submission, testing, and approval—generally. (i) The Class II gaming system has been submitted to a testing laboratory; (ii) The testing laboratory tests the submission to the standards established by: (A) This part; (B) Any applicable provisions of part 543 of this chapter that are testable by the testing laboratory; and (C) The TGRA; (iii) The testing laboratory provides a formal written report to the party making the submission, setting forth and certifying its findings and conclusions, and noting compliance with any standard established by the TGRA pursuant to paragraph (b)(1)(ii)(C) of this section; (iv) The testing laboratory's written report confirms that the operation of a player interface prototype has been certified that it will not be compromised or affected by electrostatic discharge, liquid spills, electromagnetic interference, or any other tests required by the TGRA; (v) Following receipt of the testing laboratory's report, the TGRA makes a finding that the Class II gaming system conforms to the standards established by: (A) This part; (B) Any applicable provisions of part 543 of this chapter that are testable by the testing laboratory; and (C) The TGRA. (2) For so long as a Class II gaming system is made available for use at any tribal gaming operation pursuant to this paragraph (b) the TGRA shall: (i) Retain a copy of the testing laboratory's report; and (ii) Maintain records identifying the Class II gaming system and its current components. (c) Class II gaming system component repair, replacement, or modification. (2) A TGRA may not permit the modification of any Class II gaming system in a tribal gaming operation unless: (i) The Class II gaming system modification has been submitted to a testing laboratory; (ii) The testing laboratory tests the submission to the standards established by: (A) This part; (B) Any applicable provisions of part 543 of this chapter that are testable by the testing laboratory; and (C) The TGRA; (iii) The testing laboratory provides a formal written report to the party making the submission, setting forth and certifying its findings and conclusions, and noting compliance with any standard established by the TGRA pursuant to paragraph (c)(2)(ii)(C) of this section; (iv) Following receipt of the testing laboratory's report, the TGRA makes a finding that the: (A) The modification will maintain or advance the Class II gaming system's compliance with this part and any applicable provisions of part 543 of this chapter; and (B) The modification will not detract from, compromise or prejudice the proper functioning, security, or integrity of the Class II gaming system; (3) If a TGRA authorizes a component modification under this paragraph, it must maintain a record of the modification and a copy of the testing laboratory report so long as the Class II gaming system that is the subject of the modification remains available to the public for play. (d) Emergency Class II gaming system component modifications. (i) Necessary to correct a problem affecting the fairness, security, or integrity of a game or accounting system or any cashless system, or voucher system; or (ii) Unrelated to game play, an accounting system, a cashless system, or a voucher system. (2) If a TGRA authorizes modified components to be made available for play or use without prior testing laboratory review, the TGRA must thereafter require the hardware or software manufacturer to: (i) Immediately advise other users of the same components of the importance and availability of the update; (ii) Immediately submit the new or modified components to a testing laboratory for testing and verification of compliance with this part and any applicable provisions of part 543 of this chapter that are testable by the testing laboratory; and (iii) Immediately provide the TGRA with a software signature verification tool meeting the requirements of § 547.8(f) for any new or modified software component. (3) If a TGRA authorizes a component modification under this paragraph, it must maintain a record of the modification and a copy of the testing laboratory report so long as the Class II gaming system that is the subject of the modification remains available to the public for play. (e) Compliance by charitable gaming operations. (1) The tribal government determines that the organization sponsoring the gaming operation is a charitable organization; (2) All proceeds of the charitable gaming operation are for the benefit of the charitable organization; (3) The TGRA permits the charitable organization to be exempt from this part; (4) The charitable gaming operation is operated wholly by the charitable organization's employees or volunteers; and (5) The annual gross gaming revenue of the charitable gaming operation does not exceed $3,000,000. (f) Testing laboratories. (i) It demonstrates its integrity, independence and financial stability to the TGRA. (ii) It demonstrates its technical skill and capability to the TGRA. (iii) If the testing laboratory is owned or operated by, or affiliated with, a tribe, it must be independent from the manufacturer and gaming operator for whom it is providing the testing, evaluating, and reporting functions required by this section. (iv) The TGRA: (A) Makes a suitability determination of the testing laboratory based upon standards no less stringent than those set out in § 533.6(b)(1)(ii) through (v) of this chapter and based upon no less information than that required by § 537.1 of this chapter, or (B) Accepts, in its discretion, a determination of suitability for the testing laboratory made by any other gaming regulatory authority in the United States. (v) After reviewing the suitability determination and the information provided by the testing laboratory, the TGRA determines that the testing laboratory is qualified to test and evaluate Class II gaming systems. (2) The TGRA must: (i) Maintain a record of all determinations made pursuant to paragraphs (f)(1)(iii) and (f)(1)(iv) of this section for a minimum of three years. (ii) Place the testing laboratory under a continuing obligation to notify it of any adverse regulatory action in any jurisdiction where the testing laboratory conducts business. (iii) Require the testing laboratory to provide notice of any material changes to the information provided to the TGRA. (g) Records. [82 FR 61175, Dec. 27, 2017] § 547.6 What are the minimum technical standards for enrolling and enabling Class II gaming system components? (a) General requirements. (1) Enroll and unenroll Class II gaming system components; (2) Enable and disable specific Class II gaming system components. (b) Specific requirements. (1) Ensure that only enrolled and enabled Class II gaming system components participate in gaming; and (2) Ensure that the default condition for components must be unenrolled and disabled. § 547.7 What are the minimum technical hardware standards applicable to Class II gaming systems? (a) Printed circuit boards. (2) Switches or jumpers on all circuit boards that have the potential to affect the outcome or integrity of any game, progressive award, financial instrument, cashless transaction, voucher transaction, or accounting records must be capable of being sealed. (b) Electrostatic discharge. (c) Physical enclosures. (d) Player interface. (1) Display information to a player; and (2) Allow the player to interact with the Class II gaming system. (e) Account access components. (1) Must be constructed so that physical tampering leaves evidence of such tampering; and (2) Must provide a method to enable the Class II gaming system to interpret and act upon valid or invalid input or error condition. (f) Financial instrument storage components. (g) Financial instrument acceptors. (i) Be located within a secure and locked area, cabinet, or housing that is of a robust construction designed to resist determined illegal entry and to protect internal components; (ii) Be able to detect the entry of valid or invalid financial instruments and to provide a method to enable the Class II gaming system to interpret and act upon valid or invalid input or error condition; and (iii) Be constructed to permit communication with the Class II gaming system of the accounting information required by § 547.9(a) and by applicable provisions of any Commission and TGRA regulations governing minimum internal control standards. (2) Prior to completion of a valid financial instrument transaction by the Class II gaming system, no monetary amount related to that instrument may be available for play. For example, credits may not be available for play until a financial instrument inserted into an acceptor is secured in the storage component. (3) The monetary amount related to all valid financial instrument transactions by the Class II gaming system must be recorded as required by § 547.9(a) and the applicable provisions of any Commission and TGRA regulations governing minimum internal control standards. (h) Financial instrument dispensers. (i) Be located within a secure, locked and tamper-evident area or in a locked cabinet or housing that is of a robust construction designed to resist determined illegal entry and to protect internal components; (ii) Provide a method to enable the Class II gaming system to interpret and act upon valid or invalid input or error condition; and (iii) Be constructed to permit communication with the Class II gaming system of the accounting information required by § 547.9(a) and by applicable provisions of any Commission and TGRA regulations governing minimum internal control standards. (2) The monetary amount related to all valid financial instrument transactions by the Class II gaming system must be recorded as required by § 547.9(a), the applicable provisions of part 543 of this chapter, and any TGRA regulations governing minimum internal control standards. (i) Game Outcome Determination Components. (j) Door access detection. (k) Separation of functions/no limitations on technology. § 547.8 What are the minimum technical software standards applicable to Class II gaming systems? (a) Player interface displays. (i) The purchase or wager amount; (ii) Game results; and (iii) Any player credit balance. (2) Between plays of any game and until the start of the next play, or until the player selects a new game option such as purchase or wager amount or card selection, whichever is earlier, if not otherwise provided to the player, the player interface must display: (i) The total purchase or wager amount and all prizes and total credits won for the last game played; (ii) The final results for the last game played; and (iii) Any default purchase or wager amount for the next play. (b) Game initiation and play. (2) The Class II gaming system may not alter or allow to be altered the card permutations used for play of a Class II game unless specifically chosen by the player prior to commitment to participate in the game. No duplicate cards may be sold for any common draw. (3) No game play may commence, and no financial instrument or credit may be accepted on the affected player interface, in the presence of any fault condition that affects the outcome of the game, or while in test, audit, or lock-up mode. (4) Each player must initiate his or her participation in the play of a game. (c) Audit mode. (i) Provide all accounting functions required by § 547.9, by applicable provisions of any Commission regulations governing minimum internal control standards, and by any internal controls adopted by the tribe or TGRA; (ii) Display player interface identification; and (iii) Display software version or game identification. (2) Audit mode must be accessible by a secure method such as an agent PIN, key, or other auditable access control. (3) Accounting function data must be accessible by an agent at any time, except during a payout, during a handpay, or during play. (4) The Class II gaming system must disable financial instrument acceptance on the affected player interface while in audit mode, except during financial instrument acceptance testing. (d) Last game recall. (1) Be retrievable at all times, other than when the recall component is involved in the play of a game, upon the operation of an external key-switch, entry of an audit card, or a similar method; (2) Display the results of recalled games as originally displayed or in text representation so as to enable the TGRA or operator to clearly identify the sequences and results that occurred; (3) Allow the Class II gaming system component providing game recall, upon return to normal game play mode, to restore any affected display to the positions, forms and values displayed before access to the game recall information; and (4) Provide the following information for the current and previous four games played and must display: (i) Play start time, end time, and date; (ii) The total number of credits at the start of play; (iii) The purchase or wager amount; (iv) The total number of credits at the end of play; (v) The total number of credits won as a result of the game recalled, and the value in dollars and cents for progressive prizes, if different; (vi) For bingo games and games similar to bingo, also display: (A) The card(s) used by the player; (B) The identifier of the bingo game played; (C) The numbers or other designations drawn, in the order that they were drawn; (D) The numbers or other designations and prize patterns covered on each card; (E) All prizes won by the player, including winning patterns, if any; and (F) The unique identifier of the card on which prizes were won; (vii) For pull-tab games only, also display: (A) The result(s) of each pull-tab, displayed in the same pattern as on the tangible pull-tab; (B) All prizes won by the player; (C) The unique identifier of each pull tab; and (D) Any other information necessary to fully reconstruct the current and four previous plays. (e) Voucher and credit transfer recall. (1) Display the information specified in § 547.11(b)(5)(ii) through (vi) for the last five vouchers or coupons printed and the last five vouchers or coupons accepted; and (2) Display a complete transaction history for the last five cashless transactions made and the last five cashless transactions accepted. (f) Software signature verification. (g) Test, diagnostic, and demonstration modes. (1) Clearly indicate when that component is in the test, diagnostic, or demonstration mode; (2) Not alter financial data on that component other than temporary data; (3) Only be available after entering a specific mode; (4) Disable credit acceptance and payment unless credit acceptance or payment is being tested; and (5) Terminate all mode-specific functions upon exiting a mode. (h) Multigame. (1) Provide a display of available games; (2) Provide the means of selecting among them; (3) Display the full amount of the player's credit balance; (4) Identify the game selected or being played; and (5) Not force the play of a game after its selection. (i) Program interruption and resumption. (1) Is able to return to a known state; (2) Must check for any fault condition; (3) Must verify the integrity of data stored in critical memory; (4) Must return the purchase or wager amount to the player in accordance with the rules of the game; and (5) Must detect any change or corruption in the Class II gaming system software. (j) Class II gaming system components acting as progressive controllers. (1) Modification of progressive parameters must be conducted in a secure manner approved by the TGRA. Such parameters may include: (i) Increment value; (ii) Secondary pool increment(s); (iii) Reset amount(s); (iv) Maximum value(s); and (v) Identity of participating player interfaces. (2) The Class II gaming system component or other progressive controller must provide a means of creating a progressive balancing report for each progressive link it controls. At a minimum, that report must provide balancing of the changes of the progressive amount, including progressive prizes won, for all participating player interfaces versus current progressive amount(s), plus progressive prizes. In addition, the report must account for, and not be made inaccurate by, unusual events such as: (i) Class II gaming system critical memory clears; (ii) Modification, alteration, or deletion of progressive prizes; (iii) Offline equipment; or (iv) Multiple site progressive prizes. (k) Critical memory. (i) Accounting data; (ii) Current credits; (iii) Configuration data; (iv) Last game play recall information required by paragraph (d) of this section; (v) Game play recall information for the current game play, if incomplete; (vi) Software state (the last normal state software was in before interruption); (vii) RNG seed(s), if necessary for maintaining integrity; (viii) Encryption keys, if necessary for maintaining integrity; (ix) Progressive prize parameters and current values; (x) The five most recent financial instruments accepted by type, excluding coins and tokens; (xi) The five most recent financial instruments dispensed by type, excluding coins and tokens; and (xii) The five most recent cashless transactions paid and the five most recent cashless transactions accepted. (2) Critical memory must be maintained using a methodology that enables errors to be identified and acted upon. All accounting and recall functions must be verified as necessary to ensure their ongoing integrity. (3) The validity of affected data stored in critical memory must be checked after each of the following events: (i) Every restart; (ii) Each attendant paid win; (iii) Each attendant paid progressive win; (iv) Each sensored door closure; and (v) Every reconfiguration, download, or change of prize schedule or denomination requiring operator intervention or action. (l) Secured access. § 547.9 What are the minimum technical standards for Class II gaming system accounting functions? (a) Required accounting data. (1) Amount In: The total value of all financial instruments and cashless transactions accepted by the Class II gaming system. Each type of financial instrument accepted by the Class II gaming system must be tracked independently per financial instrument acceptor, and as required by applicable requirements of TGRA regulations that meet or exceed the minimum internal control standards at 25 CFR part 543. (2) Amount Out: The total value of all financial instruments and cashless transactions paid by the Class II gaming system, plus the total value of attendant pay. Each type of financial instrument paid by the Class II Gaming System must be tracked independently per financial instrument dispenser, and as required by applicable requirements of TGRA regulations that meet or exceed the minimum internal control standards at 25 CFR part 543. (b) Accounting data storage. (1) Accounting data must be stored with at least eight decimal digits. (2) Credit balances must have sufficient digits to accommodate the design of the game. (3) Accounting data displayed to the player may be incremented or decremented using visual effects, but the internal storage of this data must be immediately updated in full. (4) Accounting data must be updated upon the occurrence of the relevant accounting event. (5) Modifications to accounting data must be recorded, including the identity of the person(s) making the modifications, and be reportable by the Class II gaming system. (c) Rollover. (d) Credit balance display and function. (i) In audit, configuration, recall and test modes; or (ii) Temporarily, during entertaining displays of game results. (2) Progressive prizes may be added to the player's credit balance provided that: (i) The player credit balance is maintained in dollars and cents; (ii) The progressive accounting data is incremented in number of credits; or (iii) The prize in dollars and cents is converted to player credits or transferred to the player's credit balance in a manner that does not mislead the player or cause accounting imbalances. (3) If the player credit balance displays in credits, but the actual balance includes fractional credits, the Class II gaming system must display the fractional credit when the player credit balance drops below one credit. § 547.10 What are the minimum standards for Class II gaming system critical events? (a) Fault events. Event Definition and action to be taken (i) Component fault Reported when a fault on a component is detected. When possible, this event message should indicate what the nature of the fault is. (ii) Financial storage component full Reported when a financial instrument acceptor or dispenser includes storage, and it becomes full. This event message must indicate what financial storage component is full. (iii) Financial output component empty Reported when a financial instrument dispenser is empty. The event message must indicate which financial output component is affected, and whether it is empty. (iv) Financial component fault Reported when an occurrence on a financial component results in a known fault state. (v) Critical memory error Some critical memory error has occurred. When a non-correctable critical memory error has occurred, the data on the Class II gaming system component can no longer be considered reliable. Accordingly, any game play on the affected component must cease immediately, and an appropriate message must be displayed, if possible. (vi) Progressive communication fault If applicable; when communications with a progressive controller component is in a known fault state. (vii) Program storage medium fault The software has failed its own internal security check or the medium itself has some fault. Any game play on the affected component must cease immediately, and an appropriate message must be displayed, if possible. (2) The occurrence of any event identified in paragraph (a)(1) of this section must be recorded. (3) Upon clearing any event identified in paragraph (a)(1) of this section, the Class II gaming system must: (i) Record that the fault condition has been cleared; (ii) Ensure the integrity of all related accounting data; and (iii) In the case of a malfunction, return a player's purchase or wager according to the rules of the game. (b) Door open/close events. (i) Indicate that the state of a sensored door changes from closed to open or opened to closed; (ii) Disable all financial instrument acceptance, unless a test mode is entered; (iii) Disable game play on the affected player interface; (iv) Disable player inputs on the affected player interface, unless test mode is entered; and (v) Disable all financial instrument disbursement, unless a test mode is entered. (2) The Class II gaming system may return the component to a ready to play state when all sensored doors are closed. (c) Non-fault events. Event Definition (1) Player interface off during play Indicates power has been lost during game play. This condition must be reported by the affected component(s). (2) Player interface power on Indicates the player interface has been turned on. This condition must be reported by the affected component(s). (3) Financial instrument storage component container/stacker removed Indicates that a financial instrument storage container has been removed. The event message must indicate which storage container was removed. § 547.11 What are the minimum technical standards for money and credit handling? (a) Credit acceptance, generally. (2) The Class II gaming system must reject financial instruments deemed invalid. (b) Credit redemption, generally. (i) Involved in the play of a game; (ii) In audit mode, recall mode or any test mode; (iii) Detecting any sensored door open condition; (iv) Updating the player credit balance or total win accounting data; or (v) Displaying a fault condition that would prevent cash-out or credit redemption. In this case a fault indication must be displayed. (2) For cashable credits not on a player interface, the player must be allowed to cash out and/or redeem those credits at any time. (3) A Class II gaming system must not automatically pay an award subject to mandatory tax reporting or withholding. (4) Credit redemption by voucher or coupon must conform to the following: (i) A Class II gaming system may redeem credits by issuing a voucher or coupon when it communicates with a voucher system that validates the voucher or coupon. (ii) A Class II gaming system that redeems credits by issuing vouchers and coupons must either: (A) Maintain an electronic record of all information required by paragraphs (b)(5)(ii) through (vi) of this section; or (B) Generate two identical copies of each voucher or coupon issued, one to be provided to the player and the other to be retained within the electronic player interface for audit purposes. (5) Valid vouchers and coupons from a voucher system must contain the following: (i) Tribal gaming operation name and location; (ii) The identification number of the Class II gaming system component or the player interface number, as applicable; (iii) Date and time of issuance; (iv) Alpha and numeric dollar amount; (v) A sequence number; (vi) A validation number that: (A) Is produced by a means specifically designed to prevent repetition of validation numbers; and (B) Has some form of checkcode or other form of information redundancy to prevent prediction of subsequent validation numbers without knowledge of the checkcode algorithm and parameters; (vii) For machine-readable vouchers and coupons, a bar code or other form of machine readable representation of the validation number, which must have enough redundancy and error checking to ensure that 99.9% of all misreads are flagged as errors; (viii) Transaction type or other method of differentiating voucher and coupon types; and (ix) Expiration period or date. (6) Transfers from an account may not exceed the balance of that account. (7) For Class II gaming systems not using dollars and cents accounting and not having odd cents accounting, the Class II gaming system must reject any transfers from voucher systems or cashless systems that are not even multiples of the Class II gaming system denomination. (8) Voucher systems must include the ability to report redemptions per redemption location or user. § 547.12 What are the minimum technical standards for downloading on a Class II gaming system? (a) Downloads. (2) Downloads must use secure methodologies that will deliver the download data without alteration or modification, in accordance with § 547.15(a). (3) Downloads conducted during operational periods must be performed in a manner that will not affect game play. (4) Downloads must not affect the integrity of accounting data. (5) The Class II gaming system must be capable of providing: (i) The time and date of the initiation of the download; (ii) The time and date of the completion of the download; (iii) The Class II gaming system components to which software was downloaded; (iv) The version(s) of download package and any software downloaded. Logging of the unique software signature will satisfy this requirement; (v) The outcome of any software verification following the download (success or failure); and (vi) The name and identification number, or other unique identifier, of any individual(s) conducting or scheduling a download. (b) Verifying downloads. § 547.13 What are the minimum technical standards for program storage media? (a) Removable program storage media. (b) Nonrewritable program storage media. (2) All unused areas of EPROMs must be written with the inverse of the erased state (zero bits (00 hex) for most EPROMs), random data, or repeats of the program data. (3) Flash memory storage components intended to have the same logical function as ROM, must be write-protected or otherwise protected from unauthorized modification. (4) The write cycle must be closed or finished for all CD-ROMs such that it is not possible to write any further data to the CD. (5) Write protected hard disks are permitted if the hardware means of enabling the write protect is easily viewable and can be sealed in place. Write protected hard disks are permitted using software write protection verifiable by a testing laboratory. (c) Writable and rewritable program storage media. (2) Program storage must be structured so there is a verifiable separation of fixed data (such as program, fixed parameters, DLLs) and variable data. (d) Identification of program storage media. (1) Manufacturer; (2) Program identifier; (3) Program version number(s); and (4) Location information, if critical (socket position 3 on the printed circuit board). § 547.14 What are the minimum technical standards for electronic random number generation? (a) Properties. (1) Statistical randomness; (2) Unpredictability; and (3) Non-repeatability. (b) Statistical randomness. (2) Numbers or other designations produced by an RNG must pass the statistical tests for randomness to a 99% confidence level, which may include: (i) Chi-square test; (ii) Runs test (patterns of occurrences must not be recurrent); and (iii) Serial correlation test potency and degree of serial correlation (outcomes must be independent from the previous game). (iv) Equi-distribution (frequency) test; (v) Gap test; (vi) Poker test; (vii) Coupon collector's test; (viii) Permutation test; (ix) Spectral test; or (x) Test on subsequences. (c) Unpredictability. (2) Unpredictability must be ensured by reseeding or by continuously cycling the RNG, and by providing a sufficient number of RNG states for the applications supported. (3) Re-seeding may be used where the re-seeding input is at least as statistically random as, and independent of, the output of the RNG being re-seeded. (d) Non-repeatability. (1) A source of “true” randomness, such as a hardware random noise generator; or (2) A combination of timestamps, parameters unique to a Class II gaming system, previous RNG outputs, or other, similar method. (e) General requirements. (2) The use of multiple RNGs is permitted as long as they operate in accordance with this section. (3) RNG outputs must not be arbitrarily discarded or selected. (4) Where a sequence of outputs is required, the whole of the sequence in the order generated must be used in accordance with the game rules. (5) The Class II gaming system must neither adjust the RNG process or game outcomes based on the history of prizes obtained in previous games nor use any reflexive software or secondary decision that affects the results shown to the player or game outcome. (f) Scaling algorithms and scaled numbers. (1) Be independent and uniform over the range; (2) Provide numbers scaled to the ranges required by game rules, and notwithstanding the requirements of paragraph (e)(3) of this section, may discard numbers that do not map uniformly onto the required range but must use the first number in sequence that does map correctly to the range; (3) Be capable of producing every possible outcome of a game according to its rules; and (4) Use an unbiased algorithm. A scaling algorithm is considered to be unbiased if the measured bias is no greater than 1 in 50 million. § 547.15 What are the minimum technical standards for electronic data communications between system components? (a) Sensitive data. (1) RNG seeds and outcomes; (2) Encryption keys, where the implementation chosen requires transmission of keys; (3) PINs; (4) Passwords; (5) Financial instrument transactions; (6) Transfers of funds; (7) Player tracking information; (8) Download Packages; and (9) Any information that affects game outcome. (b) Wireless communications. (2) Open or unsecured wireless communications are prohibited. (3) Wireless communications must be secured using a methodology that makes eavesdropping, access, tampering, intrusion or alteration impractical. By way of illustration, such methodologies include encryption, frequency hopping, and code division multiplex access (as in cell phone technology). (c) Methodologies must be used that will ensure the reliable transfer of data and provide a reasonable ability to detect and act upon any corruption of the data. (d) Class II gaming systems must record detectable, unauthorized access or intrusion attempts. (e) Remote communications may only be allowed if authorized by the TGRA. Class II gaming systems must have the ability to enable or disable remote access, and the default state must be set to disabled. (f) Failure of data communications must not affect the integrity of critical memory. (g) The Class II gaming system must log the establishment, loss, and re-establishment of data communications between sensitive Class II gaming system components. § 547.16 What are the minimum standards for game artwork, glass, and rules? (a) Rules, instructions, and prize schedules, generally. (1) Game name, rules, and options such as the purchase or wager amount stated clearly and unambiguously; (2) Denomination; (3) Instructions for play on, and use of, the player interface, including the functions of all buttons; and (4) A prize schedule or other explanation, sufficient to allow a player to determine the correctness of all prizes awarded, including: (i) The range and values obtainable for any variable prize; (ii) Whether the value of a prize depends on the purchase or wager amount; and (iii) The means of division of any pari-mutuel prizes; but (iv) For Class II Gaming Systems, the prize schedule or other explanation need not state that subsets of winning patterns are not awarded as additional prizes (for example, five in a row does not also pay three in a row or four in a row), unless there are exceptions, which must be clearly stated. (b) Disclaimers. (1) “Malfunctions void all prizes and plays” or equivalent; and (2) “Actual Prizes Determined by Bingo (or other applicable Class II game) Play. Other Displays for Entertainment Only” or equivalent. (c) Odds notification. § 547.17 How does a TGRA apply to implement an alternate minimum standard to those required by this part? (a) TGRA approval. (2) For each enumerated standard for which the TGRA approves an alternate standard, it must submit to the Chair within 30 days a detailed report, which must include the following: (i) An explanation of how the alternate standard achieves a level of security and integrity sufficient to accomplish the purpose of the standard it is to replace; and (ii) The alternate standard as approved and the record on which the approval is based. (3) In the event that the TGRA or the tribe's government chooses to submit an alternate standard request directly to the Chair for joint government to government review, the TGRA or tribal government may do so without the approval requirement set forth in paragraph (a)(1) of this section. (b) Chair review. (2) If the Chair approves the alternate standard, the Tribe may continue to use it as authorized by the TGRA. (3) If the Chair objects to the alternate standard, the operation may no longer use the alternate standard and must follow the relevant technical standard set forth in this part. (4) Any objection by the Chair must be in written form with an explanation why the alternate standard as approved by the TGRA does not provide a level of security or integrity sufficient to accomplish the purpose of the standard it is to replace. (5) If the Chair fails to approve or object in writing within 60 days after the date of receipt of a complete submission, the alternate standard is considered approved by the Chair. The Chair may, upon notification to the TGRA, extend this deadline an additional 60 days. (c) Appeal of Chair decision.