What you need to tell us when you hold an operating licence

Assurance statements

What are assurance statements for?

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:

• be a relatively concise self-assessment of the risks to the licensing objectives posed by the business
• how well you are managing those risks
• where you need to improve and how you intend to do so.

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.

Actively manage your risk

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.

LCCP notifications

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.

Our LCCP notification requirements are contained in these parts of the Licence conditions and codes of practice:

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.

You need to tell us as soon as reasonably possible about any of these matters:

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

Notification of security breaches

Types of incidents

These are some common examples of incidents which may impact on the confidentiality of customer data or the availability of accounts:

• infection by viruses or malicious software
• ransomware infection
• theft or damage of computer equipment
• attacks by unauthorised outsiders resulting in network penetration
• unauthorised access (internal or external)
• unauthorised or accidental disclosure of customer data
• staff or third party misuse of customer data
• denial of services attacks
• customer impersonated fraud (identity theft).

When to report - severity of incident

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

The key considerations are:

• potential detriment that could be caused to the individuals affected
• volume of data that has been affected
• sensitivity of the data that has been affected
• financial loss to customers.

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.

Details to provide

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:

• the nature of the incident
• the location of the incident
• the services attacked or compromised
• when it first occurred
• when it was detected
• how it was detected and whether you are able to precisely identify the extent of the incident (how many customers affected, whether data was taken, what data and systems were affected)
• what mitigating action has been taken
• whether the root cause been identified
• whether any other parties such as ICO, police, external security consultants or customers been notified and the consideration given to not notifying some or all of the other parties
• what preventative action has been taken or will be taken to prevent future breaches.

How to notify us of an information security breach

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.

Protecting customer funds

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.

Reporting on your protection of customer funds

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

Remote operators who hold customer funds

In addition to the above requirements, if you are a remote (online) operator you must also:

• hold customer funds in a separate account
• report information about customer funds as part of your overall quarterly regulatory returns. This includes a breakdown of customer funds relating to customers in Great Britain and those relating to customers outside of Great Britain.

Remote game/software payment faults

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.

Types of faults and how to identify them

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:

• incorrect maths design or software flaw resulting in a different prize frequency or amount than intended/advertised
• implementation issue, such as a configuration parameter or build process, that causes the game to operate in a different way to the design or rules of the game
• software vulnerability exploited by a player, player hacks into the game
• incorrect prizes displayed.

Game faults can be identified in a variety of ways:

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

When to report

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.

Details to provide

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:

• the nature of the incident and how it was detected
• dates when the game/version was released, when the fault occurred, how long it was active for
• how the fault occurred and how it passed internal and external testing
• the amount of players affected, including the financial amount along with the calculations used to determine this
• difference in expected/actual RTP due to the fault
• if a B2B is reporting, how many B2Cs were offering the game and whether all were affected
• what remedial action has/will be taken - both to prevent a similar reoccurrence and to remedy any fairness issues for consumers.

Considerations regarding how to remedy a fault

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.

Calculating the financial amount involved

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

Approach A:

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.

Approach B:

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:

• You should not benefit from a fault. The effort of reimbursing funds should itself act as a disincentive for producing faulty games.
• The affected consumers should be treated fairly and with priority.
• Adequate disclosure accompanies any approach.

How to report

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:

• Key Event: Gaming system fault.