This box is not visible in the printed version.
This guidance summarises all of the types of data and information that you are required to tell us when you hold an operating licence.
Published: 17 May 2021
Last updated: 4 April 2022
This version was printed or saved on: 23 February 2024
Online version: https://www.gamblingcommission.gov.uk/licensees-and-businesses/guide/what-you-need-to-tell-us-when-you-hold-an-operating-licence
Overview: Your Licence conditions and codes of practice have various reporting requirements.
The information we collect from you helps to shape our decision making and our advice to government, therefore it is vital that you report on all the required data.
To help you ensure you are reporting on all the required areas we have created this reporting summary list.
While we will hold you to account for what you say in your statements, the main beneficiary of the statement is you, the operator.
Assurance statements are designed to improve the focus and accountability on the delivery of the licensing objectives by the boards, or equivalent senior leadership structures, of large gambling businesses.
The statements are intended to:
Assurance statements provide a means for your board to provide constructive challenge within the business on the effectiveness of your governance and risk management arrangements in facilitating positive consumer protection, addressing gambling-related harm and crime prevention measures.
We want you to embrace the challenges of the regulatory landscape by actively and effectively managing your risks and issues and to inform key business decisions. In turn, we are committed to a proportionate and risk-based regulatory regime.
If licensing objectives are the focal point of your decision making and they are supported by good governance, risk management and a high level of compliance your business is less likely to present a risk.
If this approach is successful, as we believe it will be, and over time more and more operators incorporate the licensing objectives into their corporate culture, the need for external regulatory scrutiny may decrease.
The precise governance arrangements of organisations will vary depending on the size, nature, and complexity of your operations or on the gambling services you provide. We will take this into account when we receive and review your assurance statements.
The previous examples provide indicative content of the assurance statement templates (the 2019 versions). The templates provide a structure to populate, as well as explanatory notes, and have been made available in a format that can be manipulated to enable tailoring of the layout as required. These templates are available to download at the bottom of the page.
An LCCP notification is a report to us about information we have asked for within our Licence conditions and codes of practice.
We expect you to work with us in an open and cooperative way and to inform us of anything we may need to be aware of.
Licence condition 11.1.1 (lotteries and local authorities)
Licence condition 15.1.1 (reporting suspicion of offences etc – non betting licences)
Licence condition 15.1.2 (reporting suspicion of offences etc – betting licences)
Licence condition 15.1.3 (reporting of systematic or organised money lending)
Licence condition 15.2.2 (other reportable events)
Licence condition 15.2.3 (other reportable events – money laundering, terrorist financing, etc)
Ordinary code provision 3.2.2, 3.2.4, 3.2.6, 3.2.8 (access to gambling by children and young persons)
Ordinary code provision 3.8.1 (money-lending between customers)
Ordinary code provision 8.1.1 (information requirements – ordinary code)
Ordinary code provision 8.1.2 (provision of information in respect of cheating)
All LCCP notifications are to be reported to us via the LCCP Notifications part of the eServices digital service (opens in a new tab).
There is also guidance for licence holders on submitting LCCP notifications available.
information about any known or suspected offences under the Gambling Act 2005 (opens in a new tab) or breaches of the LCCP
information that may lead us to consider making an order to voiding a bet under the Gambling Act 2005 section 336 (opens in a new tab)
cases of systematic, organised or substantial money lending between customers on gambling premises
material changes to your business’s arrangements for the protection of customer funds (see Licence condition 4)
changes of Alternative Dispute Resolution providers for the handling of customer disputes
if a group company not licensed by us advertises remote gambling to a new jurisdiction, or the Gross Gambling Yield (GGY) generated by that company exceeds set thresholds relative to group GGY
if your business has breached, or potentially breached requirements imposed by the Proceeds of Crime Act 2002 (Parts 7 and 8) (opens in a new tab) or the Terrorism Act 2000 (Part III) (opens in a new tab).
Changes of persons appointed as the officer responsible for your businesses’ compliance with the Money Laundering, Terrorist Financing and Transfer of Funds (Information on the Payer) Regulations 2017 (opens in a new tab) (opens in a new tab) (Regulation 21(1)(a) and 21(3))
details of any child or young person repeatedly attempting to gamble on premises restricted to adults
descriptions and copies of the rules (or changes to these) of any lottery to be promoted
confirmation from a qualifying auditor that the proceeds of any lottery exceeding £1 million in any calendar year are accounted for in a licensee’s annual accounts
any other matters that will have a material impact on your business or its ability to conduct licensed activities compliantly and consistently with the licensing objectives.
You must tell us about any security breach to your environment that could harm the confidentiality of customer data or prevent the licensee’s customers, staff, or legitimate users from accessing accounts for longer than 12 hours.
We use the information you report to monitor ongoing compliance and evaluate risk across the industry. If themes emerge that may be valuable to share (such as specific attacks targeting a number of businesses) this may be fed back to help you deal with emerging threats.
This licence condition applies to all operators and would include an information security breach for any operator who holds electronic records of customer information or gambling transactions.
These are some common examples of incidents which may impact on the confidentiality of customer data or the availability of accounts:
Minor incidents should not necessarily be reported. You can decide whether the severity of an incident means it should be reported. You should record and keep your evidence as to how the decision to report or not report was made by the appropriate PML (or in the case of a small scale operator the appropriate ‘qualified person’).
The Information Commissioner’s Office (ICO) provides guidance on when security breaches involving personal data should be reported to them and this should be considered when making a decision to report (both to the ICO and to us).
As a general rule, if a large volume of customer data has been affected, this should be reported. If a low volume has been affected but there is the potential for serious detriment or the data is highly sensitive, this should also be reported. Consideration should also be given to notifying affected customers where warranted. Refer again to the ICO guidance in this area.
The ICO is primarily interested in breaches of personal information, our interest has a wider remit such as unavailability of customer accounts for more than 24 hours or the loss, corruption or unauthorised modification of other critical gambling records such as player account balances, prizes or gambling transaction records.
You should provide sufficient information to describe the incident that has occurred, the severity of the incident and the volume of data affected.
Consider the following when submitting a report:
Breaches must be reported as key events as soon as reasonably practicable and in any event within five working days of the licensee becoming aware of the event’s occurrence.
Your terms and conditions must include information about your arrangements for protecting the customer funds you hold in the event of insolvency, the level of that protection and the method you use to achieve this.
This information must be made available at the point when a customer deposits money. Information must be available in a manner which requires customers to actively acknowledge that they have read it. Customers must not be allowed to use their funds for gambling until they have provided this confirmation.
You must inform customers of any changes to your arrangements for protecting customer funds before implementing those changes in your terms and conditions. You must also disclose the changes when a customer subsequently makes any deposits. Customers are required to acknowledge these changes.
Our Customer funds: segregation, disclosure to customers and reporting requirements guidance explains how you can comply with the requirements, including advice on what is classed as customer funds and how to apply the customer funds rating system.
It also includes examples of common errors we have identified during our compliance work.
If there are any changes in your protection of customer funds arrangements you must notify us. This is considered an ‘other reportable event’ and you can notify us via eServices (opens in a new tab).
In addition to the above requirements, if you are a remote (online) operator you must also:
Faulty games which affect the return to player impact the fair and open licensing objective and reduce consumer confidence in gambling.
This is relevant for you if you are a remote operator of random number generator (RNG) driven games, both business to consumer/player (B2C) and business to business (B2B) or a game hosting business.
It covers reportable events in relation to gambling system or game software faults and matters to be considered when you are seeking to remedy the outcomes of such faults.
Ordinary code provision 15.2.1 (Reporting key events - gambling facilities) requires the reporting as a key event of any game fault affecting the player return of the game. All events must be submitted via the eServices digital service (opens in a new tab).
We use information on faults to monitor ongoing compliance but also evaluate risk across the sector.
Of particular interest is identifying where in the design, development or deployment of games the fault occurred and whether the internal and external testing should be improved.
Should themes emerge that would be of value to share with the sector this may be fed back to help operators and test houses deal with common and emerging trends.
We are not concerned with issues that affect the user experience or playability of a game, issues that do not affect the fairness/return to player (RTP) of games should instead be reported under the existing 'any of matters of impact' event.
Whilst not exhaustive, the list below gives some common examples of faults which may impact on the RTP of remote games:
post implementation reviews of newly installed software identifies an error in the game’s configuration (if this is identified and corrected before the game was in live operation then reporting would not be required)
proactively identified by the operator during required game performance monitoring
investigation of player complaints or operator feedback results in a fault being discovered
updates to games or development of new games might result in developers discovering errors in the existing code base which affect RTP/fairness.
Confirmation of a game fault would usually coincide with an operator’s decision to disable the faulty game from operation. If the game was not disabled pending the outcome of the investigation it must be taken down whilst the fault is fixed and retested.
We understand that the time involved to fully ascertain all the particulars of an error can vary depending on the complexity, number of parties involved and the length of time the error existed. This should not hold up the reporting of the incident. You must provide as much information as is known at the time of reporting outlining any areas where further investigation is required to confirm more details.
All RTP faults should be reported. A number of ‘small’ faults may indicate a wider systematic issue within an operator’s or test house’s processes. This would not be identified if only ‘significant’ faults are reported.
A game under or overpayment issue, even an apparently minor one, represents a failure in design, build, testing or deployment of a gambling product and is therefore of interest to us.
Prompt identification, game deactivation and notification of faults increases confidence that you are properly monitoring your products to ensure they are operating in a fair and open way.
Detecting minor variances using your monitoring processes would demonstrate you have very effective processes in place.
You should provide sufficient information to describe the incident that has occurred, how it was identified, the cause, number of players/financial amount involved and the remedial action planned and performed.
When submitting your report include:
You should not benefit from a fault. You should endeavour to return the money to customers in a timely manner. If the individuals affected cannot be identified, you are encouraged to make efforts to repay the money to the group of consumers most likely to contain those affected. The money should be repaid in a way that would not incentivise additional gambling and is not based on a minimum-spend requirement or threshold.
We expect consumers to be informed of steps taken and the reason for this only after all the money has been returned, and not during this period. This will avoid operators being able to benefit through promotion or advertising, which is unacceptable.
If you cannot return the money to consumers in line with these aims, you should divest yourselves of the profits and this should be paid to a responsible gambling charity.
The first step is to establish the financial amount and number of players affected by the fault. The complexity of this will vary depending on the nature of the fault, for example a one-off jackpot failure will have one player and one amount involved. Whereas a more subtle design or game fault that reduces RTP might affect numerous prizes and players depending on how long it was in operation for.
The default and expected remedy is to directly reimburse the affected players.
The amount to reimburse would either be the exact amount (if the transactions are available to calculate) or if the transactions required are not available then the approximate amount based on the formula (turnover generated during the fault period times the defective RTP percent).
Calculate using the exact transactions. For example, if a jackpot should have paid X but it instead paid a quarter of X, the amount involved and players affected is easy to determine.
Where exact transactions or hits aren’t available, or are too difficult to calculate, then the following formula is typically used to calculate the theoretical difference between the expected and actual results.
For example, if a frequently occurring prize should have paid £500 but instead paid £100 or if a prize wasn’t being awarded at all due to a fault then determine how much that discrepancy reduces the overall RTP (each prize contributes an exact portion of the overall RTP).
If it was 0.5 percent then multiply that times the amount of turnover (£) which occurred under fault conditions. That is the amount of underpaid winnings.
We recognise that each game fault could be unique and how you deal with reimbursing players might change on a case by case basis. Whilst every attempt should be exhausted to directly reimburse affected players, if this is not possible any alternative should take into account the following principles:
Breaches must be reported as key events as soon as reasonably practicable and in any event within five working days of becoming aware of the event’s occurrence.
All key events are to be reported to us via the key event part of the eServices digital service (opens in a new tab).
You must select the following type when entering this key event on eServices: