INTEGRITY CERTIFICATION REQUIREMENTS: CENTRAL SYSTEMS FOR SLOT MACHINES

Transcription

1 INTEGRITY CERTIFICATION REQUIREMENTS: CENTRAL SYSTEMS FOR SLOT MACHINES

2 INTRODUCTION 8 BACKGROUND 8 PURPOSE 8 GENERAL OWNERSHIP AND CONTROL OF TECHNICAL GAMING INTEGRITY DOCUMENT DOCUMENT REVISION PARAMETERS OF DOCUMENT TECHNOLOGY REGULATORY REQUIREMENTS INTERFACE DEVICES INTERFACE DEVICE HARDWARE AND SOFTWARE REQUIREMENTS CERTIFIED BATTERY BACKUP REQUIREMENTS TECHNICAL DIAGNOSTICS METERING REQUIREMENTS INFORMATION BUFFERING AND INTEGRITY CHECKING RESERVED FOR AMENDMENTS ADDRESS REQUIREMENTS CONFIGURATION ACCESS REQUIREMENTS CLEARING METERS SYSTEM HARDWARE REQUIREMENTS HARDWARE AND PLAYER SAFETY RESERVED FOR AMENDMENTS FRONT END CONTROLLER AND DATA COLLECTOR REQUIREMENTS SERVER AND DATABASE REQUIREMENTS SYSTEM CLOCK SYNCHRONIZATION FEATURE WORK STATION REQUIREMENTS JACKPOT/FILL FUNCTIONALITY JACKPOT/FILL SLIP INFORMATION SURVEILLANCE/SECURITY FUNCTIONALITY DATABASE REQUIREMENTS 13 2

3 5.01 MANAGEMENT FUNCTIONALITY PARAMETERS DATABASE ACCESS PLAYER TRACKING MODIFICATION OF PATRON INFORMATION BALANCE ADJUSTMENTS PARAMETERS ACCOUNTING FUNCTIONALITY COMMUNICATION DUE DILIGENCE GENERAL STATEMENT REGARDING COMMUNICATION ERROR RECOVERY HIERARCHY BI-DIRECTIONAL REQUIREMENTS ENCRYPTION RESERVED FOR AMENDMENTS SYSTEM FUNCTIONALITY WIRELESS TECHNOLOGY NETWORK TOPOLOGIES EVENTS EVENT FORMAT STANDARD EVENTS PRIORITY EVENTS METERS INFORMATION REQUIRED METERS REPORTING REPORTING REQUIREMENTS REQUIRED REPORTS SECURITY REQUIREMENTS ACCESS CONTROL PERSONAL IDENTIFICATION NUMBER (PIN) MANAGEMENT SYSTEM UPGRADES AND MODIFICATIONS SYSTEM APPLICATION CONTROLS 20 3

4 10.05 DATA ALTERATION DATABASE AND VALIDATION COMPONENT SECURITY SLOT PROGRAM VERIFICATION REQUIREMENTS VERIFICATION ALGORITHM TIMING SIGNATURE CALCULATIONS MINIMUM SIGNATURE ALGORITHM REQUIREMENTS SIGNATURE SEEDING SIGNATURE CALCULATION REQUIREMENTS ADDITIONAL SYSTEM FEATURES FLASH DOWNLOAD REQUIREMENTS REMOTE ACCESS REQUIREMENTS SYSTEM INTERFACES MEMORY CAPACITY SYSTEM SCALABILITY BACK UP AND RECOVERY OTHER HARDWARE TICKET VALIDATION VALIDATION PAYMENT BY TICKET PRINTER TICKET INFORMATION TICKET TYPES TICKET ISSUANCE ONLINE TICKET REDEMPTION RESERVED FOR AMENDMENTS CASHIER/CHANGE BOOTH OPERATION VALIDATION RECEIPT INFORMATION INVALID TICKET NOTIFICATION OFFLINE TICKET REDEMPTION REPORTING REQUIREMENTS PROGRESSIVE JACKPOT SYSTEMS PROGRESSIVE JACKPOT SYSTEMS DEFINED GENERAL PROGRESSIVE METER/DISPLAY REQUIREMENTS PROGRESSIVE DISPLAYS TYPES OF UPDATING DISPLAYS PROGRESSIVE DISPLAY DIGITAL LIMITATIONS RESERVED FOR AMENDMENTS PROGRESSIVE CONTROLLER REQUIREMENTS PROGRESSIVE CONTROLLER DESCRIPTION RANDOM NUMBER GENERATOR/RNG SEEDING. 28 4

5 RESERVED FOR AMENDMENTS PROGRESSIVE COMMUNICATION REQUIREMENTS SYNCHRONIZATION FEATURE SETTING THE VALUE AMOUNTS PROGRESSIVE CONTROLLER PROGRAM INTERRUPTION PROGRESSIVE RESUMPTION COMMUNICATIONS FOR SIGNALING OF A JACKPOT MONITORING OF CREDITS BET PROGRESSIVE CONTROLLER REQUIRED METERS CONTROLLER AND DISPLAY FUNCTIONS DURING PROGRESSIVE JACKPOT WIN PROGRESSIVE JACKPOT AMOUNT RESERVED FOR AMENDMENTS PROGRESSIVE CONTROLLER ERROR CONDITIONS TRANSFERRING OF PROGRESSIVE JACKPOT TIME LIMITS GAMING DEVICE REQUIREMENTS WHEN ANY PROGRESSIVE IS AWARDED PROGRESSIVE GAMING DEVICE METERING REQUIREMENTS PROGRESSIVE PERCENTAGE REQUIREMENTS AND ODDS MULTIPLE SITE PROGRESSIVE REQUIREMENTS LOCATION OF CENTRAL MONITORING SYSTEM METHOD OF COMMUNICATION FOR MULTI-SITE GAMING DEVICES DATA COLLECTION REQUIREMENT RESERVED FOR AMENDMENTS MULTI-SITE ENCRYPTION/SECURITY METHOD MULTI-SITE MONITORING CENTRAL MONITORING SYSTEM POWER SUPPLY COMMUNICATION FAILURE CENTRAL MONITORING SYSTEM REQUIRED REPORTS MULTI-SITE SYSTEM METER READINGS MULTI-SITE SYSTEM DOOR MONITORING JACKPOT WIN DURING POLL CYCLE MULTIPLE JACKPOTS DURING THE SAME POLLING CYCLE DIAGNOSTIC TESTS ON A PROGRESSIVE GAMING DEVICE BONUSING SYSTEMS BONUS SYSTEM DEFINED GENERAL CONFIGURING BONUS TRANSACTIONS ON A GAMING DEVICE AUDIT TRAILS FOR BONUSING TRANSACTIONS METER REQUIREMENTS FOR BONUSING GAMING DEVICES CENTRAL SYSTEM AUDIT TRAILS REPORTS RESERVED FOR AMENDMENTS NOTIFICATION OF A BONUS AWARD COMMUNICATION REQUIREMENTS COMMUNICATION FAILURE 37 5

6 RESERVED FOR AMENDMENTS MODIFICATION OF CRITICAL PARAMETERS PREVENTION OF UNAUTHORIZED TRANSACTIONS SYNCHRONIZATION FEATURE DIAGNOSTIC TESTS ON A BONUSING GAMING DEVICE RANDOM NUMBER GENERATOR CASHLESS SYSTEMS CASHLESS SYSTEMS DEFINED GENERAL CONFIGURING CASHLESS TRANSACTIONS ON A GAMING DEVICE AUDIT TRAILS FOR CASHLESS TRANSACTIONS METER REQUIREMENTS FOR CASHLESS GAMING DEVICES FINANCIAL AND PLAYER REPORTS CENTRAL SYSTEM SECURITY REQUIREMENTS RESERVED FOR AMENDMENTS ENCRYPTION AND RESERVED FOR AMENDMENTS SECURITY LEVELS PREVENTION OF UNAUTHORIZED TRANSACTIONS ERROR CONDITIONS CENTRAL SYSTEM AUDIT TRAILS COMMUNICATION REQUIREMENTS TRANSACTION CONFIRMATION FULL TRANSFER OF ALL TRANSACTIONS RESERVED FOR AMENDMENTS GAMING DEVICE/CARD READER REQUIREMENTS SYNCHRONIZATION FEATURE DIAGNOSTIC TESTS ON A CASHLESS GAMING DEVICE PLAYER ACCOUNTS ADDING MONEY TO A PLAYERS ACCOUNT REMOVING MONEY FROM A PLAYERS ACCOUNT MOVEMENT OF MONEY PERSONAL IDENTIFICATION NUMBER ACCOUNT BALANCE PROMOTIONAL SYSTEMS GENERAL STATEMENT CONFIGURING PROMOTION TRANSACTIONS ON A GAMING DEVICE METER REQUIREMENTS FOR PROMOTIONAL GAMING DEVICES IDENTIFYING A PROMOTIONAL DEVICE NOTIFICATION OF A PROMOTIONAL AWARD DISCLAIMERS AND FEATURE EXPIRATION RESERVED FOR AMENDMENTS 43 6

7 16.11 AUDIT TRAILS FOR PROMOTIONAL TRANSACTIONS FINANCIAL REPORTS RESERVED FOR AMENDMENTS MODIFICATION OF CRITICAL PARAMETERS PREVENTION OF UNAUTHORIZED TRANSACTIONS COMMUNICATION REQUIREMENTS FULL TRANSFER OF ALL TRANSACTIONS RESERVED FOR AMENDMENTS ERROR CONDITIONS DIAGNOSTIC TESTS ON A PROMOTIONAL GAMING DEVICE CENTRAL SYSTEM AUDIT TRAILS TRANSACTION REPORT PLAYER ACCOUNTS REMOVING PROMOTIONAL CREDITS FROM A PLAYERS ACCOUNT MOVEMENT OF PROMOTIONAL CREDITS PERSONAL IDENTIFICATION NUMBER ACCOUNT BALANCE DEFINITIONS REVISION LOG 51 7

8 Introduction The Saskatchewan Liquor and Gaming Authority (SLGA) is responsible for the regulation of gaming in Saskatchewan as mandated under The Alcohol and Gaming Regulation Act, SLGA may according to The Alcohol and Gaming Regulation Act, 1997, set the terms and conditions of gaming supplier certificates of registration. In the event that SLGA issues a gaming supplier certificate of registration to you, that certificate of registration will include a term that you shall at all times comply with all applicable Gaming Integrity Standards established by SLGA from time to time. This document outlines the technical gaming integrity standards for the central systems required to operate slot machines in casinos. Background Purpose General These standards were developed in consultation with Saskatchewan Gaming Corporation, Saskatchewan Indian Gaming Authority, Western Canada Lottery Corporation, and Saskatchewan Liquor and Gaming Authority. Additionally, documents on central systems were consulted as: Gaming Laboratories Incorporated (Standard Series 16,18,20,21, Version 1.3, November 10 th, 2000); Nevada Gaming Control Board (Technical Standards for Electronic Gaming Devices, January 15, 1999), West Virginia (limited Video Lottery Act), and discussions with other Canadian jurisdictions. These standards are intended to provide regulatory guidance to manufacturers, suppliers and gaming operators about acceptable technical gaming integrity requirements in Saskatchewan. Where practices amongst operators may differ from acceptable standards, SLGA as the regulator will review to determine acceptable practices. These standards provide the basis for consistent public policy. They are founded on objectives that meet the test for: fairness, accountability, security, honesty, reliability, and safety. 1.1 Ownership and Control of Technical Gaming Integrity Document The ownership and control of this document and all subsequent amendments rest with SLGA. 8

9 1.1.1 Document Revision Technological change in the industry may require SLGA to issue corresponding amendments and changes to previously approved standards. Reasonable notice will be given to all manufacturers, supplies, testing laboratories and operators, for implementation Parameters of Document This document is intended to outline those standards that apply to central systems for slot machines, covering: hardware, software and data base requirements, systems communications, reporting, security features, ticket validation, progressive jackpot systems, bonus systems, cashless systems, and promotional systems. SLGA recognizes that site operators may potentially have different systems providing specific features to the casino interlinked to operate transparently as one large central system for a casino. This document takes this into account and stresses that these standards shall be interpreted in either of two ways: a) The central system can be viewed as an aggregate assembly of multiple systems interlinked to operate transparently as one system, or; b) Each component of the central system can be viewed separately but the assumption will be made that all components shall operate as an aggregate assembly to form one transparent system Technology SLGA recognizes that gaming technology changes. New technology will be evaluated, as required, and the standards amended accordingly as per section of this document Regulatory Requirements Manuals Operation manuals and service manuals must be expressed in broad terms that are directly relevant to the complete gaming system. At a minimum, manufacturers must provide the following information for review to both SLGA Compliance Branch and an independent testing laboratory approved by SLGA before any system is approved for use in Saskatchewan: a) Operational manuals associated with the applicable system; b) Training manuals; c) Technical Service manuals which: Accurately depict the central system for which the manual is intended to cover; Provide adequate detail and be clear in their wording and diagrams to support use by slot technicians and other maintenance personnel; Include amaintenance schedules outlining the elements of the central system that require maintenance and the frequency at which that maintenance should be carried out; Include a maintenance checklist that enable appropriate staff to make a record of the work performed and the results of the inspection; and Include a complete list and samples of available reports that can be generated by the system. 9

10 d) Technical documentation that includes: wiring diagrams, structure diagrams, flow charts, schematics, etc. relevant to the proprietary devices specific to the gaming system. Circuit schematic diagrams must accurately depict the central system for which the diagrams are intended to cover. They must also provide adequate detail and be sufficiently clear in their wording and diagrams to enable qualified technical staff to perform an evaluation on the design of the component, and be professionally drafted in order to satisfy the above requirements; and e) Complete documentation for programming patches, fixes and any upgrades made to the system Interface Devices 2.01 Interface Device Hardware and Software Requirements Each electronic gaming device installed in the casino must have an interface device installed for communication between the electronic gaming device and the central system. The interface shall not interfere with the communication of any other devices attached/sharing the communication system either through normal communication or if a malfunction occurs with the interface device Certified The interface device shall be CSA or UL certified for use in Canada Battery Backup Requirements The interface device must retain the required information after a power loss for a period of no less than 12 months. If this data is stored in volatile RAM, a battery backup must be installed within the interface device Technical Diagnostics. The interface shall have the capability of visually indicating the status of communications to and (TX/Rx host) from the central system and to and from (Tx/Rx EGD). This can be utilized by LED s, seven segment displays, or any other acceptable means Metering Requirements If not directly communicating electronic gaming device meters, the interface device must maintain separate electronic meters of meters of sufficient length to preclude loss of information from rollover as provided for in the connected electronic gaming device. These electronic meters should be capable of being reviewed on demand, at the interface device level via an authorized access method, see also Section 8 Meters Information Buffering and Integrity Checking If unable to communicate the required information to the central system, the interface device must provide a means to preserve all mandatory meter and significant event information until at such time as it can be communicated to the central system, see also 7.01 Event Format and Section 8 Meters. Electronic gaming device operation may continue until 10

11 critical data will be overwritten and lost. There must be a method to check for corruption of the above data storage locations Reserved for Amendments 2.11 Address Requirements The interface device must allow for the association of a unique identification number to be used in conjunction with an electronic gaming device file on the central system. This identification number will be used by the central system to track all mandatory information of the associated electronic gaming device. Additionally, the central system should not allow for duplicate active electronic gaming device file entries of this identification number Configuration Access Requirements The interface device setup/configuration menu(s) must not be available unless using an authorized access method Clearing Meters An interface device should not have a mechanism whereby an unauthorized user can cause the loss of stored accounting meter information System Hardware Requirements 3.01 Hardware and Player Safety Individual hardware may be approved separately providing the hardware has met the outlined standards described AND the manufacturer provides documentation to SLGA describing the purpose or reason for testing equipment separately from the central system Reserved for Amendments 3.03 Front End Controller and Data Collector Requirements A central system may possess front end processors that gather and relay all data from the connected Data Collectors to the associated database(s). The data collectors, in turn, collect all data from connected electronic gaming devices. Communication between components must be via an approved method and at minimum conform to the communication protocol requirements stated in this document Server and Database Requirements A central system will possess a server(s), networked system or distributed systems that direct overall operation and an associated database(s) that stores all entered and collected system information System Clock A central system must maintain an internal clock that reflects the current time (24hr format) and date that shall be used to provide for the following: a) Time stamping of significant events; b) Reference clock for reporting; and c) Time stamping of all logged configuration changes. 11

12 3.06 Synchronization Feature If multiple clocks are supported, the central system shall have a facility whereby it is able to update all clocks in the central system components. This includes clocking in: cashless, bonus, progressive and promotional systems. All internal clocks shall be synchronized by the central system Work Station Requirements 4.01 Jackpot/Fill Functionality A central system must have an application that captures and processes every hand pay message from each electronic gaming device. Hand pay messages must be created for single wins (jackpots), progressive jackpots and accumulated credit cash outs (canceled credits), which result in hand pays. A fill (deposit of a predetermined, or otherwise properly authorized, token amount in an electronic gaming device s hopper) is normally initiated from a hopper empty message while a credit (removal of excess tokens from an electronic gaming device) is normally user initiated. An allowable exception to fill initiation would be where the system provides preventative or maintenance fill functionality, in which the transaction may be initiated by the system or an authorized user. Once captured by this application, there must be adequate access controls to allow for authorization, alteration, or deletion of any of the values prior to payment or execution Jackpot/Fill Slip Information The following information is required for all slips generated with some/all fields to be completed by the central system: a) Alphanumeric slip identifier; b) Date and time (shift if required) ; c) Electronic gaming device number; d) Denomination; e) Amount of fill; f) Amounts of jackpot, accumulated credit, and additional pay; g) Amount to patron; h) Total coins played and game outcome of award; i) Soft meter readings; and j) Relevant signatures as required by SLGA. The above information may vary dependent upon internal controls and may be subject to change Surveillance/Security Functionality A central system shall provide an interrogation program that enables on-line comprehensive searching of the significant event log for the present and for the previous 14 days (at minimum) through archived data or restoration from backup where maintaining such data on a live database is deemed inappropriate. The interrogation program shall have the ability to perform a search based at least on the following: a) Date and time range; b) Unique interface device/electronic gaming device identification number; and 12

13 c) Significant event number(s) Database Requirements 5.01 Management Functionality A central system must have a master electronic gaming device file which is a database of every gaming device in operation, including at minimum the following information for each entry. If the central system retrieves any of these parameters directly from the electronic gaming device, sufficient controls must be in place to ensure accuracy of the information. Additionally, the central system must accommodate the use of redemption units for use by track fills Parameters The central system shall maintain the following information for gaming equipment associated with the central system: a) Unique serial number of the electronic gaming device; b) Electronic gaming device identification number as assigned by the casino; c) Location; d) Device description; e) Game name or theme; and f) Configuration; i. Denomination; ii. Software version/ control program(s) within gaming device; iii. Theoretical hold of the gaming device; and iv. Progressive status Database Access The central system shall have no built-in facility whereby a casino user/operator can bypass system auditing to modify the database directly. Casino operators will maintain secure access control. All information related to files, internal and external transactions, terminals and programs must be protected to prevent unauthorized access, modification or destruction of data. See Section Security Requirements for further database information Player Tracking At no time shall the database be designed to record information that may breach The Personal Information Protection and Electronic Documents Act Modification of Patron Information Only an authorized, logged employee shall change player information. Security of this information (including patron PIN codes or equivalent patron identification) must be guaranteed at all times. 13

14 5.06 Balance Adjustments Any adjustment to an account balance outside of the normal methodology would require a supervisor s approval with all changes being logged and/or reported indicating who, what, when, and the item value before and after the change, with the reason Parameters The central system shall maintain the following information for player tracking associated with the central system. a. Name; b. Mailing address; c. Postal code; d. Phone number and or fax number; e. address (optional); f. Player loyalty information (e.g. games played, number of days active, time on device, etc ); and g. Game play patterns. However, at no time shall the database track information that may breach legislated privacy laws in accordance to the Criminal Code of Canada and The Personal Information Protection and Electronic Documents Act Accounting Functionality A central system must have an application that allows controlled access to all accounting (financial) information. This application shall be able to create all mandatory reports in Section 9.01 Reporting Requirements, as well as all required internal control reports Communication 6.01 Due Diligence It is the responsibility of the manufacturer to ensure that the central system be designed to be as impervious to communications. It is up to the manufacturer of the central system to ensure that the system is tolerant of: noise such as common mode noise; AC noise; Signal attenuation and distortion; Signal termination; Ground loops; Shorting of any pair in communication wiring; and Open termination General Statement Regarding Communication A central system must support a defined communication protocol(s) that provides for the following: a) All critical data communication shall be protocol based and/or incorporate an error detection and correction scheme to ensure an accuracy of data received; and 14

15 b) All critical data communication that may affect revenue and is unsecured either in transmission or implementation shall employ encryption. The encryption algorithm shall employ variable keys, or similar methodology to preserve secure communication Error Recovery The following conditions apply to error recovery: a) The communications protocol must cater for recovery of messages when they are received in error or not received at all; b) There must be positive acknowledgment of all valid data messages received. Note that this requirement implies two (2) way communications are mandatory; c) Where multiple messages may have been sent it must be clear which messages have been positively acknowledged; and d) There must be a method of automatic repeat request (ARQ) of messages received in error. Implementations may include negative acknowledgment (NAK) of messages received in error or time-out Hierarchy a) For informational purposes, the manufacture shall provide all relevant protocol specifications employed by the central system; 6.05 Bi-Directional Requirements Significant emphasis shall be placed on the integrity of the communication system for cashless gaming. With the requirement of two-way communication where credits or awards are transferred bi-directionally from the central system and the gaming device, the security of the system is paramount. Slot central systems will be held to the strictest and highest standards to ensure that: a) The physical network is designed to provide exceptional stability and limited communication errors; b) The system is stable and capable of overcoming and adjusting for communication errors in a thorough, secure and precise manner; c) Information is duly protected with the most secure forms of protection via encryption, segregation of information, firewalls, passwords, personal identification numbers and any other methods known and unknown that may facilitate the level of security mandated by SLGA Encryption For Non-Cashless systems, the following is preferred, but not mandatory. For Cashless System, the following is MANDATORY Security messages that traverse data communications lines must be encrypted using the best known form of encryption available at the time. The intent is that communications be demonstrably secure against crypto-analytic attacks. At a minimum the following data must be transmitted in encrypted format to/from the central system: a) Signature seeds (algorithm coefficients); b) Signature results; c) Encryption keys, where the implementation chosen requires transmission of keys; 15

16 d) Software uploads and downloads of any security related software (e.g. signature, RNG, game result determination, payout software); and e) Other security related information. See SECURITY REQUIREMENTS for further details Reserved for Amendments 6.11 System Functionality The central system must have the ability to perform the following: a) The ability to enable/disable gaming device; b) The ability to retrieve a snap shot of information as it pertains to financial and games played on a specific gaming device; and c) The ability to retrieve security data from a specific gaming device; The optional ability to solicit an internal self test from an individual gaming device or group of devices which will report the state of internal components Wireless Technology Non-critical applications The use of wireless technology is acceptable for the purposes of building efficiency and cost savings into areas where no critical information is being transmitted or received. Areas of inclusion are: i) Any situation where the signal is used to trigger an alarm, noise or sound used to inform the public of a prize won; and ii) Update promotional messaging or other information Critical applications Wireless technology is not allowed for use to transmit or receive any information that pertains to credits, personal identification number (PIN), player tracking, TITO, cashless gaming, or related functions. At this time, SLGA deems wireless technology to have inadequate security measures to prevent fraudulent, illegal or mischievous activity. When testing evidence demonstrates that the technology is secure, SLGA will review for inclusion as an acceptable standard Network Topologies Network topologies do not require approval as long as the integrity of the central system is not compromised Events 7.01 Event Format Events generated by or occurring at an electronic gaming device are sent via the interface device to the central system utilizing an approved communication protocol. Each event must be stored in a database(s) which includes the following: a) Date and time which the event occurred; b) Identity of the electronic gaming device that generated the event; 16

17 c) A unique code that defines the event; and d) A brief text that describes the event Standard Events The following standard events must be collected from the electronic gaming device and transmitted to the system for storage: a) Power resets or power failure; b) Hand pay conditions (amount needs to be sent to the system); i. electronic gaming device jackpot (an award in excess of the single win limit of the electronic gaming device); ii. Cancelled credit hand pay; and iii. Progressive jackpot (As per jackpot above.) c) Transaction information (see other derivatives of systems included in this document for further details.) includes: i. Casino name; ii. Machine number; iii. Date and time (24hr format); iv. Alpha and numeric dollar amount of the ticket; and v. Ticket sequence number; d) Coin or Token-In errors including: i. Coin or token jams; and ii. Reverse coins or tokens-in. e) Bill (Item) Acceptor Errors including: i. Stacker Full (if supported); and ii. Bill (Note) jam. f) Electronic gaming device low RAM battery error; g) Reel spin errors (if applicable with individual reel number identified); h) Coin or token-out errors; and i) Hopper jams;) hopper runaways or extra coins paid out; j) Hopper empties (must be sent as a unique message); and k) Printer errors (if printer supported) Priority Events The following priority events must be conveyed to the central system in a timely manner: a) Loss of communication with interface device; b) Loss of communication with electronic gaming device; c) Memory corruption of the interface device; d) RAM corruption of the electronic gaming device; e) Door openings (any external door on the electronic gaming device); f) Power off door openings; and g) Failed verification attempts (if verifications are supported by central system) Meters 8.01 Information Metering information is generated on an electronic gaming device and collected by the interface device and sent to the central system via a communication protocol. This 17

18 information may be either read directly from the electronic gaming device or relayed using a delta function. As well, the central system shall be able to compensate for meter wrapping and use a meter recovery technique to prevent data loss or corruption caused by meter wrapping Required Meters The following (minimum) metering information must be communicated from the electronic gaming device: a) Total In (credits-in); b) Total Out (credits-out); c) Amount Wagered; d) Amount Won; e) Drop Meter; f) Handpays (cancel credit); g) Bills In (total monetary value of all bills accepted); h) Items In (total value of all items accepted); i) Individual Bill Meters (total number of each bill accepted per denomination); j) Games Played (strokes); k) Cabinet Door (instance meter which may be based on central system count of this event); and l) Drop Door(s) (instance meter which may be based on central system count of this event). NOTE: Please refer to the SLGA SLOT MACHINE INTEGRITY STANDARDS, Section 4.56 Electronic Accounting and Section 3.68 Machine Metering of Bill Acceptor Events for the electronic accounting meters that are to be maintained by the electronic gaming device. While these electronic accounting meters should be communicated directly from the electronic gaming device to the central system, it is acceptable to use secondary central system calculations where appropriate Reporting 9.01 Reporting Requirements Significant event and metering information is stored on the central system in a database and accounting reports are subsequently generated by querying the stored information. The central system must have built in functions to permit the following: exportation data, investigation of anomalies, archiving of data, restoration of data, and ability to allow users to develop ad-hoc reports Required Reports Reports at minimum will consist of the following: a) Net win report for each electronic gaming device; b) Monthly electronic gaming device revenue summary; c) Drop comparison reports for each medium dropped (examples = coins, bills) with variances for each medium; d) Metered vs. actual jackpot comparison report; e) Theoretical hold vs. actual hold comparison with variances; f) Significant event log for each electronic gaming device; g) A network topology report; 18

19 h) A network status report that indicates, at a minimum, the status of devices interfaced within the communication network globally and locally; and, i) Security events Security Requirements Access Control The entire system shall maintain all accounting information, game data, reporting and other information critical and non-critical in a secure manner. Access shall be designated in a hierarchal manner with the appropriate password, PIN protection and any other safeguards deemed applicable by SLGA. The central system shall be designed with security and audit ability in mind to enable limited, controlled and monitored use of personnel. Reports and other system output must be available to authorized individuals only. The central system application and operation software must provide the ability to manage individual user privileges, perform system related functions, and view information. Access rights must be granted specifically and not by default. The central system must have a method to maintain a system access listing for all authorized users that reflects the access privileges of all authorized users. This listing may be maintained electronically or in printed form (i.e., hard copy). System access must be limited to authorized individuals only, and only at the appropriate level. At a minimum, the system access listing must include the user s name, position, level of authority, authorized functions, and date the authority was granted. All authorized users must be reflected on the system access listing which includes any vendor personnel who have onsite access rights and/or remote access privileges. (All remote access, both during and subsequent to the test period, must be documented on an on-going basis.) The central system must support either: a) A hierarchical role structure whereby user and password define program; b) Individual menu item access; or c) Logon program/device security based strictly on user and password or PIN. The central system shall maintain a configurable log of access to alert and trace system activity to specific users which includes: i) Identification; ii) Date and time signed in; iii) Date and time signed out; iv) What change was made; v) Which data was affected; and vi) The original data. 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. There must be 19

20 comprehensive password protection at both the operating system and application level that includes, but isn t limited to: a) The capability to force a password expiration; b) Encrypt passwords; c) No password display; d) Allow users to change their own passwords; and e) Force the format of password structure Personal Identification Number (PIN) Management If PINs are used in any manner within an electronic gaming device and/or the support system, the PIN creation algorithm, its implementation and operational procedures (i.e. PIN changes, database storage, security and distribution) must all be approved. The storage of PINs must be in an encrypted non-reversible form. This means that if a person reads the file that stores the PIN data, he/she must not be able to reconstruct the PINs from that data even if he/she knows the PIN creation algorithm System Upgrades and Modifications Site operators or designated agents of SLGA are responsible for all system upgrades and system modifications, and for the accuracy and integrity of system data subsequent to the upgrade or modification. Relevant information for these activities must be documented System Application Controls The central system must have adequate application controls in place to assure the accuracy of data input, integrity of system processing, and validity of system output. Some examples of these types of controls include passwords to restrict data input to authorized users, using parameters or reasonableness checks to verify the integrity of system processing, and using control totals on reports for comparison to input figures Data Alteration The central system shall not permit the alteration of any accounting or significant event log information that was properly communicated from the electronic gaming device without supervised access controls. In the event financial data is changed, an audit log must be capable of being produced to document: a) Data element altered; b) Data element value prior to alteration; c) Data element value after alteration; d) Time and date of alteration; and e) Personnel that performed alteration (user login) Database and Validation Component Security Once the validation information is stored in the database, the data may not be altered in any way. The validation system database must be encrypted or password-protected and should possess a non-alterable user audit trail to log database access. Further, the normal operation of any device that holds ticket information shall not have any options or method that may compromise ticket information. Any device that holds ticket information in its memory shall not allow removing of the information unless it has first transferred that 20

21 information to the database or other secured component(s) of the validation system. See Section 5.00 Database Requirements for further information Slot Program Verification Requirements If central system gaming device verification is supported, a central system shall provide this functionality to check electronic gaming device software. The following information must be reviewed for validity prior to implementation: a) Software signature algorithm(s); and b) Data communications error check algorithm(s) Verification Algorithm Timing If central system gaming device verification is supported, verification shall be user initiated or triggered by specific significant event(s) on the electronic gaming device. To ensure complete coverage verification should be performed after each of the following events: a) Power loss to an electronic gaming device and subsequent power up; and b) Restoration after communication loss. The signature checking process must take precedence over any other electronic gaming device operations. This means that the process cannot be interrupted by any other electronic gaming device operations Signature Calculations If supported, software signatures that are calculated on all electronic gaming devices, are to be validated by central system network Minimum Signature Algorithm Requirements If central system gaming device verification is supported, a signature algorithm must meet the following requirements: a) It must combine all of the contents of the software or data being processed (inclusive of any contiguous blank(s) and unused area(s) within the device) (i.e. each and every bit of the contents must influence the signature result); b) It must combine the bits in a complicated and cross-interactive manner. (An example of such a technique is the cyclic redundancy check (CRC) method); c) Use of primitive techniques will not be acceptable. Such techniques include (but are not limited to): i. A parity check (regardless of whether the parity check implements exclusive-or arithmetic or add-arithmetic ); or ii. A checksum (regardless of whether the checksum produces 8-bit results or 16-bit results). d) It must produce a result of at minimum16-bits in width. The algorithm must detect at least % and preferably % of all possible data errors; and e) The signature algorithm must be: i. Fast and efficient, and ii. Able to process both individual software and fixed data components and entire software suites Signature Seeding If central system gaming device verification is supported: 21

22 a) Signature algorithm "seeds" are to be supplied by the initiator of the signature request at the time of activation. b) The following principles must apply to signature seeding: i. The "seed" information is to be at minimum16 bits in length; and ii. The "seed" information is to influence the behaviour of the algorithm in a nontrivial way Signature Calculation Requirements If central system gaming device verification is supported a) If the normal signature check of the entire program exceeds sixty (60) seconds or times out, a strategy of another immediately attempting a second signature check request of the electronic gaming device programming is required. If no check is successful, a failure to verify shall be logged as a priority security event. a) Signature checks are not required for programming that provides non-critical gaming functions. Examples include: graphics and sound programming. c) A signature check of the entire range of the program must be performed for an electronic gaming device when any of the following events happen: ii. The signature seed set is changed at the interface device; iii. New firmware (programming) is installed in the electronic gaming device; iv. New software is downloaded to the electronic gaming device; v. A electronic gaming device power failure. Note that a signature check of only the secure areas of the program may be approved, but a background signature check of the entire program range must be immediately initiated and validated upon completion; vi. A RAM reset has occurred; or vii. The logic area cabinet door has been shut (after being opened); d) Additional to the situations listed above, all electronic gaming device PSD s (i.e. electronic gaming device with storage mediums that support program data downloading) must have central system initiated signature validations scheduled at least once (1) per day Additional System Features FLASH Download Requirements If supported (but not required), a central system may utilize FLASH technology to update interface device software if all of the following requirements are met and are subject to the conditions set for in Section SLOT PROGRAM VERIFICATION REQUIREMENTS : a) FLASH download functionality must be, at a minimum, password protected. The central 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; b) A non-alterable audit log must record the time/date of a FLASH download and some provision must be made to associate this log with, which version(s) of code was downloaded, and the user who initiated the download. A separate FLASH audit log report would be ideal; and c) All modifications to the download executable or flash file(s) must be submitted to an independent testing laboratory for approval. At this time, an independent testing laboratory will perform a FLASH download to the system existing at the testing laboratory and verify 22

23 operation. The laboratory will then assign signatures to any relevant executable code and flash file(s) that can be verified by an investigator in the field. Additionally, all flash files must be available to SLGA to verify the signature. The above refers to loading of new executable code only. Other program parameters may be updated as long as the process is securely controlled and subject to audit Remote Access Requirements If supported, a central system may utilize password controlled remote access to a central system as long as the following requirements are met: a) Remote access user activity log is maintained depicting logon name, time/date, duration, activity while logged in; b) No unauthorized remote user administration functionality (adding users, changing permissions, etc.); c) No unauthorized access to database other than information retrieval using existing functions; d) No unauthorized access to operating system; e) If remote access is to be continuous basis then a network filter (firewall) should be installed to protect access; f) Physical segregation and methodology of system equipment interfacing will be implemented to prevent unauthorized access into the central system, and g) Anti-virus protection will be built in where appropriate, and the system shall allow for regular anti-virus updates to be installed System Interfaces If a weigh scale interface or currency counter interface is utilized, the central system must allow methods for contingency plans that address the manner of reconstructing drop data in the event the interface fails. These methods must include a reconciliation between the weigh scale and/or currency counter and the system-generated reports. These methods must also include contingency plans in the event the weigh scale itself (or currency counter) malfunctions Memory Capacity SLGA recognizes the fact that it is difficult to determine the memory capacity requirements of the central system. However, the manufacturer shall ensure that every attempt is made to make a reasonable estimation of required capacity such that the Central System shall be equipped with the appropriate amount of memory to adequately handle all database requirements and operational requirements necessary to operate System Scalability a) Software and Hardware - The system must be designed such that it readily accepts software and hardware enhancements. b) Modularity - The central system must be designed to facilitate the ability to add additional gaming products and functions without the risk of affecting the operation of system components. 23

24 11.06 Back up and Recovery a) Back up - The central system must operate in a fault tolerant manner where a hardware or software related failure does not impact the continued operation of the central system or the gaming devices associated with it. The central system shall have sufficient redundancy and modularity so that if any single component or part of a component fails, gaming can continue. There shall be redundant copies of each log file or system database or both on the central system with open support for backups and restoration. b) Recovery Requirements - In the event of a catastrophic failure when the central system 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: i. Priority events; ii. Accounting information; iii.auditing information; and iv.specific site information such as slot file, progressive set-up, etc. If possible, the software will be capable of automatically rebuilding in the event of a hard drive failure Other Hardware The central system may be designed to permit the use of additional hardware not associated directly with gaming devices. Types of hardware that fit into this category, are, but not limited to: redemption kiosks, automated teller machines (ATM), quick jacks, etc. If utilized, these devices must use a communication protocol consistent with the requirements set forth within this document and shall not have the capacity to write information directly to the gaming database. Additionally, any hardware utilized in this manner must be tested by an approved independent gaming laboratory before being approved for use in Saskatchewan Ticket Validation Validation A ticket validation system may be entirely integrated into a central system or exist as a entirely separate entity. Ticket validation systems are generally classified into two types: bidirectional ticket systems that allow for electronic gaming device ticket insertion and ticket out only systems that do not allow this. This section primarily concerns bi-directional ticket systems. Where ticket out only systems are utilized, some of the following in this section may not apply Payment by Ticket Printer Payment by ticket printer as a method of credit redemption on an electronic gaming device is only permissible when the electronic gaming device is linked to an approved validation system or central system that allows validation of the printed ticket. Validation information shall come from the validation system or central system using a secure communication 24

25 protocol based on the criteria set forth in this document. See Section Offline Ticket Redemption Ticket Information A ticket shall contain the following printed information at a minimum: a) Casino name; b) Machine number; c) Date and time (24hr format); d) Alpha and numeric dollar amount of the ticket; e) Ticket sequence number; f) Validation number; g) Bar code or any machine readable code representing the validation number; h) Type of transaction or other method or differentiating ticket types; and i) Indication of an expiration period from date of issue, or date and time the ticket will expire (24hr format ) Ticket Types If electronic gaming device ticket generation is supported while not connected to the validation system, a ticket system must generate two different types of tickets at minimum. On-line and off-line types are denoted respectively by ticket generation either when the validation system and electronic gaming device are properly communicating or the validation system and electronic gaming device is not communicating properly. When a patron cashes out of an electronic gaming device that has lost communication with the validation system, the electronic gaming device must lockup and, print an offline ticket. The offline ticket must be visually distinct from an on-line ticket either in format or content while still maintaining all information requirements Ticket Issuance A ticket can be generated at an electronic gaming device through an internal document printer, at a player s request, by redeeming all credits. Tickets that reflect partial credits may be issued automatically from an electronic gaming device. Additionally, cashier/change booth issuance is allowed if supported by the validation system Online Ticket Redemption Tickets may be inserted in any electronic gaming device participating in the validation system providing that no credits are issued to the electronic gaming device prior to confirmation of ticket validity. The customer may also redeem a ticket at a cashier/change booth or other approved validation terminal. The central system shall be capable of allowing cross validation, or ticket redemption at multiple casino sites should an operator choose to activate this feature Reserved for amendments Cashier/Change Booth Operation All validation terminals shall be user and password controlled. Once presented for redemption, the cashier shall: a) Scan the bar code via an optical reader or equivalent; 25