GLI 13 v2 1 Standard

STANDARD SERIES
GLI-13:
On-Line Monitoring and Control Systems
(MCS) and Validation Systems in
Casinos
Version: 2.1
Release Date: September 06, 2011
Copyright  2011 Gaming Laboratories International, LLC All Rights Reserved.

This Page Intentionally Left Blank

A BOUT THIS STANDARD
This Standard has been produced by Gaming Laboratories International, LLC

for the purpose of providing independent certifications to suppliers under this
Standard and complies with the requirements set forth herein.
A supplier should submit equipment with a request that it be certified in

accordance with this Standard. Upon certification, Gaming Laboratories
International, LLC will provide a certificate evidencing the certification to this
Standard.


GLI Standard #13 – On-Line MCS and Validation Systems in Casinos Version 2.1
September 6, 2011
Table of Contents
CHAPTER 1 ............................................................................................................................... 7
1.0 OVERVIEW - STANDARDS FOR MONITORING AND CONTROL SYSTEMS (MCS) .....................7
1.1 Introduction ..........................................................................................................................................7
1.2 Graphical Overview .............................................................................................................................8
1.3 Acknowledgment of Other Standards Reviewed ...................................................................................9
1.4 Purpose of Standard ........................................................................................................................... 10
1.5 Other Documents That May Apply ..................................................................................................... 12
CHAPTER 2 ............................................................................................................................. 13
2.0 SYSTEM COMPONENT REQUIREMENTS .......................................................................................... 13
2.1 Interface Element Requirements ......................................................................................................... 13
2.2 Front End Controller and Data Collector Requirements ................................................................... 15
2.3 Server and Database Requirements .................................................................................................... 15
2.4 Workstation Requirements .................................................................................................................. 16
CHAPTER 3 ............................................................................................................................. 19
3.0 SYSTEM REQUIREMENTS .................................................................................................................... 19
3.1 Communication Protocol .................................................................................................................... 19
3.2 Significant Events ............................................................................................................................... 19
3.3 Meters ................................................................................................................................................. 21
3.4 Reporting Requirements ..................................................................................................................... 23
3.5 Security Requirements ........................................................................................................................ 24
3.6 Additional System Features ................................................................................................................ 24
3.7 Backups and Recovery ........................................................................................................................ 27
CHAPTER 4 ............................................................................................................................. 28
4.0 TICKET/VOUCHER VALIDATION SYSTEM REQUIREMENTS ....................................................... 28
4.1 Introduction ........................................................................................................................................ 28
4.2 Ticket/Voucher Issuance ..................................................................................................................... 28
4.3 Ticket/Voucher Redemption ................................................................................................................ 32
4.4 Reports................................................................................................................................................ 34
4.5 Security ............................................................................................................................................... 35
CHAPTER 5 ............................................................................................................................. 36
5.0 SYSTEM ENVIRONMENTAL AND SAFETY REQUIREMENTS ....................................................... 36
5.1 Introduction ........................................................................................................................................ 36
5.2 Hardware and Player Safety .............................................................................................................. 36
5.3 Environmental Effects on System Integrity ......................................................................................... 36
Table of Contents Page 5

September 6, 2011
Table of Contents Page 6

September 6, 2011
CHAPTER 1
1.0 OVERVIEW - STANDARDS FOR MONITORING AND
CONTROL SYSTEMS (MCS)
1.1 Introduction
1.1.1 On-line Monitoring and Controls System Defined. An On-line Monitoring and Control
System (MCS) is a game management system that continuously monitors each Electronic
Gaming Device via a defined communication protocol by either a dedicated line, dial-up system,
or other secure transmission method. A MCS is primarily tasked to provide logging, searching,
and reporting of gaming Significant Events, collection of individual device financial and meter
data, reconciliation of meter data against hard and soft counts, and System Security outlined in
section 4.0 of this document.
1.1.2 Phases of Certification. The approval of an On-line Monitoring and Control System
shall be certified in two phases:
a) Initial laboratory testing, where the laboratory will test the integrity of the system in
conjunction with Gaming Devices, in the laboratory setting with the equipment
assembled; and
b) On-site certification where the communications and set up are tested on the casino floor
prior to implementation.
Chapter One: Overview – Stands for Monitoring and Control Systems (MCS) Page 7
September 6, 2011
1.2 Graphical Overview
1.2.1 General Statement. The purpose of this section is to lend a visual depiction of a
generic On-line Monitoring and controls computer system and is not intended to mandate any
particular component or system topology providing functionality is maintained. The terms used
throughout this document will be represented in a block diagram format to clarify individual
components.
Multiple
Gaming Device Gaming
Devices
Interface Element
Multiple
DC’s
Data Collectors
Monitoring And
Control Systems
(MCS)
Front End Processor
(FEP)
Servers w/ Databases & Workstations
In the illustration above, this standard applies to all components referenced other than the
Gaming Device. The requirements for the Gaming Device are defined in GLI-11. This document
will only concern communications from the Gaming Device to the MCS, and not in the reverse
order, with the exception of the Ticket/Voucher Validation System Requirements that are
incorporated within Chapter 4.
September 6, 2011
1.3 Acknowledgment of Other Standards Reviewed
1.3.1 General Statement. These Standards have been developed by reviewing and using
portions of the documents from the organizations listed below. We acknowledge the regulators
who have assembled these documents and thank them:
a) The ACT Office of Financial Management;

b) The New South Wales Department of Gaming and Racing;
c) The New Zealand Casino Control Authority;
d) The New Zealand Department of Internal Affairs, Gaming Racing & Censorship
Division;
e) The Northern Territory Racing and Gaming Authority;
f) The Queensland Office of Gaming Regulation;
g) The South Australian Office of the Liquor and Gaming Commissioner;
h) The Tasmanian Department of Treasury and Finance, Revenue and Gaming Division;
i) The Victorian Casino and Gaming Authority;
j) The Western Australian Office of Racing Gaming and Liquor;
k) The SABS 1718 part 3;
l) US Tribal Compacts from Tribal Governments and State Governments included:
i. Arizona
ii. Connecticut
iii. Iowa Indian
iv. Kansas
v. Louisiana
vi. Michigan
vii. Minnesota
viii. Mississippi
ix. North Carolina
x. North Dakota
xi. Oregon
xii. Wisconsin
September 6, 2011
m) Colorado Division on Gaming – Limited Gaming Regulations;

n) Illinois Gaming Board – Adopted Rules;
o) Indiana Gaming Commission;
p) Iowa Racing and Gaming Commission;
q) Louisiana State Police – Riverboat Gaming Division – Gaming Device;
r) Missouri Gaming Commission – Department of Public Safety;
s) Nevada Gaming Commission and State Gaming Control Board;
t) New Jersey – Regulations on Accounting and Internal Controls;
u) South Dakota Commission on Gaming – Rules and Regulations for Limited Gaming.
v) NIST Special Publication 800-57 Recommendations for Key Management – Part 2: Best
Practices for Key Management Organization;
w) Nevada Regulatory 14 Technical Standards;
x) GSA G2S and S2S protocol standards; and
y) GLI-11, GLI-13, and GLI-20 Technical Standards.
1.4 Purpose of Standard
1.4.1 General Statement. The purpose of this technical standard is as follows:
a) To eliminate subjective criteria in analyzing and certifying gaming Monitoring and

Control System operation.
b) To only test those criteria which impact the credibility and integrity of gaming from both
the Revenue Collection and game play point of view.
c) To create a standard that will insure that On-Line Monitoring and Control Systems
(MCS) And Validation Systems in Casinos are fair, secure, and able to be audited and
operated correctly.
d) To distinguish between local public policy and laboratory criteria. At GLI, we believe
that it is up to each local jurisdiction to set their public policy with respect to gaming.
e) To recognize that non-gaming testing (such as Electrical Testing) should not be
incorporated into this standard but left to appropriate test laboratories that specialize in
that type of testing. Except where specifically identified in the standard, testing is not
September 6, 2011
directed at health or safety matters. These matters are the responsibility of the
manufacturer, purchaser, and operator of the equipment.
f) To construct a standard that can be easily changed or modified to allow for new
technology.
g) To construct a standard that does not specify any particular technology, method, or
algorithm. The intent is to allow a wide range of methods to be used to conform to the
standards, while at the same time, to encourage new methods to be developed.
1.4.2 No Limitation of Technology. One should be cautioned that this document should not be
read in such a way that limits the use of future technology. The document should not be
interpreted that if the technology is not mentioned, then it is not allowed. Quite to the contrary,
as new technology is developed, we will review this standard, make changes and incorporate
new minimum standards for the new technology.
1.4.3 Scope of Standard. This standard will only govern On-Line Monitoring and Control
Systems (MCS) and Validation System requirements necessary to achieve certification when
interfaced to Gaming Devices, for the purpose of communicating mandatory security events and
electronic meters. This infers that all relevant monetary transactions at the Gaming Device level
are handled through:
a) Credit Issuance:
i. Coins or tokens accepted via approved coin acceptors;
ii. Currency notes (Bills) accepted via approved bill validators; and
iii. Approved Ticket/Voucher (Items) accepted via approved Bill/ Ticket/Voucher
validators; or
iv. Player Account Cards (cashless)
b) Credit Redemption:
i. Coins or tokens paid by approved hoppers;
ii. Handpays;
iii. Ticket/Voucher (Items) paid by approved ticket/voucher printers; or
iv. Player Account Cards (cashless).
September 6, 2011
1.4.4 Exceptions to Standard. This standard does not govern MCS requirements for any other
form of monetary transaction. This standard also does not govern advanced bi-directional
communication protocols (i.e. EFT, AFT, Bonusing, Promotional, System Based Progressives,
features that utilize an RNG, etc.) that support credit transfer between Gaming Device and MCS.
This standard only supports one-way communication of events originated at the Gaming Device
level to the MCS with the exception of the Ticket/Voucher Validation System Requirements that
are incorporated within Chapter 4. This standard does not exclude Gaming Devices that operate
with Player Account Cashless transactions for the purpose of communicating mandatory security
events and electronic meters. This infers that all relevant monetary transactions at the EGD level
are handled via electronic transfer through a secure communication protocol. These device types
shall meet the applicable requirements set forth herein, specifically governing metering
information and significant events in addition to other GLI standards that may apply.
1.5 Other Documents That May Apply
1.5.1 General Statement. This standard covers the minimal requirements of an MCS and all
associated components. Please refer to the GLI website at www.gaminglabs.com for other GLI
Standards. Below are a few that may apply:
a) Gaming devices in Casinos (GLI-11);

b) Progressive Gaming devices in Casinos (GLI-12);
c) Cashless Systems in Casinos (GLI-16);
d) Bonusing Systems in Casinos (GLI-17);
e) Promotional Systems in Casinos (GLI-18);
f) Individual Gaming Commission Minimum Internal Control Procedures;
g) Redemption Terminals (GLI-20);
h) Client-Server Systems (GLI-21); and
i) Wireless Gaming Systems (GLI-26).
September 6, 2011
CHAPTER 2
2.0 SYSTEM COMPONENT REQUIREMENTS
2.1 Interface Element Requirements
2.1.1 General Statement. Each Gaming Device installed in the casino must have a device or
facility (interface element) installed inside a secure area of the Gaming Device, that provides for
communication between the Gaming Device and an external Data Collector.
2.1.2 Metering Requirements. If not directly communicating 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. These electronic meters should be capable of being
reviewed on demand, at the interface element level via an authorized access method, see also
Section 3.3 ‘Meters.’
2.1.3 Battery Backup Requirements. The interface element must retain the required
information after a power loss for a period determined by the regulatory agency. If this data is
stored in volatile RAM, a battery backup must be installed within the interface element, see also
Section 3.3 ‘Meters.’
2.1.4 Information Buffering. If unable to communicate the required information to the MCS,
the interface element must provide a means to preserve all mandatory meter and significant event
information until such time as it can be communicated to the MCS, see also Section 3.2,
‘Significant Events’ and Section 3.3 ‘Meters.’ Gaming Device operation may continue until
critical data will be overwritten and lost.
2.1.4.1 Comprehensive Checks Comprehensive checks of interface element critical memory

shall be made during each power resumption (this includes interface element restart).
Chapter Two: System Component Requirements Page 13

September 6, 2011
a) Upon resumption, the integrity of all interface element critical memory shall be checked.
b) It is recommended that interface element critical memory is continuously monitored for
corruption or with comprehensive checks occurring at the start of game play.
c) In addition, it is recommended that the control program (software that operates the
interface element’s functions) allow for the interface element to continually ensure the
integrity of all control program components residing in non-volatile memory.
2.1.4.2 Interface Element Requirements for Offline Ticketing Support It is recommended

that the following set of minimum requirements should be met for an Interface Element to be
capable of providing validation information to an EGD for the issuance of offline vouchers after
a loss of communication to the Ticket/Voucher Validation System has been identified.
a) The Interface Element is recommended to be capable of communicating to the game that

offline voucher issuance is supported and allow the game to negotiate non-support of this
feature.
b) The Interface Element is recommended to meet the Manual Authentication ID
requirements of Section 4.2.2.1.
c) The Interface Element is recommended to limit the number of provided validation
numbers and seed, key, etc. values used for the issuance of offline vouchers to a max of
25 unused pairs.
i. The Interface Element shall not provide to an EGD anymore than 25 validation
numbers and seed, key, etc. values allowed for the issuance of offline vouchers
until all outstanding offline voucher information has been fully communicated to
the Ticket/Voucher Validation System.
d) The Interface Element is recommended to set a maximum expiration length of no more
than 30 gaming days for all provided and still unused validation numbers and seed, key,
etc. values.
i. Expired validation numbers and seed, key, etc. values must be discarded in a way
that prevents the re-use of unique combinations of validation numbers and seed,
key, etc. values for a sufficient period of time on the system.

September 6, 2011
2.1.5 Address Requirements. 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 MCS. This
identification number will be used by the MCS to track all mandatory information of the
associated Gaming Device. Additionally, the MCS should not allow for duplicate Gaming
Device file entry of this identification number.
2.1.6 Configuration Access Requirements. The interface element setup/configuration menu(s)

must be not be available unless using an authorized access method.
2.2 Front End Controller and Data Collector Requirements
2.2.1 General Statement. A MCS may possess a Front End Processor (FEP) that gathers and
relays all data from the connected Data Collectors to the associated database(s). The Data
Collectors, in turn, collect all data from connected Gaming Devices. Communication between
components must be via an approved method and at a minimum conform to the Communication
Protocol requirements stated in Section 3.1 of this document. If the FEP maintains
buffered/logging information, then a means shall exist which prevents the loss of critical
information contained herein.
2.3 Server and Database Requirements
2.3.1 General Statement. A MCS 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.
2.3.2 System Clock. A MCS must maintain an internal clock that reflects the current time
(24hr format - which is understood by the local date/time format) and date that shall be used to
provide for the following:

September 6, 2011
a) Time stamping of Significant Events;

b) Reference clock for reporting; and
c) Time stamping of configuration changes.
2.3.3 Synchronization Feature. If multiple clocks are supported the MCS shall have a facility
whereby it is able to update those clocks in MCS components, whereby conflicting information
could occur.
2.3.4 Database Access. The MCS 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.
2.4 Workstation Requirements
2.4.1 Jackpot/Fill Functionality. A MCS System must have an application or facility that
captures and processes every hand pay message from each 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 pre-determined, or otherwise
properly authorized, token amount in a Gaming Device’s hopper) is normally initiated from a
hopper empty message while a Credit (removal of excess tokens from a 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, there must be adequate access controls to
allow for authorization, alteration, or deletion of any of the values prior to payment or execution.
2.4.2 Tax Reporting Threshold. Every single win event hand pay message confirmed at this
application by personnel of proper authorization, equal to or greater than the tax reporting
threshold (established by the US Internal Revenue Service, currently $1,200), must advise the
user of the need for a W2G (domestic players) or 10425 (foreign players) (required by the US
Internal Revenue Service only) to be processed, either via the MCS or manually. This option

September 6, 2011
must not be capable of being overridden. 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.
NOTE: This is only applicable for U.S. jurisdictions that must comply with taxation
requirements.
2.4.3 Jackpot/Fill Slip Information. The following information is required for all slips
generated with some/all fields to be completed by the MCS:
a) Type of slip;
b) Numeric Slip identifier (which increments per event);
c) Date and Time (Shift if required) ;
d) Gaming Device number;
e) Denomination;
f) Amount of Fill;
g) Amounts of Jackpot, Accumulated Credit, and Additional Pay;
h) W2G indication, if applicable;
i) Additional Payout, if applicable;
j) Total before taxes and taxes withheld, if applicable;
k) Amount to Patron;
l) Total coins played and game outcome of award;
m) Soft meter readings; and
n) Relevant signatures as required by Gaming Board.
NOTE: Items ‘b’ through ‘f,’ ‘m,’ and ‘n’ apply to fill slips and items ‘b’ through ‘e’ and ‘g’
through ‘n’ apply to jackpot slips. The above information may vary dependent upon the
jurisdictional Internal Controls and may or may not be required.
2.4.4 Surveillance/Security Functionality. A MCS shall provide an interrogation program that

enables on-line comprehensive searching of the significant event log for the present and for the

September 6, 2011
previous 14 days 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 element/Gaming Device identification number; and
c) Significant event number/identifier.
2.4.5 Gaming Device Management Functionality. A MCS must have a master “Slot file”
which is a database of every Gaming Device in operation, including at minimum the following
information for each entry. If the MCS retrieves any of these parameters directly from the
Gaming Device, sufficient controls must be in place to ensure accuracy of the information.
a) Unique interface element/location identification number;

b) Gaming Device identification number as assigned by the casino;
c) Denomination of the Gaming Device (please note that the denomination may reflect an
alternative value, in the case of a multi-denomination game);
d) Theoretical hold of the Gaming Device; and
e) Control program(s) within Gaming Device.
2.4.6 Accounting Functionality. A MCS must have an application or facility that allows
controlled access to all accounting (financial) information and shall be able to create all
mandatory reports in the ‘Reporting Requirements,’ Section 3.4, as well as all Internal Control
required reports, if specified.
2.4.7 Exclusions. Generally, any system (component) not specified in this document that
impacts revenue reporting must be submitted to the laboratory for test. For example,
Standalone Player Tracking Systems are not required for submission unless their function
includes embedded feature(s) that affect revenue. (However, they may be tested for operation
and version control if an integrated feature of a MCS submission.)

September 6, 2011
CHAPTER 3
3.0 SYSTEM REQUIREMENTS
3.1 Communication Protocol
3.1.1 General Statement. The system must support a defined communication protocol(s) and
function as indicated by the communication protocol(s). A MCS must provide 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 ninety-nine percent (99%) or
better of messages received;
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; and
c) All communication performed within the system, in it’s entirety, must accurately function
as indicated by the communication protocol that is implemented.
3.2 Significant Events
3.2.1 General Statement. Significant events are generated by a Gaming Device and sent via
the interface element to the MCS 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; and

b) Identity of the Gaming Device that generated the event; and
c) A unique number/code that defines the event; or
d) A brief text that describes the event in the local language.
Chapter Three: System Requirements Page 19

September 6, 2011
3.2.2 Significant Events. The following significant events must be collected from the 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. Gaming Device Jackpot (An award in excess of the single win limit of the
Gaming Device);
ii. Cancelled Credit Hand pay; and
iii. Progressive Jackpot (As per Jackpot above.)
c) Door Openings (any door that accesses a critical area on the Gaming Device). Door
switches (discrete inputs to the interface element) are acceptable if their operation does
not result in redundant or confusing messaging.
d) Coin or Token-In errors (It is acceptable to report Coin-In Jam, Reverse Coin-In and
Coin Too Slow as a generic “Coin-In Error”):
e) Bill (Item) Validator Errors (‘i’ and ‘ii’ should be sent as a unique message, if supported
by the communication protocol):
i. Stacker Full (it is recommended that an explicit “stacker full” error message not
be utilized since this may promote a security issue, rather “Bill Validator
Malfunction” or equivalent); and
ii. Bill (Item) Jam.
f) Gaming Device Low RAM Battery Error;
g) Reel Spin Errors (if applicable with individual reel number identified);
h) Coin or Token-Out Errors (should be sent as unique messages if supported in the
protocol):
i. hopper jams;
ii. hopper runaways or extra coins paid out; and
iii. hopper empties.
i) Printer Errors (if printer supported):
i. Printer Empty/Paper Low; and
ii. Printer Disconnect/Failure.

September 6, 2011
3.2.3 Priority Events. The following significant events must be conveyed to the MCS where a
mechanism must exist for timely notification (it is permissible for the following significant
events to be sent to the system as a generic error code) in cases where the game is unable to
distinguish the specifics of the event:
a) Loss of Communication with Interface element;

b) Loss of Communication with Gaming Device;
c) Memory corruption of the Interface element, if storing critical information; and
d) RAM corruption of the Gaming Device.
3.3 Meters
3.3.1 General Statement. Metering information is generated on a Gaming Device and

collected by the interface element and sent to the MCS via a communication protocol. This
information may be either read directly from the Gaming Device or relayed using a delta
function. Metering information on the MCS shall be labeled so they can be clearly understood in
accordance to their function.
3.3.2 Required Meters. The following metering information must be communicated from the
Gaming Device and stored on the system in units equal to the denomination of the gaming device
or in dollars and cents:
a) Coin In;
i. The System shall maintain Paytable Coin-In and theoretical payback percentage
information provided by the gaming device for each multi-game or multi-
denomination/multi-game.
ii. The System shall maintain Paytable Coin-In and weighted average theoretical
payback percentage information provided by each gaming device which contain
paytables with a difference in theoretical payback percentage which exceeds 4
percent between wager categories.

September 6, 2011
NOTE: This does not apply to Keno or Skill Games.
b) Coin Out:
c) Total Coin-Drop (coins-dropped or total value of all coins, bills and ticket/vouchers
dropped);
d) Attendant Paid Jackpots (hand-pays);
e) Attendant Paid Cancelled Credits (if supported on Gaming Device);
f) Physical Coin In
g) Physical Coin Out
h) Bills In (total monetary value of all bills accepted);
i) Ticket/Vouchers Out
j) Machine Paid External Bonus Payout
k) Attendant Paid External Bonus Payout
l) Attendant Paid Progressive Payout
m) Machine Paid Progressive Payout
n) Ticket/Vouchers In (total monetary value of all ticket/vouchers accepted)
NOTE: Please refer to the GLI-11 standards for the electronic accounting meters that are to be
maintained by the Gaming Device. While these electronic accounting meters should be
communicated directly from the Gaming Device to the MCS, it is acceptable to use secondary
MCS calculations where appropriate.
3.3.3 Clearing Meters. An interface element should not have a mechanism whereby an
unauthorized user can cause the loss of stored accounting meter information, see also Section
3.1.4 ‘Information Buffering.’

September 6, 2011
3.4 Reporting Requirements
3.4.1 General Statement. Significant event and metering information is stored on the MCS in
a database and accounting reports are subsequently generated by querying the stored
information.
3.4.2 Required Reports. Reports will be generated on a schedule determined by the Gaming
Commission, which typically consists of daily, monthly, yearly period, and life to date reports
generated from stored database information. These reports at minimum will consist of the
following:
a) Net Win/Revenue Report for each Gaming Device;

b) Drop Comparison Reports for each medium dropped (examples = coins, bills) with dollar
and percent variances for each medium and aggregate for each type;
c) Metered vs. Actual Jackpot comparison Report with the dollar and percent variances for
each and aggregate;
d) Theoretical Hold vs. Actual Hold comparison with variances;
e) Significant Event Log for each Gaming Device; and
f) Other Reports, as required by individual jurisdictions.
NOTE: It is acceptable to combine reporting data where appropriate (e.g., revenue,

theoretical/actual comparison)
NOTE: For additional revenue reporting requirements when ticket/voucher drop Gaming
Devices are interfaced, please see ‘Ticket/-Validation System Requirements,’ section 4.0 of this
document.

September 6, 2011
3.5 Security Requirements
3.5.1 Access Control. The MCS 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. In addition, the MCS shall not permit the alteration
of any significant log information communicated from the Gaming Device. 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.
3.5.2 Data Alteration. The MCS 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. In the event financial data is changed, an automated 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).
3.6 Additional System Features
3.6.1 Gaming Device Program Verification Requirements. If supported, a MCS may provide
this redundant functionality to check Gaming Device game software. Although the overhead
involved can potentially impede Gaming Device and MCS operation, the following information
must be reviewed for validity prior to implementation:
a) Software signature algorithm(s); and

b) Data communications error check algorithm(s).

September 6, 2011
NOTE: The above standard is subject to review based on jurisdictional regulations and may or
may not be required of the MCS.
3.6.2 Verification Algorithm Timing. Verification may be user initiated or triggered by

specific significant event(s) on the Gaming Device. To ensure complete coverage verification
should be performed after each of the following events:
a) Gaming Device Power Up; and

b) New Gaming Device installed.
NOTE: The above standard is subject to review based on jurisdictional regulations and may or
may not be required of the MCS.
3.6.3 FLASH Download Requirements. If supported, a MCS may utilize FLASH technology
to update interface element software if all of the following requirements are met:
a) FLASH Download functionality must be, at a minimum, password protected, and should
be at a supervisor level. The MCS 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) An 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 GLI
for approval. At this time, GLI will perform a FLASH download to the system existing
at GLI and verify operation. GLI will then assign signatures to any relevant executable
code and flash file(s) that can be verified by a regulator in the field. Additionally, all flash
files must be available to a regulator to verify the signature.

September 6, 2011
NOTE: The above refers to loading of new system executable code only. Other program
parameters may be updated as long as the process is securely controlled and subject to audit.
3.6.4 Remote Access Requirements. If supported, a MCS may utilize password controlled
remote access to a MCS 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; and
e) If remote access is to be continuous basis then a network filter (firewall) should be
installed to protect access.
NOTE: GLI acknowledges that the MCS manufacturer may, as needed, remotely access the MCS
and its associated components for the purpose of product and user support. This feature
however, must be optional, by a secure means, to accommodate those jurisdictions that do not
permit remote access.
3.6.5 Verification of System Software. System software components/modules shall be

verifiable by a secure means (as defined in 3.5.1 Access Controls) at the system level denoting
Program ID and Version. The system shall have the ability to allow for an independent integrity
check of the components/modules from an outside source and is required for all control programs
that may affect the integrity of the system. This must be accomplished by being authenticated by
a third-party device, which may be embedded within the system software (see NOTE below) or
having an interface port for a third-party device to authenticate the media. This integrity check
will provide a means for field verification of the system components/modules to identify and
validate the programs/files. The test laboratory, prior to system approval, shall approve the
integrity check method.

September 6, 2011
NOTE: If the authentication program is contained within the system software, the manufacturer
must receive written approval from the test laboratory prior to submission.
3.7 Backups and Recovery
3.7.1 General Statement. The MCS 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 MCS with open support for
backups and restoration.
3.7.2 Recovery Requirements. In the event of a catastrophic failure when the MCS 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:
a) Significant Events;
b) Accounting information;
c) Auditing information;
d) Specific site information such as slot file, employee file, progressive set-up, etc; and
e) If voucher issuance is supported, all information utilized in the voucher redemption
process including information specific to the redemption of offline vouchers if applicable.

September 6, 2011
CHAPTER 4
4.0 TICKET/VOUCHER VALIDATION SYSTEM
REQUIREMENTS
4.1 Introduction
4.1.1 General Statement. A ticket/voucher validation system may be entirely integrated into a
MCS or exist as an entirely separate entity. Ticket/Voucher validation systems are generally
classified into two types: bi-directional ticket/voucher systems that allow Gaming Devices to
print and redeem ticket/vouchers (TITO) and ticket/voucher out (TOO) only systems that allow
Gaming Devices to print ticket/vouchers but do not allow ticket/voucher redemption. This
chapter primarily addresses bi-directional ticket/voucher systems. Where ticket/voucher out only
systems are utilized, some of the following may not apply.
4.1.2 Payment by Ticket/Voucher Printer. Payment by ticket/voucher printer as a method of

credit redemption on a Gaming Device is only permissible when the Gaming Device is linked to
an approved validation system or MCS that allows validation of the printed ticket/voucher.
Validation information shall come from the validation system or MCS using a secure
communication protocol.
NOTE: For support of offline voucher issuance, the Gaming Device must be linked to an
approved validation system or MCS that allows validation of the printed ticket/voucher, but does
not have to be in constant communication for the issuance of voucher to be permissible.
4.2 Ticket/Voucher Issuance
4.2.1 Ticket/Voucher Information used by the Gaming Device while communicating to a

validation system. The ticket/voucher validation system must be able to communicate the
following ticket/voucher data to the Gaming Device to print on the ticket/voucher.
Chapter Four: Ticket/Voucher Validation System Requirements Page 28
September 6, 2011
a) Casino Name/Site Identifier;

b) Indication of an expiration period from date of issuance, or date and time the
ticket/voucher will expire (24 hr format which is understood by the local date/time
format) if applicable;
c) System date and time (24 hr format which is understood by the local date/time format);
and
d) Ticket/Voucher validation number for the Gaming Device to generate the validation
number.
4.2.2 Algorithm for generating ticket/voucher validation numbers or seeds.
a) System Validation – the algorithm or method used by the validation system or MCS to
generate the ticket/voucher validation number must guarantee an insignificant percentage
of repetitive validation numbers.
b) Gaming Device generated validation number (system seed) – The validation system
must send a unique seed to the Gaming Device upon enrolling the Gaming Device as
ticket/voucher printing capable. The system may subsequently send a new seed to the
Gaming Device after a ticket/voucher is printed. The algorithm or methods used to
determine the seed must guarantee an insignificant percentage of repetitive validation
numbers.
4.2.2.1 Algorithm for generating offline ticket/voucher authentication identifiers If support,

the offline authentication identifier must be of a unique value that is derived by a HASH or other
secure encryption method of at least 128 bits, that will: uniquely identify the wager instrument,
verify that the redeeming system was also the issuing system, and validate the amount of the
voucher. The following minimum set of inputs must be used to create the authentication
identifier:
a) EGM identifier;
b) Validation number;

September 6, 2011
c) Voucher amount; and

d) Secure seed, key, etc. provided by the validation system or MCS to the Gaming Device;
i. Secure seeds, keys, etc. as assigned must be sufficiently random. Measures to
avoid predictability will be reviewed by the test laboratory on a case by case
basis.
ii. The minimum length for any secure seeds, keys, etc. employed by the validation
system or MCS shall be chosen from a pool of the variable type specified by the
communication protocol utilized. The pool must be comprised of at least 10 to the
power of 14 randomly distributed values.
4.2.3 System Ticket/Voucher Records.
a) The validation system must retrieve the ticket/voucher information correctly based on the
secure communication protocol implemented, and store the ticket/voucher information
into a database.
b) The ticket/voucher record on the host system must contain at a minimum the following
ticket/voucher information:
i. Validation number;
ii. Date and time the Gaming Device printed the ticket/voucher (24 hr format which
is understood by the local date/time format);
iii. Type of transaction or other method of differentiating ticket/voucher types
(assuming multiple ticket/voucher types are available);
iv. Numeric value of ticket/voucher in dollars and cents;
v. Status of ticket/voucher (i.e. valid, unredeemed, pending, void, invalid,
redemption in progress, redeemed, etc.);
vi. Date and time the ticket/voucher will expire (24 hr format which is understood by
the local date/time format or expiration period from date of issuance) if
applicable;
vii. Machine number (or Cashier/Change booth location number, if ticket/voucher
creation outside the Gaming Device is supported) that identifies where the
ticket/voucher was issued from.

September 6, 2011
4.2.4 System Requirements for Offline Ticketing Support. This section is recommended if
an approved offline voucher routine is supported.
a) Support the identification and redemption of offline vouchers through a system provided
application.
b) Log all access and operations of users of the aforementioned application for 14 days
through archived data or restoration from backup where maintaining such data on a live
database is deemed inappropriate.
c) The validation system or MCS must set a maximum expiration length of no more than 30
gaming days for all provided and still unused validation numbers and seed, key, etc.
values.
d) Expired validation numbers and seed, key, etc. values must be discarded in a way that
prevents the re-use of unique combinations of validation numbers and seed, key, etc.
values for a sufficient period of time on the system.
4.2.5 **Ticket/Voucher Printing during loss of communication with validation system.

For validation systems that communicate to a Gaming Device through an Interface Board
(also called SMIB, System Machine Interface Board), if any links between the Interface
Board and the MCS database go down, the Interface Board must:
a) Not respond to the validation request from the Gaming Device and stop ticket/voucher
printing, or
b) Prevent the Gaming Device from further ticket/voucher issuance, or
c) Not read or store any further ticket/voucher information generated by the Gaming
Device.
NOTE: A maximum of 2 (two) ticket/vouchers directly after loss of communication is acceptable,

in cases where the interface element has already been ‘seeded’ by the system, provided the
ticket/voucher issuance information is sent immediately, when communication is reestablished.

September 6, 2011
**NOTE: This section does not apply to systems employing an approved offline voucher routine.
4.3 Ticket/Voucher Redemption
4.3.1 Online Ticket/Voucher Redemption. Ticket/Vouchers can be redeemed at Gaming

Device, Cashier/Change booths or other approved Validation Terminals (Kiosks) provided they
are enrolled for ticket/voucher validation with a validation system. (See GLI-11 2.31 for Gaming
Device ticket/voucher validation requirements).
a) The validation system must process ticket/voucher redemption correctly according to the
secure communication protocol implemented;
b) The validation system must update the ticket/voucher status on the database during each
phase of the redemption process accordingly. In other words, whenever the
ticket/voucher status changes, the system must update the database; Upon each status
change, the database must indicate the following information:
i. Date and time of status change;
ii. Ticket/Voucher status;
iii. Ticket/Voucher value;
iv. Machine number or source identification from where the ticket/voucher
information came from.
4.3.2 Offline Ticket/Voucher Redemption. If supported, Offline Ticket/Vouchers can be

redeemed at Cashier/Change booth provided they are enrolled for ticket/voucher validation with
a validation system.
a) The validation system at a minimum must support the identification and redemption of
offline vouchers through a system provided application;
b) The validation system must process offline ticket/voucher redemption correctly according
to the secure communication protocol implemented;
c) The validation system must update the ticket/voucher status on the database during each
phase of the redemption process accordingly. In other words, whenever the

September 6, 2011
ticket/voucher status changes, the system must update the database. Upon each status
change, the database must indicate the following information:
i. Date and time of status change;
ii. Ticket/Voucher status;
iii. Ticket/Voucher value;
iv. Machine number or source identification from where the ticket/voucher
information came from.
4.3.3 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; or

b) Input the ticket/voucher validation number manually; and
c) May print a validation receipt, after the ticket/voucher is electronically validated, if
applicable.
4.3.4 Validation Receipt Information. If applicable, the validation receipt, at a minimum,

shall contain the following printed information:
a) Machine number;
b) Validation number;
c) Date and Time paid;
d) Amount; and
e) Cashier/Change Booth identifier.
4.3.5 Invalid Ticket/Voucher Notification. The validation system or MCS must have the
ability to identify these occurrences and notify the cashier that one of the following conditions
exists:
a) Ticket/Voucher cannot be found on file (stale date, forgery, etc.);

b) Ticket/Voucher has already been paid; or

September 6, 2011
c) Amount of ticket/voucher differs from amount on file (requirement can be met by display
of ticket/voucher amount for confirmation by cashier during the redemption process).
4.3.6 **Ticket/Voucher Redemption During Communication Loss. If the on-line data system
temporarily goes down and validation information cannot be sent to the validation system or
MCS, an alternate method of payment must be provided either by the validation system
possessing unique features, (e.g., validity checking of ticket/voucher information in conjunction
with a local database storage), to identify duplicate ticket/vouchers and prevent fraud by
reprinting and redeeming a ticket/voucher that was previously issued by the Gaming Device; or
use of an approved alternative method as designated by the regulatory jurisdiction that will
accomplish the same.
NOTE: A maximum of 2 (two) ticket/vouchers directly after loss of communication is acceptable,

in cases where the interface element has already been ‘seeded’ by the system, provided the
ticket/voucher issuance information is sent immediately, when communication is reestablished.
**NOTE: This section does not apply to systems employing an approved offline voucher routine.
4.3.7 Redemption Terminals (Kiosks). Refer to GLI-20 Redemption Terminals for technical
standards for these devices.
4.4 Reports
4.4.1 Reporting Requirements. The following reports shall be generated at a minimum and
reconciled with all validated/redeemed ticket/vouchers:
a) Ticket/Voucher Issuance Report;

b) Ticket/Voucher Redemption Report;
c) Ticket/Voucher Liability Report;
d) Ticket/Voucher Drop Variance Report

September 6, 2011
e) Transaction Detail Report must be available from the validation system that shows all
ticket/vouchers generated by a Gaming Device and all ticket/vouchers redeemed by the
validation terminal or other Gaming Device; and
f) Cashier Report, which is to detail individual ticket/vouchers, the sum of the
ticket/vouchers paid by Cashier/Change Booth or Redemption Terminal.
NOTE: The requirements for ‘b’ & ‘d’ are waived where two-part ticket/vouchers exist for the
Gaming Device where the first part is dispensed as an original ticket/voucher to the patron and
the second part remains attached to the printer mechanism as a copy (on a continuous roll) in
the Gaming Device.
4.5 Security
4.5.1 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 prevent
unauthorized access. Further, the normal operation of any device that holds ticket/voucher
information shall not have any options or method that may compromise ticket/voucher
information. Any device that holds ticket/voucher information in its memory shall not allow
removing of the information unless it has first transferred that information to the database or
other secured component(s) of the validation system.

September 6, 2011
CHAPTER 5
5.0 SYSTEM ENVIRONMENTAL AND SAFETY
REQUIREMENTS
5.1 Introduction
5.1.1 General Statement. This chapter shall govern the environmental and safety requirements
for all system components submitted for review.
5.2 Hardware and Player Safety
5.2.1 General Statement. Electrical and mechanical parts and design principals of the
electronic associated hardware may not subject a player to any physical hazards. The test
laboratory shall NOT make any finding with regard to Safety and EMC testing as that is the
responsibility of the manufacturer of the goods or those that purchase the goods. Such Safety
and EMC testing may be required under separate statute, regulation, law or Act and should be
researched, accordingly, by those parties who manufacture or purchase said hardware. The test
laboratory shall not test for, be liable for, nor make a finding relating to these matters.
5.3 Environmental Effects on System Integrity
5.3.1 Integrity Standard. The Laboratory will perform certain tests to determine whether or
not outside influences affect game fairness to the player or create cheating opportunities. An on-
line system shall be able to withstand the following tests, resuming game play without operator
intervention:
a) Electro-magnetic Interference. Systems shall not create electronic noise that affects the
integrity or fairness of the neighboring associated equipment;
Chapter Five: System Environmental and Safety Requirements Page 36

September 6, 2011
b) Electro-static Interference. Protection against static discharges requires that the system’s
hardware be earthed in such a way that static discharge energy shall not damage or inhibit
the normal operation of the electronics or other components within the System. Systems
may exhibit temporary disruption when subjected to a significant electro-static discharge
greater than human body discharge, but they shall exhibit a capacity to recover and
complete any interrupted function without loss or corruption of any control or data
information associated with the System. The tests will be conducted with a severity level
of up to 27KV air discharge.
Chapter Five: System Environmental and Safety Requirements Page 37


GLI 13 v2 1 Standard

Uploaded by

Copyright:

Available Formats

GLI 13 v2 1 Standard

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GLI 13 v2 1 Standard

Uploaded by

Copyright:

Available Formats

STANDARD SERIES

Release Date: September 06, 2011

Copyright  2011 Gaming Laboratories International, LLC All Rights Reserved.

Copyright  2011 Gaming Laboratories International, LLC All Rights Reserved.

This Standard has been produced by Gaming Laboratories International, LLC

A supplier should submit equipment with a request that it be certified in

Copyright  2011 Gaming Laboratories International, LLC All Rights Reserved.

Copyright  2011 Gaming Laboratories International, LLC All Rights Reserved.

Table of Contents Page 5

This Page Intentionally Left Blank

Table of Contents Page 6

1.2 Graphical Overview

Servers w/ Databases & Workstations

1.3 Acknowledgment of Other Standards Reviewed

a) The ACT Office of Financial Management;

m) Colorado Division on Gaming – Limited Gaming Regulations;

1.4 Purpose of Standard

1.4.1 General Statement. The purpose of this technical standard is as follows:

a) To eliminate subjective criteria in analyzing and certifying gaming Monitoring and

1.5 Other Documents That May Apply

a) Gaming devices in Casinos (GLI-11);

2.1 Interface Element Requirements

2.1.4.1 Comprehensive Checks Comprehensive checks of interface element critical memory

Chapter Two: System Component Requirements Page 13

2.1.4.2 Interface Element Requirements for Offline Ticketing Support It is recommended

a) The Interface Element is recommended to be capable of communicating to the game that

Chapter Two: System Component Requirements Page 14

2.1.6 Configuration Access Requirements. The interface element setup/configuration menu(s)

2.2 Front End Controller and Data Collector Requirements

2.3 Server and Database Requirements

Chapter Two: System Component Requirements Page 15

a) Time stamping of Significant Events;

2.4 Workstation Requirements

Chapter Two: System Component Requirements Page 16

2.4.4 Surveillance/Security Functionality. A MCS shall provide an interrogation program that

Chapter Two: System Component Requirements Page 17

a) Unique interface element/location identification number;

Chapter Two: System Component Requirements Page 18

3.1 Communication Protocol

3.2 Significant Events

a) Date and time which the event occurred; and

Chapter Three: System Requirements Page 19

a) Power Resets or power failure;

Chapter Three: System Requirements Page 20

a) Loss of Communication with Interface element;

3.3.1 General Statement. Metering information is generated on a Gaming Device and

Chapter Three: System Requirements Page 21

NOTE: This does not apply to Keno or Skill Games.

Chapter Three: System Requirements Page 22

3.4 Reporting Requirements

a) Net Win/Revenue Report for each Gaming Device;

NOTE: It is acceptable to combine reporting data where appropriate (e.g., revenue,

Chapter Three: System Requirements Page 23

3.5 Security Requirements

a) Data element altered;

3.6 Additional System Features

a) Software signature algorithm(s); and

Chapter Three: System Requirements Page 24

3.6.2 Verification Algorithm Timing. Verification may be user initiated or triggered by

a) Gaming Device Power Up; and