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.
Protecting customer funds
Last updated: 7 December 2023
Show updates to this content
Formatting changes