iGaming — Standards and Requirements

Standards 7 – 12 removed April 2022; see the Registrar’s Standards for Internet Gaming.

7. Player Account Management (iGaming)

Registration and Account Creation

Note: This Standard is only applicable to the OLG’s igaming activities. All other igaming Operators wishing to enter Ontario’s regulated market should refer to the Registrar’s Standards for Internet Gaming.

7.1 Relevant player information shall be collected and saved upon registration and shall be demonstrated to be complete, accurate and validated before a player account is created for the player.

Requirements – At a minimum, the following information shall be gathered upon registration:

  1. Name.
  2. Date of birth.
  3. Address.
  4. Method of identification for subsequent log on.
  5. Player contact information.
  6. Information required by the Proceeds of Crime (Money Laundering) and Terrorist Financing Act and to be filed with FINTRAC.

7.2 Before a player account is created, players shall affirm that all player information provided upon registration is complete and accurate.

7.3  Only eligible individuals are permitted to create a player account and gamble.

Note: This Standard does not preclude the AGCO and OLG from being granted access to accounts for purposes of testing and/or monitoring. 

Player Account Maintenance and Transactions

7.4 Player information shall be kept complete and accurate.

7.5 Prior to participating in game play, players must affirm that they are fit for play.

7.6 Only eligible individuals who hold a valid player account are permitted to log on to their account and gamble.

Note: This does not preclude the AGCO and OLG from being granted access to accounts for purposes of testing and/or monitoring.

7.7 All player accounts shall be uniquely identifiable.

7.8 Players may have only one player account with an Operator.

7.9 The list of prohibited and excluded individuals may change from time to time. Player information shall be re-verified at the time of change and at regular intervals thereafter.

Guidance: The intent is to ensure that each time the list of individuals who are prohibited from accessing gaming sites or playing lottery schemes under Standards 3.1 and 3.2 changes, all registered player information is checked to ensure that all registered players are still eligible to play and, if they are not eligible, they are prohibited from gambling.

7.10 There shall be an auditable trail of events that is logged and available relating to account creation and activation and account changes.

Requirements – At a minimum, an auditable trail of events shall be available for the following:

  1. Information relating to player identification and verification.
  2. Information related to any contractual agreements entered into between the OLG and the player.

7.11 Players shall acknowledge and accept the terms of the contract between the player and OLG prior to account creation and shall acknowledge and accept any subsequent changes to the terms of the contract when the player logs onto their account.

7.12 All players shall be authenticated prior to accessing their player account and being permitted to gamble.

7.13 All player account transactions shall be recorded and logged in an accurate and complete manner.

7.14 Player account information shall be made readily available to the player.

7.15 All player account transactions shall be made readily available and clear to the player.

Requirements – At a minimum, the gaming system shall give the player access to the following player account transactions:

  1. Deposit/withdrawal history, and current balance.
  2. Log in time, last log in time and last log out time.
  3. Gaming event and transaction history.
  4. Method and source of funds used for transactions.
  5. Total monies wagered for session and/or period of time.
  6. Total monies won or lost for session and/or period of time.
  7. Account balance at start and end of session.
    Guidance: Player account transactions under this Standard would not include logs of game play activity (e.g. log for each hand played).

7.16 All player account transactions shall be uniquely identifiable and traceable to a unique individual player account. 

Deactivation and Dormant Accounts

7.17 Reasonable efforts shall be made to inform players of player funds remaining in dormant accounts.

7.18 Players may elect to deactivate their player account at any time and, once the election is made, the account is deactivated.

7.19 There shall be an auditable trail of events logged and available regarding account deactivation.

7.20 Where necessary, a player account may be deactivated by the Operator.

7.21 A player account shall be deactivated if requested by the Registrar.

7.22 If player information is removed, OLG shall ensure that it is archived in accordance with records retention schedules.

7.23 Where an account becomes dormant, the player shall be able to recover the balance of their account owing to them.

7.24 Where an account is deactivated, by a player or another authorized individual, the player shall be able to recover the balance of their account owing to them.

8. Funds Management (iGaming)

Deposits

Note: This Standard is only applicable to the OLG’s igaming activities. All other igaming Operators wishing to enter Ontario’s regulated market should refer to the Registrar’s Standards for Internet Gaming.

8.1 A player may be permitted to deposit funds into his/her player account only after the appropriate verifications and authorization.

Requirements – At a minimum, deposits shall be verified and authorized to ensure the following:

  1. Deposits made are appropriately authorized by a financial services provider.

Withdrawals

8.2 Players are permitted to withdraw funds from their player account only after the appropriate verifications and authorization.

Requirements – At a minimum:

  1. Withdrawals shall be verified and authorized to ensure the following, before a withdrawal is permitted:
    1. The withdrawal is being made by a holder of the account;
    2. The withdrawal is being transferred to an account of which the player is a legal holder;
    3. Where winnings are equal to $10,000 or more, additional verification shall take place to ensure that the player is eligible to receive the winnings.

8.3 Players are permitted to withdraw funds from their player account in an accurate and complete fashion and within a reasonable timeframe.

Funds Maintenance and Transactions

8.4 Player funds shall be clearly and appropriately managed.

8.5 All player funds deposited shall be held in an OLG account.

8.6 Operators shall not extend credit or lend money to players or refer players to credit providers or imply or infer that a player should seek additional credit to play games.

8.7 A player shall never have a negative funds balance.

8.8 Players shall be provided with a clear and accurate representation of their funds account balance that is easily accessible and readily available at all times.

Requirements – At a minimum:

  1. The player balance shall be displayed in Canadian dollars.

8.9 Players shall be provided with unambiguous information about all player account fees prior to making a withdrawal or deposit.

8.10 Players shall be informed clearly and specifically of all rules and restrictions regarding deposits and withdrawals and access to funds in connection with deposits and withdrawals.

8.11 Funds shall not be transferred between player accounts without the Registrar’s approval.

8.12 Adjustments to player accounts shall be made accurately and only by authorized individuals.

8.13 Adjustments to player accounts shall be recorded and logged in an accurate and complete manner.

8.14 Players shall be provided with accurate, clear and specific reasons for any adjustments made to their accounts.

9. Security (iGaming)

Architecture and Infrastructure

Note: This Standard is only applicable to the OLG’s igaming activities. All other igaming Operators wishing to enter Ontario’s regulated market should refer to the Registrar’s Standards for Internet Gaming.

9.1 The gaming system architecture and all its related components shall demonstrate security in depth.

9.2 All gaming systems and devices shall validate inputs before inputs are processed.

9.3 The gaming system shall only display the minimum information about the gaming system to unauthorized users and during system malfunctions.
Guidance: The intent is to ensure that the gaming system does not display unnecessary information to unauthorized individuals that may be used to compromise the gaming system or privacy of information.

9.4 All remote access methods shall be appropriately secured and managed.

9.5 Use of wireless communication shall be secured and only used where appropriate.
Guidance:
The intent is to ensure that wireless communication is not present in areas
where it could be potentially harmful (e.g. data centres).

9.6 All components shall be hardened as defined by industry and technology good practices prior to going live and as part of any changes.

Requirements – At a minimum:

  1. All default or standard configuration parameters shall be removed from all components where a security risk is presented.
  2. The appropriateness and effectiveness of steps taken to harden technology components shall be regularly assessed and, if appropriate, changes must be made to improve the hardening.

9.7 Access shall be appropriately restricted to ensure that the domain name server records are kept secure from malicious and unauthorized changes.

Data and Information Management

9.8 All private encryption keys shall be stored on secure and redundant media that are only accessible by authorized management personnel.

9.9 Encryption keys must be appropriately rotated at regular intervals.

9.10 The gaming system architecture shall limit the loss of data and session information.

System Account Management

9.11 The gaming system shall be able to change, block, deactivate or remove system accounts in a timely manner upon termination, change of role or responsibility, suspension or unauthorized usage of an account.

9.12 A secure authenticator that meets industry good practices shall be used to identify a user and his or her account to ensure that only authorized individuals are permitted to access their system account on the gaming system.

Requirements – At a minimum:

  1. The gaming system shall automatically lock out accounts should identification and authorization requirements not be met after a defined number of attempts.

9.13 The gaming system shall ensure that all access to the system is fully attributable to, and logged against, a unique user identification.

9.14 Only the minimum access rights shall be granted to each system account on the gaming system and access rights shall be clearly documented.

9.15 All temporary and guest accounts shall be disabled immediately after the purpose for which the account was established is no longer required.

9.16 System accounts and system access rights for the gaming system shall be regularly reviewed and updated.

9.17 A log of account owners shall be kept and regularly reviewed and updated.

9.18 A mechanism shall be in place to ensure that the assignment of administrator accounts is approved by the Operator’s management and that usage is monitored for appropriateness.

9.19 Inappropriate use of system accounts on the gaming system shall be logged, reviewed and responded to within a reasonable period of time.

9.20 Inappropriate use of administrator accounts shall be reported to the Registrar in a timely manner.

Software

Note: The following Standards apply to the following types of software: 1) Commercial off the shelf software, 2) Modified commercial off-the-shelf software, 3) Proprietary developed software, and 4) OLG specific developed software.

9.21 Software used for the gaming system shall be developed using industry good practices.

9.22 Software development methodologies used shall be clearly documented, regularly updated and stored in an accessible, secure and robust manner.

9.23 An appropriate system shall be in place to manage the software development and ongoing software management lifecycle.

9.24 All software development roles shall be segregated during and after release of code to a production environment.

9.25 The Operator shall establish an appropriate audit trail of authority and management review of code for software.

9.26 Controls shall be in place to ensure software is appropriately secured and access is appropriately restricted throughout development.

9.27 The Operator’s authorized management staff shall review and approve software documentation to ensure that it is appropriately and clearly documented.

9.28 Source code and compiled code shall be securely stored.
Guidance: Compiled code could be digitally signed or hashed (including each time there is a change) in a manner that allows for external verification.

9.29 The promotion or movement of code from testing through other environments to production shall be accompanied by the appropriate documentation and approvals.

9.30 All promotion of code from development to production shall only be performed by production support staff and not by development staff.

9.31 Appropriate testing environments shall be in place to allow for thorough testing of any code before it is put into production.

9.32 Access to production environments shall be restricted from development personnel.
Note: This does not preclude granting of temporary supervised access for conducting technical investigations that may only be performed on the production environment.

9.33 Development code shall not be present in the production environment.

9.34 A mechanism shall be built into the gaming system to verify the integrity of the software that is deployed to production, including before changes are implemented, as well as on an ongoing basis.

9.35 Appropriate release and configuration management systems shall be in place to support software development.

9.36 All code developed by a third party shall be tested to ensure it meets industry good practices and that it performs to meet its purpose prior to being added to the testing environment and prior to integration testing.

9.37 All code developed by a third party shall pass integration testing before it is added to production.

9.38 Mechanisms shall be in place to ensure that bugs are identified and addressed prior to, and during, production.

9.39 Quality assurance processes, including testing, shall take place during development and prior to the release of any code.

9.40 All components, where appropriate, shall be tested for the purposes for which they will be used.

Change Management

9.41 Post implementation reviews shall be performed to ensure that changes have been correctly implemented and the outcomes shall be reviewed and approved.

9.42 All change related documentation and information shall be captured, stored and managed in a secure and robust manner.

9.43 The implementation of software related updates, patches or upgrades shall be regularly monitored, documented, reviewed, tested and managed with appropriate management oversight and approval.

9.44 A mechanism shall be in place to regularly monitor, document, review, test and approve upgrades, patches or updates to all gaming-related hardware components as they become end of life, obsolete, shown to have weaknesses or vulnerabilities, are out-dated or have undergone other maintenance.

9.45 Appropriate release and configuration management processes with support systems shall be in place to support both software and hardware related changes.

9.46 Only dedicated and specific accounts may be used to make changes.

10. Game Play and Management (iGaming)

Display and Game Information

Note: This Standard is only applicable to the OLG’s igaming activities. All other igaming Operators wishing to enter Ontario’s regulated market should refer to the Registrar’s Standards for Internet Gaming.

10.1 The player shall be provided with accurate information to enable the player to make informed choices.

Requirements – At a minimum:

  1. For each game, the theoretical payout shall be provided:
    1. For games that include progressive awards, limited time awards, metamorphic elements or game-within-a-game awards, the variable contribution of such awards to the theoretical payout percentage shall be clearly disclosed;
    2. For games which have different theoretical payout percentages for different betting options, the lowest theoretical payout percentage of all betting options shall be disclosed, as a minimum;
    3. For games that have skill and/or strategy components, the theoretical payout percentage shall be calculated using a disclosed, generally known and/or publicly available strategy. If there is no such standard/published strategy, the theoretical payout percentage shall be calculated using a blind strategy (random choice).
  2. Games with elements of skill or strategy shall either disclose the optimal strategy or provide other information to the player that is sufficient to derive the optimal strategy.
  3. For any top award that has a probability of less than 1 in 17 million to win, the probability shall be disclosed to the player.
  4. For any other award that has a probability of less than 1 in 34 million to win, the probability shall be disclosed to the player.

10.2 Information shall be displayed for a length of time that is sufficient for the player to understand their bet and the result of the game.

Speed and Interruption

10.3 Where speed of interaction has an effect on the player’s chances of winning, the Operator shall take reasonable steps to ensure the player is not unfairly disadvantaged due to gaming system related performance issues.

10.4 Service interruptions shall be responded to and dealt with in a way that does not disadvantage players.

Requirements – At a minimum, the gaming system shall:

  1. Inform players that the speed of connection or processor may have, or appear to have, an effect on the game;
  2. Recover from failures that cause interruptions to the game in a timely fashion;
  3. Where appropriate, void bets;
  4. Retain sufficient information to be able to restore events to their pre-failure state, if possible;
  5. Return bets to players where a game cannot be continued after a service interruption.

10.5 For all single player games, a mechanism shall be in place to require a player to complete an incomplete game before a player is allowed to participate in any other games, where possible.

Peer-to-Peer Games

10.6 For all peer-to–peer games, the player shall be made aware of possible communication loss and the impact to the player in such an event.

10.7 Operators shall ensure that no programs are used to participate in peer-to-peer games with players (e.g. robots).

10.8 Mechanisms shall be in place to detect and prevent situations where players in peerto- peer games may be using software/programs (e.g. robot play) to create an unfair advantage during game play.

Requirements – At a minimum:

  1. OLG shall require the player to enter into an agreement which clearly states that using software or programs to play games on a player’s behalf is prohibited.

10.9 A mechanism shall be in place to allow players to report suspected use of robots.

10.10 A mechanism shall be in place to ensure that a player cannot play against himself/herself.

10.11 Players shall not be unjustly treated or unfairly disadvantaged by the actions of other players.

10.12 Where players are unjustly treated or unfairly disadvantaged by the actions of other players, a mechanism shall be in place to detect, log and respond appropriately to this behaviour.

Determination of Game Outcomes

10.13 All possible game outcomes (winning and losing outcomes) shall be available in each play, unless clearly explained in the rules of play.

10.14 The probability of game outcomes in virtual games shall be the same as in the associated live game (e.g. card games), unless the differences are set out in the rules of play and communicated to players.

10.15 The probability of achieving any specific game outcome shall be constant and independent of game history, player or any other factor.

Guidance: The intent is to ensure that where the outcome of a game should be truly random (i.e. dice games, slot games), the outcome is not dependent or based upon any game history or other factors. This Standard is not meant to prohibit games which are based on cumulative play i.e. metamorphic games.

10.16 Bets shall be committed before the selection of game elements and associated game outcomes. Any wager received after the selection of game elements or associated game outcomes associated with the wager shall be voided and returned to the player.

Randomness of Game Outcomes

10.17 A mechanism shall be in place to randomly select game elements used to determine game outcomes.

10.18 The mechanism used to select game elements and their associated game outcomes shall be impervious to outside influences: including electro-magnetic interference; devices within or external to the gaming system; characteristics of the communications channel between the gaming system and the end player device; players; and the Operator.

10.19 Mechanical and electrical devices used to select game elements and their associated game outcomes shall meet the following:

  1. Components shall be constructed of materials that will not degrade or impact the randomness of the selection before their scheduled replacement lifecycle;
  2. The devices shall be capable of being monitored and inspected to ensure the integrity of the device and randomness of the generated outcomes.

10.20 The selected game elements and their associated game outcomes shall not be influenced, affected or controlled by the amount wagered, or by the style or method of play unless the conditions of play are changed and are clearly disclosed to the player.

10.21 The selected game elements and their associated game outcomes shall not be altered, discarded or otherwise manipulated through a secondary decision by the game program.

10.22 There shall be a mechanism in place to ensure that the randomness of selected game elements is not impacted by load on the gaming system.

10.23 Selected game elements shall not be supplied to more than one player, unless required by the rules of play.

10.24 Initial values and conditions shall be selected and used to seed the random selection process in a way that ensures the randomness of the resulting game outcomes, and avoids any correlation of selected game elements with elements selected by any other instances of the mechanism.

10.25 Re-initialization of initial values shall be kept to a minimum. Initial values shall be reinitialized, if corrupted.

10.26 Where the random selection process is interrupted, the next selection shall be a function of the selection produced immediately prior to the interruption, where possible.

10.27 Any failure of the mechanism used to select game elements shall be quickly identified and responded to in an appropriate and timely manner in order to minimize the effect on players.

10.28 Where there is a failure of the mechanism used to select game elements, games that rely upon that mechanism shall be made unavailable until the failure has been rectified.

Automated Functionality

10.29 A mechanism shall be in place to ensure that the player retains control of betting where auto-wagering functionality is provided.

Requirements – At a minimum, the auto-wagering functionality shall:

  1. Enable the player to choose the bet, and either the number of auto-wagering bets or the total amount to be bet.
  2. Enable the player to stop the auto-wagering regardless of how many auto-wagering bets were initially chosen or how many remain.
  3. Not override any of the display requirements, e.g. the result of each bet shall be displayed for a reasonable length of time before the next bet commences.
  4. Enable the player to limit the dollar amount gambled and/or length of play.
  5. Provide reasonable limits to the length of time auto-wagering can continue.

Game Management

10.30 Where applicable, game interface changes made by the player shall be appropriately limited by the gaming system to ensure that information and representation of the game remains fair and accurate and in accordance with the rules of play.

10.31 Rules of play shall not be changed during a game session unless the player is made aware of the change and no bets have been placed by the player.

10.32 Where games have been changed, players shall be notified of the changes and the impact on the rules of play before the game is played.

10.33 All game sessions shall be appropriately secured and checked for authenticity.

10.34 There shall be a player inactivity time-out that automatically logs the player out or ends the player’s session after a specified period of inactivity.

Downloadable Game Content

10.35 All downloadable games shall be set up and provided to the player in a secure manner with all relevant information provided to the player.

Requirements – At a minimum, downloadable games shall include:

  1. Separate and distinct rules of play.
  2. Separate and distinct security parameters.

10.36 All critical functions, including the generation of the outcome of any game, shall be generated by the gaming system, independently of the end player device.

Guidance: The intent is for the Operator to maintain control (i.e. security, integrity) of all critical game functions.

Collusion and Cheating

10.37 Mechanisms shall be in place in order to facilitate investigation of collusion and cheating and, if necessary, deactivation of player accounts or player sessions in a timely fashion when detected.

 

11. Responsible Gaming (iGaming)

Note: This Standard is only applicable to the OLG’s igaming activities. All other igaming Operators wishing to enter Ontario’s regulated market should refer to the Registrar’s Standards for Internet Gaming.

11.1 All lottery schemes shall be entered into willingly by the player.

Guidance: The intent is to ensure that the player is not forced into game play simply by
selecting the game.

11.2 Players shall be provided with an easy and obvious way to set gaming limits (financial or time based) upon registration and at any time after registration.

Requirements – At a minimum:

  1. Players shall be provided with the option to set loss and deposit limits during registration.

11.3 Where a gaming limit has been previously established by a player, a request to relax or eliminate that limit shall only be implemented after a cooling-off period.

Requirements – At a minimum:

  1. The cooling-off period shall be 24 hours.

11.4 Where a gaming limit has been previously established by a player, it may not be relaxed by an Operator acting unilaterally, without instructions from the player.

11.5 Gaming limits, however imposed, shall be enforced by the gaming system.

Requirements – At a minimum:

  1. Players shall be clearly notified that the game or gaming session has come to an end due to a gaming limit.

11.6 The registration page and pages within the player account shall prominently display a responsible gambling statement.

11.7 A mechanism shall be in place to monitor and detect game and account transactions which may indicate signs of problem gambling.

11.8 Removed, July 2019.

11.9 There shall be reasonable and appropriate breaks in play.

11.10 Advertising and marketing materials that communicate gambling inducements, bonuses and credits are prohibited, except on an operator’s gaming site and through direct advertising and marketing, after receiving active player consent. [New: December, 2021]

Guidance: This standard does not prohibit the use of inducements, bonuses and credits.
This standard prohibits all public advertising, including targeted advertising and algorithm-based ads.
Direct marketing and advertising includes but is not limited to: direct messaging via social media, emails, texts, and phone calls.

12. Other Operator Standards (iGaming)

General

Note: This Standard is only applicable to the OLG’s igaming activities. All other igaming Operators wishing to enter Ontario’s regulated market should refer to the Registrar’s Standards for Internet Gaming.

12.1 Employees shall receive training appropriate to their role and be competent in carrying out their duties.

12.2 The contract between the player and OLG shall clearly state that all applicable laws must be complied with.

12.3 Relevant information about the AGCO shall be displayed and easily accessible to the player.

Incident Management

12.4 The Registrar shall be notified about incidents in accordance with the established notification matrix.

Guidance: The intent is only to inform the Registrar of incidents which are of a regulatory concern. These may include:

  1. Incidents related to gaming system integrity
  2. Incidents related to security
  3. Incidents related to accounting improprieties
  4. Incidents related to cheat at play

Logging Management and Reporting

12.5 There shall be appropriate, accurate and complete records of transaction and game state and play information kept and made available for the purposes of:

  1. Ensuring timely investigations can be performed by the Registrar.
  2. Capturing information needed to continue a partially complete game within a reasonably defined time
  3. Resolving disputes in a fair and timely manner.
  4. Ensuring player complaints can be resolved.
  5. Tracking all relevant player information (including funds information).
  6. Tracking all relevant individual gaming sessions and game play information.
  7. Tracking all relevant information related to events (including significant events).
  8. Tracking of game enabling, disabling and configuration changes.

    Guidance: There should be an adequate amount of storage, capacity and retention of logged information.

The appropriate capacity, design and monitoring of the logging facilities should be in place to ensure that logging is not interrupted for a technical reason that could have been prevented.

The following are EXAMPLES ONLY of what should be recorded and logged.

Recorded and logged information should include the following:

Information that could be used in investigations

  1. Amending player balances
  2. Changing game rules or pay-tables
  3. Changing administrator or root level access

Player Account Information

  1. Player identity details (including player identity verification results)
  2. Account details and current balance
  3. Changes to account details, such as change of address, change of credit card, or change of name
  4. Any self-imposed player protection limitations
  5. Any self-imposed player protection exclusions
  6. Details of any previous accounts, including reasons for deactivation
  7. Deposit/withdrawal history
  8. Game play history (e.g. games played, amounts bet, amounts won, progressive jackpots won, etc.)

Gaming Session and Game Play Information

  1. Unique player ID
  2. Unique game identifier
  3. Game session start and end time
  4. Player account balance at start of game
  5. Amount wagered
  6. Contributions to progressive jackpot pools (if any)
  7. Current game status (i.e. in progress / complete)
  8. Game result/outcome
  9. Progressive jackpot wins (if any)
  10. Game end time
  11. Amount won
  12. Player account balance at end of game

Event Information

  1. Player registration or player account creation and deactivation
  2. Changes to player registration (e.g. address) or account details (e.g. balance, player configurable parameters)
  3. Changes made to game parameters
  4. Changes made to jackpot parameters
  5. New jackpot created
  6. Jackpot retired
  7. Large wins
  8. Jackpot wins
  9. Any large transfer of funds
  10. Loss of communication with a player device
  11. Player exclusion (including exclusion, requests to lift exclusion, and actual lifting of exclusion)

Significant Event Information

  1. Changes made to game parameters
  2. Changes made to progressive jackpot parameters
  3. New progressive jackpots created
  4. Progressive jackpot shutdowns

Note: The above are examples only and are not to be considered a complete list.

12.6 There shall be a mechanism in place to ensure that if logging is interrupted, compensating manual controls are used, where reasonable.

12.7 The gaming system shall be capable of providing unfettered custom and on- demand reports to the Registrar.

Guidance: The intent is to ensure that the Registrar can receive information in the appropriate format when necessary.

The following are EXAMPLES ONLY of the types of reports that may be generated:

  1. A list of all currently (or previously) active player accounts
  2. A list of all currently (or previously) dormant player accounts
  3. A list of all accounts for which the player has currently (or previously) imposed a player protection self-exclusion
  4. A list of all accounts for which the player has currently (or previously) been excluded from the site (i.e. involuntary exclusion)
  5. A list of all accounts for which the player’s funds have currently (or previously) been inactive for a period of time exceeding 90 days
  6. A list of all accounts for which one or more of the player’s deposits and/or withdrawals have exceeded a configurable limit (i.e. large deposits/withdrawals. The limit shall be configurable for single transactions, as well as aggregate transactions over a defined time period.
  7. A list of all accounts for which one or more of the player’s wins have exceeded a configurable limit (i.e. large wins). The limit shall be configurable for single wins, as well as aggregate wins over a defined time period.
  8. A list of all currently active gaming sessions
  9. A list of all games hosted by the website, including approved game/paytable
    versions

Note: The above are examples only and are not to be considered a complete list.

12.8 Information regarding specific game elements (such as a player’s hand or cards) shall not be accessible to give advantage to any player during games, unless by the player themselves.

12.9 The Operator shall ensure that investigators (OPP or Registrar) are able to monitor and participate in games.

Complaints and Help Management

12.10 A mechanism shall be in place to allow players to contact the Operator in a timely fashion with issues or complaints relating to their player account, funds management, game play or any matter related to compliance with the Standards and Requirements. The Registrar shall be notified of any such issues or complaints, in accordance with the established notification matrix.

12.11 A ‘help’ function shall be made readily available and easily accessible to players to provide gaming-related assistance.