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 licensing of Raffle events.

2.2.2 Players must be provided with clear, meaningful, and accurate information to enable them to make informed choices. For example, this includes any applicable price discounts for purchasing multiple Raffle Numbers or entries on one Ticket, that the 50-50 Raffle Prize will be 50% of sales, that the currently displayed Raffle Prize is an estimated amount where applicable, Subscription options where available, how to opt-out or cancel from a Subscription, and how failure of automatic payment will be handled for a Subscription.

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;
  7. All applicable Draw date(s), e.g. early bird, main and consolation Draw dates; and
  8. The total number of times the Raffle Number will be entered into the draw if the Raffle Number is entered more than one time.

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; and
  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.

Raffle Game Process

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 Sales

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.

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.2 The ERS solution must ensure that tickets are only sold to players who are eligible to play before a sale takes place.

3.2.3 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.4 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.5 The ERS must require that players acknowledge the acceptance of Raffle rules of play before sales take place.

3.2.6 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 Subscriptions

3.3.1 Raffles that support Subscription options must, at a minimum:

  1. Require deliberate action to opt-in on the part of the player in order to participate in a Subscription; and
  2. Notify the player in advance of each automatic billing purchase being processed.

3.3.2 The following information must be provided to the player in a manner that is clear and accurate upon entering into a Subscription:

  1. The events included in the Subscription;
  2. The cost of each event in the Subscription;
  3. The duration of the Subscription;
  4. That automatic billing will occur for future events; and
  5. How to opt-out or cancel the Subscription.

3.3.3 A feature to opt-out or cancel a Subscription, including auto-payment options, is required and must at a minimum:

  1. Be displayed prominently to enable players to easily locate the feature;
  2. Be available at all times to enable a player to cancel entry into Raffles for which payment has not yet been processed;
  3. Not come at a cost or penalty to any player choosing to opt-out or cancel;
  4. Be provided via all channel(s) Subscription opt-in options are available; and
  5. Have instructions included about how to opt-out or cancel the Subscription with each automatic billing purchase notification per 3.3.1b).

3.4 Player Accounts

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

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

3.4.3 All player accounts must be uniquely identifiable.

3.5 Raffle Sales Unit (RSU) Sale

3.5.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.5.2 The RSU functions that handle Raffle Tickets must perform as intended and without compromising the integrity of Raffles.

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

3.6 Raffle Draw(s)

3.6.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;
  5. Verification that all valid Raffle Numbers, including off-line sales, are entered into the Draw the correct number of times, and only valid Raffle Numbers are entered into the Draw; and
  6. For all Raffle Numbers entered into the Draw more than one time, the ERS must be auditable to demonstrate which Raffle Number entry was selected as the winner.

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

3.6.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 are not returned to the sale pool) are invalid and must not be included in the draw.

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

3.6.5 Backend System must accurately and securely log information related to 3.6.1 and 3.6.4 for each Raffle Draw.

3.7 Verification of Draw

3.7.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; and
  2. Assignment of Prizes.