Cancelled Ticket: A Raffle Ticket whose sale was cancelled.

Charity: An organization that has met the eligibility criteria to hold a lottery license under which it may conduct and manage a Raffle.

Backend System: A connected structure of computers, software and devices that is integral to the Charity’s conduct and management of Raffle Games that is not interacted with directly by players. It may include computer servers, software applications and database management systems.

Critical Game Data: Stored data that is considered vital to the integrity, security and accounting for the continued operation of Raffles. This includes, but is not limited to:

1. Raffle sales (Ticket transactions including financial transaction data, and jurisdiction in which transaction occurred where event is licensed to occur in more than one jurisdiction);
2. Raffle Numbers including selected winner(s), and jurisdiction where winning ticket(s) was purchased where event is licensed to occur in more than one jurisdiction;
3. Raffle Prizes, including jurisdiction where winning ticket(s) was purchased where event is licensed to occur in more than one jurisdiction;
4. POS/Ticket configurations;
5. Significant Events; and
6. Critical Software state (e.g. to enable recovery from unexpected interruptions).

Critical Game Options: Options and configurations of software, which, if configured incorrectly, would result in integrity issues, violate the Minimum Technical Standards,  Electronic Raffle Operational Terms and Conditions, Raffle License Terms and Conditions, or Lottery License Terms and Conditions.  

Critical Memory: Memory locations storing Critical Game Data. 

Critical Software: Any ERS software that affects the integrity or outcome of the Raffle. This includes, but is not limited to, any software that is used to control Raffle functions, Raffle outcome, payout, security, or accounting functions.

Draw: A random selection of winning Raffle Number(s) (or winners) conducted at a predetermined and scheduled time by means of a Random Number Generator or physical randomizer.

Electronic Raffle System (ERS): Consists of Backend System, and POS for frontend ticket sales; includes hardware, software, and applications for the purpose of conducting Raffles that:

1. Could influence the outcome of a Game held at a Gaming Site; or 
2. Is integral to the conduct, management, or operation of a Game.

Game: A game of Chance or mixed Chance and skill (as defined in Criminal Code of Canada); a Raffle is one type of Game.

Gaming Site: A premises or an electronic channel maintained for the purpose of playing or operating a lottery scheme (as defined in Gaming Control, Act 1992).

Online: Using the internet to facilitate self-service Raffle sales. 

Point of Sale (POS): Hardware or software interface with Backend System that facilitates Raffle Ticket sales; RSU, Online portal, and applications are typically used for this purpose.

Prize: A payout associated with winning Raffle Number(s) and may consist of a monetary amount or merchandise.

Progressive Raffles or Progressive: A type of Raffle that incorporates a feature that enables progress towards the accumulating Prize until a certain condition is met to trigger and award the accumulating Prize.

Raffle: A Game where Raffle Tickets are sold for a Chance to win a Prize at a Draw.

Raffle Number: Unique ERS-generated number assigned to Raffle Ticket for the purpose of participating in Raffle Draw.

Raffle Ticket or Ticket: A paper or electronic record of a sale which includes Raffle Numbers.

Raffle Sales Unit (RSU): Fixed base or mobile device, which communicates with the Backend System to facilitate the sale of Raffle Tickets.

Randomness or Chance: Observed unpredictability and absence of a pattern in a set of events that have definite probabilities of occurrence.

Random Number Generator (RNG): Hardware and/or software used to generate numbers which exhibit Randomness. 

Registrar:  The Registrar established under the Alcohol and Gaming Commission of Ontario Act, 2019.

Restricted Technical Procedure: A procedure, tool, or other mechanism that requires special software, special access identifier, or other information or technology that is restricted to the ERS provider.

Significant Events: Occurrences related to integrity, security or accounting, such as:

1. Changes to Raffle features and Critical Game Options;
2. Regular operation: Ticket transactions, Voids, and Cancellations;
3. Irregular conditions, e.g. errors in Ticket creation or security breach; and
4. Software authentication failure.

Validation Number: A unique number which identifies a particular Raffle Ticket and is used to validate the winning Raffle Number.

Voided Ticket: A sold Raffle Ticket whose Raffle Numbers are removed from the pool of valid Raffle Numbers in the ERS.
 

Point of Sale (POS) Operations

The objective of the requirements in this section is to ensure functions typically performed at the POS operate in a manner that maintains technical integrity and security of Raffles.

1.1 Communications

1.1.1 The integrity and security of all Ticket transactions must be maintained during communication between POS and Backend System, and Raffle Sales Unit (RSU) and printer..

1.1.2 The RSU printer must accurately communicate all error conditions back to RSU.

1.1.3 Significant Events must be communicated from POS to the Backend System in real time or as soon as it becomes technically possible, e.g. when communication is reestablished.

1.1.4 Interruptions in communications must not negatively impact Raffle integrity or security, e.g. any Critical Game Data related to Ticket transactions, and security events must be preserved.

1.1.5 Impacted POS functions must be disabled in case of the loss of communication with the Backend System.

1.2 Issuance of Raffle Tickets

1.2.1 Complete and accurate Raffle Ticket information as set out in 2.3.1 must be clearly presented on all issued Tickets to be valid.

1.2.2 An error condition must be displayed at the POS and logged in the event a Ticket is not issued but should have been. 

1.2.3 In case of POS shutdown by the Backend System during Ticket issuance, a valid Ticket must be issued or Cancelled/Voided, and the POS must display an explanatory message if a Ticket has been Cancelled/Voided.

1.2.4 The printer must be automatically disabled when a condition prevents proper operation of the printer. 

1.3 Applications and Data

1.3.1 The POS raffle applications must display information to uniquely identify themselves for verification purposes. Examples include their name, version, and cryptographic hash value.

1.3.2 The POS applications must provide sufficient information and messaging to instruct sellers and players, respectively how to complete the transactions of Raffle Tickets successfully.

1.3.3 It must not be possible to alter Critical Game Data or Critical Software at any time from the POS interface.
Guidance: The intent is for the Charity to conduct and manage Raffles without having any influence from POS interface.

1.3.4 POS application must be secured to prevent unauthorized access to Critical Software and Critical Game Data to ensure integrity and security of Raffle Game operations.

1.3.5 The Critical Game Data on mobile RSU devices must be protected from alterations by non-Raffle applications or corruption.

1.4 Raffle Displays

1.4.1 Raffle displays must accurately show players the Raffle Prize, and related event information, such as winning Raffle Number after a Draw.

1.4.2 Raffle Prize displays must be synchronized with the Backend System.

1.4.3  Monetary Raffle Prize amounts must be shown in the currency of the Raffle Prize and in a manner that is clear and easy to understand.

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

Backend System Servers with Raffle Applications

The objective of the requirements in this section is to ensure technical integrity is embedded in ERS design, audit, security, monitoring and accounting capability that enable Charities to conduct and manage Raffles while maintaining the public interest.

4.1 Design

4.1.1 ERS components critical to the outcome of Raffles must reside in Canada.

4.1.2 Mechanisms must be in place to ensure the reliability, integrity, and availability of the ERS.

4.1.3 The ERS components must have synchronized time when providing the following, at a minimum:

1. Time stamp for Ticket sales and Draws;
2. Time stamp for Significant Events; and
3. Referent time for logging and reporting.

4.1.4 The ERS must validate inputs before being processed to prevent risks to Raffle integrity or security.
Guidance:  This requirement is intended to ensure that inappropriate inputs do not compromise integrity or security of Raffles. For example, player inputs at Online POS must be validated to prevent malicious data injection, or Charity Raffle administration fields must be validated to be meaningful, e.g. numbers not accepted for letters.

4.1.5 ERS must be designed and tested to operate with integrity under anticipated load (total volume of sales and picks of Raffle Ticket transactions per minute) and communication bottlenecks in production environment.

4.1.6 The ERS must be designed for immunity against security attacks, such as security in depth (that is, multiple layers of security, so that if one layer is bypassed, the attack still has to get through the next layer, and so on).

4.1.7 Sensitive data must be secured and protected from unauthorized access or use at all times using industry good practices.

4.1.8 ERS components must not have access to nor be accessible from the internet beyond what is required by the ERS to support the Raffle solution.

4.2 Recovery

4.2.1 The ERS must be recoverable so that there is no impact on the integrity of the Raffle or the ability to audit the Raffle.

4.3 Access Control

4.3.1 The ERS must restrict users’ access based on business needs to the following, at a minimum:

1. Access privileges must be granted, modified, and revoked based on employment status and job requirements, and all activities associated with these actions are logged; and
2. All ERS accounts must be uniquely assigned to an individual.

4.3.2 Any changes to user access privileges must be logged, along with the user performing the change and time of the change. The following changes to user access privileges must be logged, at a minimum:

1. Account creation;
2. Account removal;
3. Disabling/suspension of an account;
4. Password change;
5. Change in role; and
6. Change in permissions.

4.3.3 A secure authenticator that meets industry good practices, e.g. strong password must be used to identify a user and his or her account to ensure that only authorized individuals are permitted to access their ERS account.

4.3.4 The ERS must automatically lock out accounts should identification and authorization requirements not be met after a defined number of attempts.

4.3.5 Logical access to the ERS must be fully auditable and all related events must be logged.

4.3.6 The ERS must prevent unauthorized access to sensitive database files/tables containing sensitive, confidential, or personally identifiable information, including stored procedures and passwords, and prevent their unauthorized alteration.

4.4 Secure Configuration

4.4.1 Only authorized personnel, Raffle Administrator/Manager may be permitted to configure the Raffle Game and Ticket information.

4.4.2 The ERS must not allow Raffle configuration changes that would adversely affect the security or integrity of the Raffle or any gaming-related information once the sale of Raffle Tickets has commenced.

4.4.3 ERS, data, activity logs and all other related components must be protected from threats, vulnerabilities, attacks, or breaches to ensure the integrity and security of the ERS, as follows, at a minimum:

1. All ERS components and connections between the ERS and any other system, whether internal or external third party, must be hardened in accordance with industry and technology good practices prior to going live and prior to any changes; and
2. The ERS must be protected against malware.

4.4.4 Functions performed by the Raffle Administrator/Manager at the Backend System must be technically restricted and not be possible to perform from POS.

4.4.5 The Backend System must have the ability to monitor and manage all RSUs and functions performed by Raffle sellers at the RSU, as follows, at a minimum:

1. RSU must have a unique identifier to allow for its monitoring and tracking;
2. RSUs must be authorized at the Backend System before being connected to it; 
3. Only authorized sellers can sell Tickets for a Raffle Draw after login to assigned RSUs;
4. Sellers can be enabled and disabled on-demand at the Backend System;
5. RSUs can be enabled or disabled on-demand at the Backend System; and
6. By default, all RSUs are disabled for sale of Tickets, except when assigned and enabled for sale of Tickets for a Raffle Draw.

4.5 Monitoring and Incident Response

4.5.1 Security activities must be logged in an auditable manner and monitored, as follows, at a minimum:

1. Attempts to attack, breach or access ERS components in an unauthorized manner;
2. Intrusion attempts must be actively detected and where possible prevented from causing disruption or outage of the ERS; and
3. There must be adequate logging to capture and monitor any attempts to attack, breach or access in an unauthorized manner any components of the ERS.

4.6 Data Governance

4.6.1 Appropriate, accurate and complete records of Ticket transactions and Raffle event information must be kept for the purposes of audits and other regulatory purposes. 

4.6.2 The Backend Systems must record and store complete data from Tickets and financial transactions (e.g. cash floats & collections), Draw accounting data for all valid and Voided Tickets and player data, including at a minimum:

1. Name of Charity conducting Raffle event;
2. The Draw ID, date and time;
3. Date and time of Ticket issuance;
4. Ticket price(s);
5. List of Prize(s), as applicable;
6. Value of Prize seeds, if any;
7. Winning Raffle Number(s) and Prize value(s);
8. Where the Raffle event is being held in more than one jurisdiction, the jurisdiction of the winning Raffle Number(s) and Prize value(s);
9. Financial information sufficient to reconcile Ticket sales, including payment method and price points of sold Tickets;
10. Where the Raffle event is being held in more than one jurisdiction, sufficient information to reconcile Ticket sales, including payment method and price points of sold Tickets, for each jurisdiction separately;
11. Player information, including name, address, age and contact information for Online sales;
12. Individual Ticket information per section 2.3.1;
13. Ticket status;
14. Ticket transactions history, including Voided and Cancelled Tickets;
15. Type of transaction or other method of differentiating ticket types;
16. POS; and
17. RSU seller ID.

4.6.3 Adjustments and corrections to Critical Game Data are permitted by authorized individuals, provided the following information is recorded in unalterable logs:

1. ID of authorized user who performed the change;
2. Date and time of change;
3. Type of data changed; and
4. The value of adjusted data before and after change.

4.7 Logging and Reporting

4.7.1 The ERS must provide at a minimum the following information for audit trail in on-demand generated reports with settable time periods and specific activities for each Raffle event:

1. Raffle Transactions - Information on all Ticket transactions and Draw accounting handled by the ERS, including: All valid, Cancelled and Voided Tickets with Raffle Numbers and Validation Numbers, Ticket price, transaction POS identifier, time of transaction, Prize seed(s), total sales, cash floats & collections, winning Raffle Number(s), and Prize(s) distributed;
2. Raffle Transactions – Where Raffle events occur in multiple jurisdictions, information on all Ticket transactions and Draw accounting handled by the ERS, including: The jurisdiction where the transaction occurred, and the jurisdiction where the winning Raffle Number(s) were purchased, and the Prize(s) distributed per jurisdiction;
3. Security Events – any information on access and attempted authentication including: Component(s) accessed, username, success or failure of authentication, time, any changes made;
4. Error Logs – All critical errors, e.g. failed software authentication and communication errors; and
5. Significant Events Log - At minimum the last 100 events with the appropriate time stamp.

Randomness of Raffle Draws

The objective of this section is to ensure the outcome of Raffles is random.

5.1 Random Number Generators (RNG)

The following requirements apply to RNG randomness and its implementation.

5.1.1 The outputs provided by RNG must pass applicable statistical tests of Randomness to demonstrate:

1. Statistical independence;
2. Uniform distribution over their range for intended Raffle Game; and
3. Unpredictability.

5.1.2 The range of random numbers used for statistical tests must correspond to the complete set of possible Raffle Game outcomes, as provided to the player, and to include both high and low end of Raffle sales.  The 99% confidence interval is applicable for Game specific statistical tests, including but not limited to frequency test, runs test and serial correlation test.

5.1.3 Valid RNG output must be used for Raffle Game outcome without alteration or secondary decision by the ERS.
Guidance:  The RNG output includes all necessary scaling performed such that the output is usable by the Raffle Game.

5.1.4 Where the Draw process of winning Raffle Numbers is interrupted, the original selection must be preserved until full ERS recovery.

5.1.5 The ERS must use secure communication protocols to protect RNG and random selection process.

5.1.6 Pools of Raffle Numbers must be stored securely.

5.2 Physical Randomizers

5.2.1 Physical randomizers that use the laws of physics to determine winning Raffle Ticket, must ensure Raffle Game integrity and Randomness of Raffle Draws (e.g. shuffling of Tickets).
Note: The Randomness and implementation of physical randomizers will be assessed on a case-by-case basis.

Integrity of Critical Software and Critical Game Data

The objective of the requirements in this section is to ensure technical integrity of the Critical Software and Critical Game Data during Raffle operations and that only approved software is installed.

6.1 Authentication of Critical Software

6.1.1 A mechanism that meets industry good practices must be built into the ERS to verify the integrity of the Critical Software in production in order to ensure approved software is being used with no unauthorized changes and Raffles operate as intended.

6.1.2 At a minimum, ERS must be successfully authenticated:

1. Immediately prior to the start of a Raffle event;
2. Before Raffle Draw for jackpot Prizes; and
3. On demand.

6.1.3 If the self-authentication fails, the software that fails authentication must enter an error condition, safely stop operation, and notify the Charity.

6.1.4 The results of each authentication must be recorded in an unalterable report.  This report must include a pass/fail condition with details on which software did not pass the authentication.

6.2 Remote Authentication of Raffle Sales Unit (RSU) Critical Software

6.2.1 Backend System must initiate independent verification on any client device or RSU Critical Software upon initial establishment of a connection with the system. When a threshold of unsuccessful verification attempts is reached, such client device or RSU must be disabled.

6.3 Critical Game Data Integrity

6.3.1 The ERS must accurately maintain the integrity of Critical Game Data to ensure the Raffle Game operates as expected and is auditable.

6.3.2 The ERS must employ methods to detect corruption and unauthorized alteration to its Critical Game Data to prevent integrity issues from occurring.

6.3.3 Detection of corrupted or unauthorized alteration of Critical Game Data that cannot be recovered must cause Raffle sales to be halted immediately and must cause the POS to enter into an error condition, and not resume Raffle sales until the condition has been addressed.

6.3.4 The integrity of RSU Critical Game Data must be maintained by methodology that enables failure detection, backup, and recovery of Critical Game Data.

6.3.5 It must be possible to extract RSU Critical Game Data through Restricted Technical Procedures without contaminating the data in the original storage media.

Electronic Raffle System (ERS) Environment and Deployment

The objective of this section is to link environmental and deployment requirements to ERS design.

7.1 Network Infrastructure

71.1 Communication protocol among ERS components over network infrastructure must be secure and must maintain Raffle Game integrity.

71.2 Network components must have synchronized time to preserve logging and auditing capability.

71.3 All gaming related network traffic exposed to public network lines must be secured using an industry standard method proven to prevent any security threats.

7.1.4 Network architecture must be designed in a way to prevent that a large volume of communications causes an integrity issue.

7.2 Remote Access to Backend System

7.2.1 Any remote access methods and associated procedures must limit access to authorized users and systems to perform specific tasks only through a secure link.

7.2.2 Remote access to ERS may only be granted to either the Charity or the Gaming-Related Supplier via a secure method (e.g. VPN client with two-factor authentication), provided the access is monitored and the following records are created and captured in an automated fashion that prevents alteration of the records, at a minimum:

1. Log-on name
2. Time, date and duration of the connection
3. Activity while logged-on
4. Specific areas accessed
5. All Raffle related changes made

7.3 Independent Security Assessment

7.3.1 Publicly exposed ERS (e.g. Web applications accessible through public networks) must be protected with adequate security measures to prevent any integrity or security issues.

7.3.2 ERS’, including all related components, that are publicly exposed must be independently assessed prior to initial deployment, and on a regular basis thereafter, in accordance with industry good practice security frameworks by qualified individuals to ensure that security vulnerabilities are identified and assessed, and risks are promptly mitigated or otherwise confirmed to be negligible.

7.3.3 Modifications to publicly exposed ERS may require assessment, as well, depending on the complexity and number of changes. These will be assessed on a case-by-case basis.

7.4 Submission Requirements for Approval of Electronic Raffle Systems

7.4.1 The Gaming-Related Suppliers or Charity must provide necessary information, training and tools pertaining to the Electronic Raffle Systems for which the approval is being requested to help facilitate AGCO assessment, testing, and issuing decisions in a timely manner.
Note: As per AGCO Info Bulletin No. 89 from November 30, 2018, Charities have the flexibility to develop and use their own ERS solution.

7.4.2 All requests for approval of Electronic Raffle Systems must adhere to the, “AGCO Gaming Technology Submission Requirements”, including being accompanied with fully and accurately completed iAGCO submission.

7.5 Ensuring the Ongoing Integrity of Approved Electronic Raffle Systems

7.5.1 Gaming-Related Suppliers and Charities must promptly notify the Registrar per Notification Matrix – Electronic Raffles of any integrity, security or accounting capability concerns with the approved Electronic Raffle Systems.