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.
From April 2018 ordinary code provision 15.2.1 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 portal or email.
Until April 2018 the related ordinary code provision is 8.1.1.
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 not be reported.
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
We do not expect every suspected game fault to be reported to us. However once a fault, resulting in an under or overpaying game is confirmed, reporting would be required within five days.
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
The primary objective should be to protect consumers, which includes making sure the players affected are treated fairly and with penalising disincentives for the provision of unfair games.
The overarching aim of any remedy is to ensure the operator does not benefit from the fault, and the affected players are treated with priority in correcting the fault.
Where an issue has resulted in overpayment to players, operators will need to refer to their own rules and determine whether or not to pursue reclaiming any extra payments based on the circumstances of each case. For that reason the following is to be considered in a player underpayment context.
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%).
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% 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.
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.
Key events relating to game faults should be reported through our online returns system or via email at firstname.lastname@example.org
The new specific key event will go live in April 2018, in the meantime select ‘Other - Matter of impact’ as the category of LCCP notification.