1. (a)

   1. (1) Casino gaming must at a minimum utilize an online monitoring system that maintains all financial and security data.
   2. (2) The rules outlined within this section apply to all critical systems (systems that have an effect on the integrity of casino gaming).

2. (b) Phases of system testing. All critical systems must endure the following phases of tests:

   1. (1) Phase I — Within the laboratory setting; and
   2. (2) Phase II — On-site following the initial install of the system to ensure proper configuration of the equipment and installation of the security applications.

3. (c) Interface elements.

   1. (1) An interface element, where applicable, is any component within a system that is external to the operations of the casino gaming that assists in the collection and processing of data that is sent to a system.

   2. (2) All critical interface elements shall:

      1. (A) Be installed in a secure area, which may be inside the gaming devices;
      2. (B) The interface element setup/configuration menu or menus must not be available unless using an authorized access method;
      3. (C)

4. (i) When not directly communicating with gaming device meters, the interface element must maintain separate electronic meters, of sufficient length, to preclude the loss of information from meter rollovers, or a means to identify multiple rollovers, as provided for in the connected gaming device.

   1. (ii) These electronic meters should be capable of being reviewed on demand at the interface element level via an authorized access method;

      1. (D)

         1. (i) The interface element must retain the required information after a power loss for a minimum of thirty (30) days.
         2. (ii) If this data is stored in volatile RAM, a battery backup must be installed within the interface element;

      2. (E)

         1. (i) If unable to communicate the required information to the online monitoring system, the interface element must provide a means to preserve all mandatory meter and significant event information until at such time as it can be communicated to the online monitoring system.
         2. (ii) Gaming device operation may continue until critical data is overwritten and lost.
         3. (iii) There must be a method to check for corruption of the above data storage locations;

      3. (F)

         1. (i) The interface element must allow for the association of a unique identification number to be used in conjunction with a gaming device file on the online monitoring system.
         2. (ii) This identification number will be used by the online monitoring system to track all mandatory information of the associated gaming device.
         3. (iii) Additionally, the online monitoring system should not allow for a duplicate gaming device file entry of this identification number; and

      4. (G)

         1. (i) An online monitoring system may possess a front end processor that gathers and relays all data from the connected data collectors to the associated database or databases.
         2. (ii) The data collectors, in turn, collect all data from connected gaming devices.
         3. (iii) Communication between components must be a defined communication protocol or protocols and function as indicated by the communication protocol or protocols.
         4. (iv) An online monitoring system must provide for the following:
5. (a) (a) All critical data communication shall be protocol-based and/or incorporate an error detection and correction scheme to ensure an accuracy of ninety-nine percent (99%) or better of messages received; and

6. (b)

   1. (1) (b)(1) All critical data communication that may affect revenue and is unsecured either in transmission or implementation shall employ encryption.

   2. (2) (2) The encryption algorithm shall employ variable keys or similar methodology to preserve secure communication.

      1. (d)
   3. (1) System server or servers networked system or systems or distributed system or systems that direct the overall operation and an associated database or databases that store all entered and collected system information, is considered the “server”.

   4. (2)

      1. (A) In addition, the server shall maintain an internal clock that reflects the current time in twenty-four-hour format and data that shall be used to provide for the following:

         1. (i) Time stamping of significant events;
         2. (ii) Reference clock for reporting; and
         3. (iii) Time stamping of configuration changes.
      2. (B) If multiple clocks are supported, the online monitoring system shall have a facility whereby it is able to update those clocks in online monitoring system components where conflicting information could occur.

7. (e) Remote access requirements. If supported, system or systems may utilize password-controlled remote access, provided the following requirements are met:

   1. (1) A remote access user activity log is maintained depicting logon name, time/date, duration, and activity while logged in;
   2. (2) No unauthorized remote user administration functionality (adding users, changing permissions, etc.);
   3. (3) No unauthorized access to the database other than information retrieval using existing functions;
   4. (4) No unauthorized access to the operating system; and
   5. (5) If remote access is to be on a continuous basis then a network filter (firewall) should be installed to protect access.

8. (f) Security access control.

   1. (1) The online monitoring system must support either a hierarchical role structure whereby user and password define program or individual menu item access or logon program/device security based strictly on user and password or PIN.
   2. (2) In addition, the online monitoring system shall not permit the alteration of any significant log information communicated from the gaming device.
   3. (3) Additionally, there should be a provision for system administrator notification and user lockout or audit trail entry, after a set number of unsuccessful login attempts.

9. (g) Data alteration.

   1. (1) The online monitoring system shall not permit the alteration of any accounting or significant event log information that was properly communicated from the gaming device without supervised access controls.

   2. (2) In the event financial data is changed, an audit log must be capable of being produced to document:

      1. (A) Data element altered;
      2. (B) Data element value prior to alteration;
      3. (C) Data element value after alteration;
      4. (D) Time and date of alteration; and
      5. (E) Personnel that performed alteration (user login).

10. (h) System backup.

    1. (1) The system or systems shall have sufficient redundancy and modularity so that if any single component or part of a component fails, gaming can continue.

    2. (2) There shall be redundant copies of each log file or system database or both, with open support for backups and restoration.

       1. (i) Recovery requirements. In the event of a catastrophic failure when the system or systems cannot be restarted in any other way, it shall be possible to reload the system from the last viable backup point and fully recover the contents of that backup, recommended to consist of at least the following information:
    3. (1) Significant events;
    4. (2) Accounting information;
    5. (3) Auditing information; and
    6. (4) Specific site information such as device file, employee file, progressive set-up, etc.

11. (j) Downloading of interface element control. If supported, a system may utilize writable program storage technology to update interface element software if all of the following requirements are met:

    1. (1)

       1. (A) Writable program storage functionality must be, at a minimum, password-protected, and should be at a supervisor level.
       2. (B) The system can continue to locate and verify versions currently running but it cannot load code that is not currently running on the system without user intervention;

    2. (2)

       1. (A) A nonalterable audit log must record the time/date of a writable program storage download and some provision must be made to associate this log with which version or versions of code were downloaded, and the user who initiated the download.
       2. (B) A separate Download Audit Log Report would be ideal;

    3. (3)

       1. (A) All modifications to the download executable or other file or files must be submitted to the test laboratory for approval.
       2. (B) The laboratory will assign signatures to any relevant executable code and file or files that should be verified by a regulator in the field.
       3. (C) Additionally, all downloadable files must be available to a regulator to verify the signature; and

    4. (4)

       1. (A) The system must have the ability to verify the program on demand for regulatory audit purposes.
       2. (B) The above refers to loading of new system executable code only.
       3. (C) Other program parameters may be updated as long as the process is securely controlled and subject to audit.
       4. (D) The parameters will have to be reviewed on an individual basis.

12. (k) Self-monitoring of gaming system servers. The systems must implement self-monitoring of all critical interface elements (e.g., central hosts, network devices, firewalls, links to third parties, etc.) and shall have the ability to effectively notify the system administrator of the condition, provided the condition is not catastrophic.

    1. (l) Online monitoring system requirements.

    2. (1)

       1. (A) The online monitoring system shall communicate to all gaming devices for the purpose of gathering all financial data and security events.
       2. (B) The online monitoring system may perform this sole function or may also incorporate other system functions that are addressed within this part.
       3. (C) For systems that serve multiple purposes, each of the relevant sections herein shall apply.

    3. (2) Required online monitoring system functionality. At a minimum, an online monitoring system shall provide for the following security and audit ability requirements:

       1. (A)

          1. (i) An interrogation program that enables online comprehensive searching of the significant event log for the present and for the previous fourteen (14) days through archived data or restoration from backup where maintaining such data on a live database is deemed inappropriate.
          2. (ii) The interrogation program shall have the ability to perform a search based at least on the following:
13. (a) (a) Date and time range;

14. (b) (b) Unique interface element/gaming device identification number; and

    1. (c) (c) Significant event number/identifier;

       1. (B)

          1. (i) An online monitoring system must have a master gaming device file which is a database of every gaming device in operation, including at minimum the following information for each entry.
          2. (ii) If the online monitoring system retrieves any of these parameters directly from the gaming device, sufficient controls must be in place to ensure accuracy of the information.
          3. (iii) Unique interface element/location identification number.
          4. (iv) Gaming device identification number as assigned by the licensee.
          5. (v)
15. (a) (a) Denomination of the gaming device.

16. (b) (b) Please note that the denomination may reflect an alternative value, in the case of a multidenomination game.

    1. (vi) Theoretical hold of the gaming device.

       1. (vii) Control program or programs identification number within the gaming device; and

       2. (C)

          1. (i) Significant events are generated by a gaming device and sent via the interface element to the online monitoring system utilizing an approved communication protocol.
          2. (ii) Each event must be stored in a database or databases which includes the following:
17. (a) (a) Date and time on which the event occurred;

18. (b) (b) Identity of the gaming device that generated the event;

    1. (c) (c) A unique number/code that defines the event; or

       1. (d) (d) A brief text that describes the event in the local language.

    2. (3) Stored accounting meters.

       1. (A) Metering information is generated on a gaming device and collected by the interface element and sent to the online monitoring system via a communication protocol.
       2. (B) This information may be either read directly from the gaming device or relayed using a delta function.

       3. (C) The online monitoring system must collect and store the following meter information from each gaming device:

          1. (i) Total in (credits-in);
          2. (ii) Total out (credits-out);
          3. (iii) Total dropped (total value of all bills, tickets, and other approved notes in the cash box or drop);
          4. (iv) Hand paid (handpays);
          5. (v) Cancelled credits, if supported on the gaming device;
          6. (vi) Bills in (total monetary value of all bills accepted);
          7. (vii) Individual bill meters (total number of each bill accepted per denomination);
          8. (viii) Games-played;
          9. (ix) Cabinet door (instance meter which may be based on online monitoring system count of this event);
          10. (x) Drop door or doors (instance meter which may be based on online monitoring system count of this event);
          11. (xi) Tickets in (total monetary value of all tickets accepted); and
          12. (xii) Tickets out (total monetary value of all tickets produced).
       4. (D) Please refer to 23 CAR § 358-621 for more detailed descriptions of the above meters.

    3. (4) Required reports.

       1. (A) Reports will be generated on a schedule determined by the Arkansas Racing Commission which typically consists of daily, monthly, yearly period, and life to date reports generated from stored database information.

       2. (B) These reports at minimum will consist of the following:

          1. (i) Net Win/Revenue Report for each gaming device;
          2. (ii) Drop Comparison Reports for each medium dropped (examples = tickets, bills) with dollar and percent variances for each medium and aggregate for each type;
          3. (iii) Metered vs. Actual Jackpot Comparison Report with the dollar and percent variances for each and aggregate;
          4. (iv) Theoretical hold vs. actual hold comparison with variances;
          5. (v) Significant event log for each gaming device; and
          6. (vi)
19. (a) (a) Other reports, as required by individual jurisdictions.

20. (b) (b) It is acceptable to combine reporting data where appropriate (e.g., revenue, theoretical/actual comparison).

    1. (5) Jackpot functionality. An online monitoring system must have an application or facility that captures and processes every handpay message from each gaming device and meets the following rules:

       1. (A) Handpay messages must be created for single wins (jackpots), progressive jackpots, and accumulated credit cash outs (canceled credits), which result in handpay;

       2. (B)

          1. (i) For every single win event that is equal to or greater than the applicable Internal Revenue Service tax reporting threshold, as established from time to time by the Internal Revenue Service, the online monitoring system user must be advised of the need for a W2G or 1042-S Form, as required by the Internal Revenue Service, which is to be processed either via the online monitoring system or manually.
          2. (ii) This option must not be capable of being overridden.
          3. (iii) The keyed reset ability to return winnings from a taxable event to a gaming device should require user intervention to void the original jackpot slip that is generated; and

       3. (C) The following information is required for all jackpot slips generated with some/all fields to be completed by the online monitoring system:

          1. (i) Numeric slip identifier (which increments per event);
          2. (ii) Date and time (shift if required);
          3. (iii) Gaming device number;
          4. (iv) Denomination;
          5. (v) Amounts of:
21. (a) (a) Jackpot;

22. (b) (b) Accumulated credit; and

    1. (c) (c) Additional pay;

       1. (vi) W2G indication, if applicable;

          1. (vii) Additional payout, if applicable;
          2. (viii) Total before taxes and taxes withheld, if applicable;
          3. (ix) Amount to patron; and
          4. (x) Total credits played and game outcome of award.

Codification Notes: “RAM” means random-access memory.