Compliance in iGaming: Same Principles, Different Details

Compliance in iGaming has long gone beyond Know Your Customer (KYC) checks and anti-money laundering (AML). Regulators assess what the product itself can do: what data it collects, how long it retains it, how it presents it, and which components, such as the random number generator, have been certified. The principles behind these requirements are similar across most markets, but the details differ.

Common Standards, Local Details

🔵 GLI-19 is a widely used technical standard for interactive gaming systems, covering auditing, security controls, sensitive data handling, and components that determine game outcomes.

🔵 Specific rules within the same area vary by market: Britain permits slot advertising featuring animals and characters provided it is not primarily aimed at children, while Belgium bans characters in such advertising altogether.

🔵 In Germany, licensed operators must connect to two national systems: LUGAS, which monitors deposit limits and player activity across multiple operators, and OASIS, the register of self-excluded players.

🔵 An existing technical setup from one market cannot be transferred to another without a separate review of the requirements.

System Design Requirements

🔴 The platform maintains event logs: records of what happened, including who accessed an account, what settings changed, and when an error occurred.

🔴 A single game round is a sequence of connected steps: the bet, the outcome, the winnings, and the balance update. If the balance does not change as expected following a particular outcome, this sequence can be traced back to identify where the data diverged.

🔴 Regulators examine more than a security policy document; they examine the system itself: who accessed it and when, whether identity verification worked at login, and how a specific failure was handled.

When the Product Falls Short of Requirements

🔵 In Britain, operators must give players access to their account history. The platform must therefore be designed from the outset to collect this data, retain it for the required period, and display it in the required format.

🔵 If the team discovers this gap only after the product has been built, it must change the underlying data model and the logs that store this information, rather than simply adjust an existing feature.

🔵 This leads to further testing, certification delays, and higher launch costs.

Operator and Supplier Data in a Dispute

🔴 The operator holds player account data: deposits, withdrawals, and identity verification documents.

🔴 The game supplier holds data about the round itself: the bet placed, the outcome, the winnings credited, and technical logs of the game’s operation.

🔴 If a player disputes the outcome of a particular round, for example, believing that a technical failure caused an incorrect result, the issue can only be investigated by matching both sets of data.

🔴 Britain’s Gambling Commission requires the operator to remain accountable to the regulator, even if the failure occurred on the game supplier’s side, because the operator holds the licence.

Conclusion

Each requirement looks straightforward on its own: show players their account history, accurately reconstruct the events of a single round, and identify who is accountable when a contractor experiences a failure. But the data needed to do this is split between companies: the game supplier records the round and its outcome, while the operator records payments and the player’s identity. The operator is accountable to the regulator for both sets of data, even if the supplier caused the failure. Unless the parties agree in advance on who retains which data and for how long, the party required to respond may be missing essential information by the time a player disputes the outcome of a particular round.