• Cancelled Ticket: A Raffle Ticket whose sale was cancelled.
• Charity: An organization that has met the eligibility criteria to hold a lottery licence 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 transactions data)
  2. Raffle Numbers including selected winner(s)
  3. Raffle Prizes
  4. POS/Ticket configurations
  5. Significant Events
  6. Critical Game 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 standards or policy and licensing rules. 
• 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 as frontend; 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 means 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.in the conduct, management or operation of lottery scheme (as defined in Gaming Control, Act 1992).
• Online means using the internet to facilitate self-service Raffle sales.
• Point of Sale (POS) means hardware and/or software interface with Backend System that facilitates Raffle Ticket sales; RSU and Online portal are typically used as POS.
• 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, Cannabis and Gaming Regulation and Public Protection Act, 1996
• Restricted Technical Procedure means 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 and 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
  4. Software authentication failure

• Supplier means Gaming Related Supplier as defined in Regulation 78/12.
• 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.

1 Point of Sale 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, if a Ticket is not properly issued. 

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.

2 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. Draw identifier, and
6. 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 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.2 Online Sale

3.2.1 The ERS must employ a mechanism to ensure Ticket sales are taking place within Ontario.

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. 
Note: An individual under 18 years of age must not be permitted to play. When the Charity is offering liquor items as Prize, the minimum age is 19.

3.2.3 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

5. Method of identification for subsequent log on, if player account is implemented

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

3.2.5 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

4 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 All ERS components critical to the outcome of Raffles must reside in Ontario.

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
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 (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 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.
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
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, including stored procedures and passwords, and prevent their unauthorized alterations.

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.
2. The ERS must be protected against malware.

4.4.4 Functions performed by 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 that is sufficient 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.
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 to 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
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. Financial information sufficient to reconcile Ticket sales, including payment method and price points of sold Tickets
9. Player information, including name, address, age and contact information for Online sales
10. Individual Ticket information per section 2.3.1
11. Ticket status
12. Ticket transactions history, including Voided and Cancelled Tickets
13. Type of transaction or other method of differentiating ticket types
14. POS
15. 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
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 Numbers and Prizes distributed.
2. Security Events – any information on access and attempted authentication including: component accessed, username, success or failure of authentication, time, any changes made.
3. Error Logs – All critical errors, e.g. failed software authentication and communication errors, and

4. Significant Events Log - At minimum the last 100 events with the appropriate time stamp.

 

5 Randomness of Raffle Draws

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

5.1 Software Random Number Generator (RNG)

The following requirements are applicable to software Random Number Generators and their implementation.

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

1. Statistical independence
2. Uniform distribution over their range for intended Raffle Game
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.

 

6 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 the approved software is being used (no unauthorized changes) and Raffles operates as intended.

At a minimum, ERS must be successfully authenticated:

1. Immediately prior to the startup of Raffle event
2. Before Raffle Draw for jackpot Prizes, and
3. On demand

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

6.1.3 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 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.

7 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 Supplier from their respective secure business location by a method, such as VPN client with two-factor authentication, provided it is monitored and the following records were made, 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. 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 New ERS that are publicly exposed must be assessed in accordance with industry good practices security frameworks by qualified individuals to ensure that security vulnerabilities are identified and assessed, and risks are confirmed to be negligible through security/penetration testing, as applicable.

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 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 submission requirements, “AGCO Electronic Raffle Systems Submission Requirements”, including being accompanied with fully and accurately completed AGCO submission form(s).
Note: Submission materials may be most efficiently provided via a secure electronic mechanism, e.g. sFTP.

7.5 Ensuring the Ongoing Integrity of Approved Electronic Raffle Systems

7.5.1 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.