This section contains general Backend System requirements which apply to electronic bingo card and Ticket Games.
17.1.1 User input fields must be validated to prevent any security breaches.
17.1.2 Backend System must have ability to enable/disable Player Terminal.
17.1.3 cGaming System must not have hardcoded passwords.
17.1.4 Management, administration or configuration of the Backend System from Player Terminal must not be allowed.
17.1.5 Backend Systems must record and store complete Game events and accounting data.
17.1.6 Backend Systems must provide reports for complete inventory and status audit of activated Deals, sold and unsold Tickets, Bingo Cards etc. which are used in electronic Games.
17.1.7 The Backend System must at a minimum contain the following information in reports, capable of being generated on-demand, for specific time periods, and for specific activities:
18.1 General Requirements
18.1.1 The Backend System must require player interaction to call a bingo.
18.1.2 The Backend System must detect a failure or loss of communication with any participating Player Terminal during session Play and notify the Operator.
18.2 Bingo Cards
18.2.1 If there is a data corruption or modification in the Bingo Card database, the Backend Sys- tem must have a method to detect and notify the Operator of any discrepancy and mark the cards unplayable.
18.2.2 Any changes to, or removal of card Perms from the database must not impact the log of card faces from previously played session bingo Games.
18.2.3 The Backend System must have a secure and reliable method of validating called bingos for all bingo paper products. This validation requires manual Operator acceptance for payout of paper products.
18.2.4 The Backend System must track paper products inventory and sales for reconciliation of sales values and to match inventory values, when paper products are used in electronic Game. The system must reasonably ensure that sufficient information is provided to the Op- erator to identify missing paper products prior to a session starting.
18.2.5 If the Bingo Cards used are pulled from a Perm, the data storage mechanism of the Perm must have integrity check. If the Bingo Card is generated at the time of Play by using RNG, the RNG must satisfy requirements set out in 21.1.1 and 21.1.2 of this document.
18.3 Session Bingo Game
18.3.1 Session bingo Game results may be generated by either electronic or physical RNG, which must satisfy section 21.1 or 21.2 respectively.
18.3.2 The Backend System must provide functionality to recall a drawn ball. All instances of ball re-calls must be logged. Ball recalls must be communicated to all paper and electronic bingo players.
18.3.3 All Game results must be logged.
18.4 Single-Player Bingo Game
18.4.1 All Game results generated must adhere to section 21.1 of this document
18.4.2 If the Game uses traditional 5x5 Bingo Cards with a results set of 75 balls, the odds of achieving a pattern must be the same as session bingo unless otherwise communicated to the player.
18.4.3 The Game may allow player to re-select their Bingo Card face prior to retrieving Game results.
18.4.4 Paytables must be protected from modifications and must also have integrity check.
18.5 Flashboard Display
18.5.1 Flashboard display is required if the system supports paper Play.
18.5.2 Estimated Prizes advertised on the flashboard display must be disclosed immediately when modified.
18.5.3 Results must be displayed on both Player Terminals and flashboard displays in real time.
18.5.4 Flashboard display must contain all information required for paper players to participate in the Game. This includes:
18.5.5 The Backend System must automatically detect any failure in the flashboard display, e.g. communication failure or any other that can be detected, and halt session Play until the fail- ure is resolved.
18.6 Prizing
18.6.1 Prize adjustments may only be performed through restricted means.
18.6.2 Any Prize adjustments made, or other changes to Prize structure must be logged sufficiently for audit purposes, including: user making the change, date/time and details on the change.
18.6.3 Session bingo Prizes must pay out according to the advertised Game rules.
18.6.4 Progressive Prize contributions and Ordinal balls must increment as designed and be accu- rately communicated.
18.6.5 The changes of Progressive pools and Ordinal ball values must be tracked by the Backend System to show the details of the change including: time of change, associated session, val- ue of contribution or increment change and when the value is reset to the default value.
18.6.6 The Backend System must provide functionality to either enable a “must-go” situation for Progressive Prizes to force the Prize to be paid out, or to transfer contributions to a new Prize pool. If used, this function must be logged in reports.
18.7 Reporting
18.7.1 Where the Backend System is used to track asset inventory, the following paper inventory information must be available in the reporting interface:
18.7.2 The following information must be available for each session played by the Backend System, including both electronic and paper sales for a minimum of 1 year:
19.1 General Requirements
19.1.1 All Game Results Sets must be reviewed and approved by the Registrar for integrity of Pay- back and Play results. In addition, the integrity of sets must be verifiable on demand before offered for Play.
19.1.2 Tickets may be drawn from electronic Game Results Sets secured on Backend System with or without replacement.
19.1.3 Functionality must exist to place entire Game Results Sets into an unplayable state (deacti- vation of Deals) through restricted technical procedure. The use of this functionality must be logged and fully auditable.
19.1.4 Removal of a Game Results Set from Play must not impact audit trail or reports for any past Game Plays.
19.2 Tickets Drawn with Replacement
19.2.1 RNG used for random draw of Tickets must satisfy section 21.1 of this document.
19.2.2 Tickets drawn must be statistically independent, that is sufficiently random, so that there are no negative impacts on any Game aspects, e.g. Game Payback.
19.2.3 There must be no patterns or correlation of drawn Tickets.
19.3 Tickets Drawn without Replacement
19.3.1 RNG utilized to randomly sequence Tickets must satisfy requirements 21.1.1 and 21.1.2 of this document.
19.3.2 The position of Tickets within a Deal/Deck must be statistically independent, that is suffi- ciently random, so that winning Tickets cannot be determined along any given sequence of Tickets.
19.3.3 There must be no patterns or correlation of Tickets within a single Deal or Deck and across Deals and Decks.
19.3.4 If a shuffling algorithm is used to sequence Tickets, it will be evaluated on case-by-case basis for approval by the Registrar.
19.3.5 Any shuffled sequence of Tickets for Deals with the same contents (Deal duplication) must satisfy the requirements 19.3.2 and 19.3.3.
19.3.6 Where physical Tickets are used to communicate Game results to the player, the Backend System must contain a function to remove from Play and void unplayable Tickets that cannot be sold properly, e.g. damaged tickets.
19.3.7 All voided Tickets must be logged and fully auditable.
19.3.8 Play status of all Tickets must be tracked in the Backend System for audit purposes.
19.3.9 The Backend System must have a check to prevent sale of a ticket that has already been sold.
19.3.10 cGaming System must restrict and minimize information available which could be used to predict the winnings, such as current payout of a set which is still in Play.
19.3.11 When enrolling new Game Results Set (Deal), the following must be ensured:
19.3.12 Game Results Sets (Deals) may be created on systems outside the Backend System. Once created, Deal results must be protected to preserve the integrity of the Game.
19.4 Reporting
19.4.1 Information regarding all Ticket Plays must be available for audit. These reports must contain the following information at a minimum:
20.1 Wagering Account at POS
20.1.1 Wagering Accounts must use a method of authentication to access or transfer player funds or associated information such as player activity. This authentication requires a Wagering Ac- count identifier, as well as a player supplied authentication method, such as a PIN.
20.1.2 Wagering Accounts must have a unique and non-predictable identifier. Either the player must choose this identifier, or the system will assign it pseudo-randomly. This identifier may be associated with a player, or a specific player session.
20.1.3 At the time a Wagering Account is created, a player receipt must be issued with the following information, at a minimum:
20.1.4 There must be a method of identifying a player in the event that their account PIN is lost.
20.1.5 All Wagering Account activities including transactions, changes to the account and success- ful and unsuccessful logins must be tracked at the Backend System including Wagering Account number, location of activity and activity.
20.2 Vouchers and Coupons
20.2.1 Voucher and Coupon status during transactions and on-demand must be displayed on Player Terminals and Backend System. Once redeemed, they must not be redeemable again.
20.2.2 The Backend System must be equipped to capture and store all Cashless Wagering meters. The following meter information must be captured, as applicable:
20.2.3 The Backend System must have a mechanism in place to record all required meters, as specified above in Section 20.2.2 of this document, at the time a drop box is removed or on demand.
20.2.4 Vouchers and Coupons must contain the following information at a minimum:
20.2.5 In the event of a communication disruption, the Player Terminal may issue a single offline Voucher to clear player’s balance, which must be communicated to the Backend System im- mediately on reconnection, or lockup in hand-pay.
20.2.6 Validation numbers of unredeemed Vouchers must be appropriately masked when viewable through any display to prevent generation of counterfeit vouchers.
20.3 Reporting
20.3.1 Sufficient accounting information must be captured by the Backend System to allow for full reconciliation and audit of all Cashless Wagering transactions.
20.3.2 Reports must be available to provide information on all activities on electronic Wagering Ac- counts including purchases, Wagers and cash-outs:
20.3.3 Reports must be available to track information on all Voucher transactions, including:
21.1 Software Random Number Generator
The following requirements are applicable to software Random Number Generators and their implementation.
21.1.1 Random numbers must be:
21.1.2 The range of random numbers must match the range used in the particular Game, or Deal size for Tickets, as applicable. Specifically, the random numbers must produce statistics that lie within the 99% confidence interval for various Game specific, empirical statistical tests, including but not limited to frequency test, runs test and serial correlation test. The applicable tests are chosen in a way to match the grouping of random numbers to form Game out- comes, or Deal size, as applicable.
21.1.3 The RNG must be capable of generating all possible Game outcomes (winning and losing combinations) in each Play.
Note: due to the nature of draw, this requirement does not apply to Games with Tickets drawn without replacement.
21.1.4 The RNG output must not exhibit detectable patterns or correlation with any previous RNG output.
21.1.5 The RNG output and its corresponding Game outcome must not be dependent upon the amount wagered, style or method of Play.
21.1.6 The RNG and/or cGaming System must implement a mechanism to prevent the determina- tion of RNG seeds.
21.1.7 RNG seed must be reinitialized, if corrupted.
21.1.8 Where the selection process of Game elements is interrupted, the original selection must be preserved until full system recovery.
21.1.9 Where there is a failure of the mechanism used to select Game elements, the Player Termi- nals that rely upon that mechanism must be made unavailable for Play until the failure has been rectified.
21.1.10 The cGaming System must use secure communication protocols to protect RNG and ran- dom selection process.
21.2 Physical Random Number Generator
In addition to the requirements 21.1.1, 21.1.2 and 21.1.10, the following are specific requirements that apply to physical RNG, which use physical properties of number designators (e.g. balls, wheels, dice) to randomly generate Game results.
21.2.1 RNG designators must satisfy the following: