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:

1. Cashier Transactions - Information on all cash transactions handled by the system, including: cash-in, cash-out, transaction location, time and user name of the cashier performing the transaction and invalid transactions;
2. Game and player (Wagering Account) transactions – Any sales and wagering information must be tracked for full reconciliation including: terminal location of the sale, product details, cashless and currency flow, cost and Game result;
3. Security Events – any information on access and attempted authentication including: component accessed, username, success or failure of authentication, time, any changes made; and
4. Error Logs – All critical errors, such as terminal or system application crashes, failed software authentication and communication errors.

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:

1. Called balls;
2. Graphical representation of winning pattern;
3. Prize of current Game;
4. Game and session name;
5. Ordinal number, if used;
6. Pre-called balls for outstanding Games for which sales are open; and
7. Any other non-standard information required for Play.

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:

1. Inventory delivered to the hall;
2. Inventory assigned to cashiers or runners;
3. Inventory returned by cashiers or runners;
4. Inventory reported as damaged;
5. Sold inventory;
6. Inventory Price;
7. Date/time of the above actions; and
8. User responsible for initiating the above actions.

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:

1. Card face information for all participating players;
2. Ball call order including ball recalls;
3. Winning card(s);
4. User name of the caller;
5. Prizes won;
6. Sales; and
7. Progressive Prize contributions.

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:

1. Results are transmitted to the database in a fashion which preserves confidentiality of results and verifies the results came from a trusted source;
2. Addition or removal of Game Results Set from Play must be logged in a way that cap- tures information regarding user, date/time of action, and Deal parameters;
3. The Backend System must verify the integrity of a pre-determined Game Results Set through use of a Hash function. The pre-determined Game Results Set must not be en- abled for Play until this Hash is calculated and verified;
4. Removal or replacement of an existing pre-determined Game Results Set must not inter- fere with Game Play, e.g. it is not in Play, or made unavailable for Play.

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:

1. Play results;
2. Prizes paid;
3. Amount wagered;
4. Unique identifier for the Player Terminal;
5. Unique identifier for the finite set; and
6. Date/time.

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:

1. Location of issuance;
2. Date and time;
3. Receipt number;
4. Player ID;
5. The amount in dollars and cents;
6. Time period the funds can be used at Player Terminal; and
7. The expiry date after which the funds cannot be redeemed.

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:

1. Voucher in;
2. Voucher out;
3. Cashable electronic promotion in;
4. Cashable electronic promotion out;
5. Non-cashable electronic promotion in;
6. Non-cashable electronic promotion out;
7. Coupon promotion in; and
8. Coupon promotion out.

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:

1. Name and address of cGaming Site;
2. Value;
3. Machine readable, unique identifier;
4. Plaintext identification number;
5. Location where it was generated;
6. Message indicating how long it is redeemable for; and
7. Date and time of issuance.

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:

1. Action performed;
2. Player balance at the time of action;
3. Date/time of action;
4. Location of action;
5. Wagering Account identifier.

20.3.3  Reports must be available to track information on all Voucher transactions, including:

1. Voucher issuance by date and identification of Player Terminal where issued;
2. Voucher redemption by date, time, and means of redemption (such as, Player Terminal and cashier station);
3. Voucher liabilities by date and time issued and by sequence number;
4. Voucher expired by date and time issued, sequence number, and identification of Player Terminal where it was issued;
5. Voucher voided by date and time issued, sequence number, and identification of Player Terminal where it was issued;
6. Voucher count in each category;
7. Player Terminal meter cashable electronic promotion in vs. Backend System cashable electronic promotion in;
8. Player Terminal meter cashable electronic promotion out vs. Backend System cashable electronic promotion out;
9. Player Terminal meter non-cashable electronic promotion in vs. Backend System non-cashable electronic promotion in;
10. Player Terminal meter non-cashable electronic promotion out vs. Backend System non-cashable electronic promotion out;
11. All cashiering activities including log on, redemptions, adjustments to Wagering Accounts deposits/withdrawals, and log off, by cashier;
12. All system generated adjustments;
13. All exceptions to include:
    1. Date and time of exception;
    2. Player Terminal number or user identification number and location where the exception occurred; and
    3. A description of the exception or a unique code that identifies the exception.

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:

1. Statistically independent;
2. All values within the desired range must have an equal chance of being generated;
3. Able to pass various recognized statistical tests; and
4. Unpredictable.

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:

1. All designators must be of equal size and mass homogeneously distributed to ensure that they are not weighted to a specific outcome;
2. Game results must be clearly displayed on the designator and be distinguishable from all other results (e.g. 6 and 9 must be clearly marked);
3. Designators must contain a method of identifying the set to which each individual designator belongs; and
4. The designators used must be designed to resist physical degradation. Where the desig- nators have a defined life cycle, they must be replaced within their life cycle.