{"id":109,"date":"2026-09-25T09:44:57","date_gmt":"2026-09-25T09:44:57","guid":{"rendered":"https:\/\/blog.playpatrol.app\/?post_type=igaming_news&p=109"},"modified":"2026-09-25T11:57:08","modified_gmt":"2026-09-25T11:57:08","slug":"game-fault-reporting","status":"publish","type":"igaming_news","link":"https:\/\/blog.playpatrol.app\/news\/game-fault-reporting\/","title":{"rendered":"What UKGC asks after a game fault"},"content":{"rendered":"\n

Game fault reporting in the UK asks how a fault was detected and how long it was active. What UKGC expects, and how to have the answer before it breaks.<\/p>\n\n\n\n

Game fault reporting: how long was your game broken?<\/strong><\/h2>\n\n\n\n

Picture a Friday afternoon at a UK-licensed operator. A player writes to support: in a popular slot, the trigger symbols landed, but the free spins round never started. Support passes it on. By Monday, the provider confirms it. The game has a fault, and players have been losing a feature they had already won.<\/p>\n\n\n\n

Now the compliance lead has five working days and a report to file. The regulator’s guidance lists what that report must cover, and two of the first questions are simple to read and hard to answer.<\/p>\n\n\n\n

How was the fault detected? And how long was it active?<\/strong><\/h2>\n\n\n\n

The honest answer to the first one is “a player told us.” For the second one, most teams have no answer at all. This article walks through what game fault reporting to the UK Gambling Commission actually asks for, why most operators and providers cannot answer it well, and what has to be in place before the next fault, not after it.<\/p>\n\n\n\n

This article summarises public UKGC guidance. It is not legal advice<\/em><\/p>\n\n\n\n

What UKGC asks after a game fault<\/strong><\/h2>\n\n\n\n

The Gambling Commission’s guidance on\u00a0remote game and software faults<\/a>\u00a0is short and specific. Any game fault that affects the player return of a game must be reported as a key event, through eServices, as a “Gaming system fault.” The deadline is\u00a0“as soon as reasonably practicable and in any event within five working days”<\/strong>\u00a0of becoming aware of it.<\/p>\n\n\n\n

The report is expected to include: <\/p>\n\n\n\n

What the guidance asks for<\/strong><\/td>What you need to answer it<\/strong><\/td><\/tr>
The nature of the incident and how it was detected<\/td>A record of who or what found it first<\/td><\/tr>
When the game or version was released<\/td>Release history per game<\/td><\/tr>
When the fault occurred and how long it was active<\/td>A timestamp before the fault and a timestamp of the first failure<\/td><\/tr>
How the fault occurred and how it passed internal and external testing<\/td>Root cause, plus an honest view of what testing covered<\/td><\/tr>
How many players were affected, with the financial amount and the calculation<\/td>Session and transaction data for the whole window<\/td><\/tr>
The difference between expected and actual RTP<\/td>Game performance data<\/td><\/tr>
For a B2B supplier: how many B2Cs offered the game, and whether all were affected<\/td>A view of the game on every operator that offers it<\/td><\/tr>
What remedial action has been or will be taken<\/td>The fix, and how you will catch it next time<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The default remedy is just as clear: reimburse the affected players directly<\/strong>. In the regulator’s words, “You should not benefit from a fault.”<\/p>\n\n\n\n

One scope note matters. This duty covers faults that change what a game pays. A game that simply fails to load is a different problem, handled under other obligations. The rest of this article is about the faults that land in this report.<\/p>\n\n\n\n

Most teams can answer only one of these questions<\/strong><\/h3>\n\n\n\n

Look at that table again and ask a practical question. Which rows can a typical operator<\/a> fill in from the data it already has on Monday morning?<\/p>\n\n\n\n

Transaction data covers the player numbers and the amounts. The provider can explain the root cause. But the rows about detection and duration depend on something most teams never recorded: what the game looked like to a player, on that site, before anyone complained<\/strong>.<\/p>\n\n\n\n

The reason is structural. The provider sees its own game server. The operator sees its own site and its own wallet. Between them sit the integration, the configuration for each market and the frontend on each device. A fault can start in any of those layers, and each side’s logs show only its own half.<\/p>\n\n\n\n

So the start of the fault window is usually set by guesswork. It becomes “since the last release,” or “since the last time someone looked.” And the B2B row is harder still. A provider that cannot see its game on every operator cannot say which B2Cs were affected. It can only say which ones complained.<\/p>\n\n\n\n

How a player complaint turns into a longer fault<\/strong><\/h2>\n\n\n\n

The regulator’s guidance names the ways a fault gets found: post-implementation reviews, the operator’s own monitoring, and player complaints. It is also open about which of these it prefers. “Detecting minor variances using your monitoring processes would demonstrate you have very effective processes in place.”<\/strong> And: “Prompt identification, game deactivation and notification of faults increases confidence that you are properly monitoring your products.”<\/p>\n\n\n\n

A fault found through a complaint is, by definition, a fault that players found first. And the cost of that grows with every day it stays live.<\/p>\n\n\n\n

Take an illustrative example and swap in your own figures. A bonus round fails to start in one market. 1,200 sessions a day<\/strong> hit the fault, and the average value of the lost feature is \u20ac1.50<\/strong> per session. That is \u20ac1,800 a day<\/strong> to reimburse.<\/p>\n\n\n\n

Faund by<\/td>Days active<\/td>Illustrative amount to reimburse<\/td><\/tr>
Monitoring, on the first day<\/td>1<\/td>about \u20ac1,800<\/td><\/tr>
A player complaint, on day 9<\/td>9<\/td>about \u20ac16,200<\/td><\/tr>
A regulator question, on day 30<\/td>30<\/td>about \u20ac54,000<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The reimbursement is only the visible part. Every extra day also adds more players to contact, more transactions to recalculate, and more engineering hours spent proving which side caused the fault. And it weakens the one thing the report is meant to show: that the business is watching its own games.<\/p>\n\n\n\n

A manual check is not a detection process<\/strong><\/h2>\n\n\n\n

In June 2026, the Commission settled with a slot supplier for \u00a3122,835<\/strong>. Sixteen of its games spun faster than the 2.5-second minimum, some of them for years. The root cause, as the regulator’s notice<\/a> put it, was the testing method. The supplier had been relying on “a manual stopwatch to measure the speed of their games.” The Commission called that unacceptable, “with all the technological resources available to an online gambling business.”<\/p>\n\n\n\n

The lesson for game fault reporting is not about spin speed. It is about method. A check done by hand, from time to time, leaves no reliable record of when a problem started. It also cannot scale to every game, every operator and every market.<\/p>\n\n\n\n

Screen-level failures are sanctioned too. In October 2025, an operator paid a \u00a3240,000 penalty<\/a> because some of its games did not show players their net position and celebrated returns that were equal to or lower than the stake. These were problems a player could see on the screen, and the regulator treated them as failures to meet its technical standards.<\/p>\n\n\n\n

Both cases point the same way. The regulator expects a business to know what its games do in front of players, and to know it before a player or an investigator does.<\/p>\n\n\n\n

What a fault record needs before the fault happens<\/strong><\/h2>\n\n\n\n

Before looking at any tool, including PlayPatrol, it helps to set out what a record needs so that it can answer the report’s questions. Five conditions cover most of it:<\/p>\n\n\n\n