Part B: Raffle Game

Last Updated

Raffle Game Design

The objective of the requirements in this section is to ensure technical integrity of Raffles is embedded in Game design.

2.1 General Requirements


2.1.1 Game designs and features must be clear and must not mislead the player.

2.1.2 The electronic Raffle Game must be designed and played in a manner that is as consistent as technically possible with the associated non-electronic, paper Raffles.
Guidance: This standard is intended to avoid discrepancies in Game play causing confusion for players, while still maintaining Game fairness. For example, “must go” Draw of Catch the Ace must produce a winner in one or more re-draws until Ace of Spades is revealed.

2.2 Rules of Play and Information Display

2.2.1 The ERS must provide a mechanism for Charities to communicate the rules of play to players, such as: ticket messaging, digital signage and URL links.
Note: Raffle rules of play are considered through the licencing of Raffle events.

2.2.2 Players must be provided with clear, meaningful and accurate information to enable them to make informed choices (e.g. price discounts for purchasing multiple Raffle Numbers in one Ticket, or the 50-50 Raffle Prize to be 50% of sales and as estimated Raffle Prize).

2.2.3 Non-gaming-related information displayed on Raffle displays, such as advertisements or entertainment, must be clearly distinguishable from Game-related information and must not mislead Players nor negatively impact Raffles.

2.3 Raffle Ticket

2.3.1 Raffle Tickets must display the following information, at a minimum:

  1. POS identifier
  2. Ticket issuance date and time
  3. Raffle Number(s)
  4. Ticket price
  5. Jurisdiction where ticket purchase occurred, where event is licensed to occur in more than one jurisdiction;
  6. Draw identifier, and
  7. All applicable Draw date(s), e.g. early bird, main and consolation Draw dates

2.3.2 ERS must not generate duplicate Raffle Numbers or Raffle Tickets for the same Draw. If reprint is supported, such a Ticket must be clearly marked as “reprint”.

2.3.3 Each Raffle Ticket must be uniquely identifiable, e.g. if Ticket Validation Number is implemented, it must be unique (no duplicates).

2.4 Progressive Raffles

2.4.1 The design of a Progressive Raffle and the method used to award an accumulating Prize must not disadvantage any player participating in the Game..

2.4.2 ERS must provide accurate and clear Progressive Prize amount that includes current contributions and any amounts transferred from previous Draw(s).

2.4.3 The following information to support Progressive Raffle audits must be captured in ERS, at a minimum:

  1. The configuration of Progressive Raffle
  2. The changes in the amount of Progressive Prize
  3. Draw identifier, time and date of Progressive hit
  4. Progressive Prize awarded

2.5 Configurable Raffle Features and Critical Game Options

2.5.1 ERS solution must have a mechanism to lockup configurations of Raffle features and Critical Game Options to prevent changes from being made that could impact the integrity of a live Raffle event.

2.5.2 ERS solution must have a mechanism to disable or remove configurable Raffle features and Critical Game Options such that Raffle events can be prevented from being deployed with features and options that are not permitted.

2.5.3 Configuration lockups and disabling or removal of Raffle features and Critical Game Options from 2.5.1 and 2.5.2 respectively may only be possible through Restricted Technical Procedures or operational controls.
Guidance: The expectations are the ERS solution as provided by Gaming-Related Suppliers will technically mitigate all Raffle integrity risks pertaining to Configurable Raffle Features and Critical Game Options. Any exceptions where this mitigation is handled through operational controls will be assessed on a case-by-case basis.

2.5.4 Any and all settings or changes to Raffle configurations in reference to Configurable Raffle Features and Critical Game Options from 2.5.1 and 2.5.2 must be logged sufficiently for audit purposes, including: user, date/time and details of the change.

 

3 Raffle Game Processes

The objective of the requirements in this section is to ensure technical integrity and security of raffle processes within the ERS.

3.1 General Requirements for Sale of Raffle Tickets 

3.1.1 The ERS must issue valid Ticket(s) once the purchase has been accepted and successfully completed at the ERS.

3.1.2 The ERS must support cancellation of Ticket sale and voiding of sold Tickets prior to the close of the Raffle sales.

3.1.3 Cancelled and Voided Tickets must be logged, fully auditable, and any completed payments for these Tickets must be refunded to the player.

3.1.4 Voiding Raffle Tickets may only be performed by authorized personnel.

3.1.5 Raffle Numbers and corresponding Ticket Validation Numbers from Voided Tickets must not be possible to reissue or sell again for the same Raffle Draw. 

3.1.6 When e-payment is integrated into the ERS, the payment processor and ERS must be compliant with current Payment Card Industry’s Data Security Standards (PCI DSS).

3.1.7 Where Ticket sales occur in a public place, the purchaser’s personally identifiable information must be protected, including being protected from being observed by others.
Guidance: Using a compliant RSU in a public location protects the players’ personally identifiable information, while having the player fill in their personal information via an Online portal on a display in a public location typically does not.

3.2 Online Sale

3.2.1  Raffle sales shall occur only within Ontario, unless the license issued by the AGCO indicates the Raffle may occur in Ontario and other specified provinces, in which case the Ticket sales must occur only in those provinces specified on the license.

3.2.2 Requirements – At a minimum:

  1. The ERS must have mechanisms in place that are effective in detecting and dynamically monitoring the location where Ticket purchases are being attempted;

  2. The ERS must block Ticket sales where the location from which the purchase is being attempted has not been verified, is outside of Ontario for events licensed to occur in Ontario only, or is outside of all specified provinces including Ontario for events where the license issued by the AGCO indicates the raffle may occur in Ontario and other specified provinces; and

  3. The ERS must put in place mechanisms that are effective in detecting software, programs, virtualization, and other programs capable of circumventing player location detection.

3.2.3 The ERS solution must ensure that tickets are only sold to players who are eligible to play before a sale takes place.

3.2.4 When the Prize includes other age-restricted items, e.g. liquor, the minimum age to purchase the Raffle Ticket shall be the highest of all age-restrictions.

3.2.5 Sufficient player information to uniquely identify a player for the purpose of Raffle sales, distribution and audit of Prizes must be collected and securely stored. The following information must be collected, at a minimum:

  1. Full legal name;

  2. Age information sufficient to confirm eligibility to play;

  3. Address;

  4. Player contact information, e.g. phone number and email; and

  5. Method of identification for subsequent log on, where player accounts are implemented.

3.2.6 The ERS must require that players acknowledge the acceptance of Raffle rules of play before sales take place.

3.2.7 ERS supporting Online sales must provide full audit trail of player information and Tickets, and it must meet all applicable security and personal information storage standards in Ontario.

3.3 Player Accounts

3.3.1 If player account functionality is available, the ERS must support secure player account creation.

3.3.2 Only eligible individuals are permitted to create a player account and log on to their account.

3.3.3 All player accounts must be uniquely identifiable.

3.4 Raffle Sales Unit (RSU) Sale

3.4.1 RSU may sell Tickets when not communicating with the Backend System, provided all Ticket transactions are securely stored on the RSU. Upon the re-establishment of communication, the sale must be transmitted to the Backend System and be available for Draw.

3.4.2 The RSU functions that handle Raffle Tickets must perform as intended and without compromising the integrity of Raffles.

3.4.3 Improper activation of various RSU functions must not compromise the integrity of Raffle. For example, button inputs must function as designed.

3.5 Raffle Draw(s)

3.5.1 Raffle Numbers Draw may only be conducted after:

  1. Closure of the Raffle sales in accordance with the scheduled time period for the Draw
  2. Full reconciliation of all sold Tickets
  3. Full financial reconciliation of Tickets eligible for Draw
  4. Full financial reconciliation of sales, if necessary to determine Prize amount of the Draw, and
  5. Verification that only valid Raffle Numbers, including off-line sales, and only valid Raffle Numbers are entered into the Draw

3.5.2 The Raffle Draw must be conducted through a random selection process.

3.5.3 The Draw must include all sold valid Raffle Numbers, and exclude all invalid Raffle Numbers. The Raffle Numbers from unsold Tickets, Voided Tickets and Cancelled Tickets (whose Raffle Numbers that are not returned to the sale pool) are invalid, and must not be included in the draw.

3.5.4 A winning Raffle Number must be drawn for each advertised Prize.

3.5.5 Backend System must accurately and securely log information related to 3.5.1 and 3.5.4 for each Raffle Draw.

3.6 Verification of Draw

3.6.1 The ERS must provide the ability to independently verify the results of each Raffle Draw, if the Draw outcome and recording of winning Tickets is not a fully automated process.  At a minimum, the following must be possible to reconcile independently for each Draw prior to distributing the Prizes:

  1. Selection of winners
  2. Assignment of Prizes