Written by: Kacper Osiewalski, Lead Backend Engineer, Digital Colliers
The 15% of gross gaming yield number lands differently once you sit with it. That's the ceiling the UK Gambling Commission can apply for the most serious AML breaches, and it's roughly the size of a full-year compliance budget at most mid-sized operators. You're not paying a fine in that scenario. You're paying next year's entire second line of defence, twice over, and losing the licence conversation on top.
The thing nobody says out loud is that this bill is already on your books. It's just been reclassified as "we'll fix the data later." Every week you run compliance out of spreadsheets and ad-hoc SQL, you're accruing interest on a debt that gets called in the day a regulator asks a question you can't answer in the shape they asked it.
Why the spreadsheet stack always loses the audit
A regulator's question is almost never "what does this customer look like now." It's "what did this customer look like on the afternoon of 14 March, what did you know about them at that moment, and what did your rules do with that knowledge."
Spreadsheets can't answer that. Neither can a live production database that's been mutated a thousand times since March. You end up reconstructing state from logs, and the reconstruction is always slightly wrong, and the regulator notices.
This is why roughly one in four UK-licensed operators fails to hit a satisfactory AML rating on first assessment. It's not that the compliance teams don't understand the rules. It's that the data underneath them can't reproduce yesterday on demand.
What an audit-ready data model actually looks like
The operators I see holding up under scrutiny in 2025 tend to have three things in common at the data layer.
- Point-in-time customer state. Every material fact about a player, KYC status, source-of-funds evidence, affordability band, self-exclusion flags, marketing consents, is stored as an event with a valid-from and valid-to timestamp. You can query "who was this customer at 14:32 on 14 March" and get one answer, deterministically, forever.
- A behavioural feature store. The signals your risk rules consume, rolling 30-day net deposits, session velocity, deposit-to-withdrawal ratios, time-of-day patterns, are computed once, versioned, and served to both the real-time decisioning path and the offline audit path from the same source. When RCI guidance expanded in 2024, the operators who already had this were shipping new triggers in weeks. The others are still shipping them.
- Transaction lineage. Every deposit, wager, bonus, and withdrawal carries a chain back to the decision that let it through. Which rule fired. Which version of that rule. Which feature values it saw. Which human, if any, reviewed it. This is the artefact that turns a two-week audit response into a two-hour one.
None of this is exotic. It's boring event-sourcing and boring feature engineering. The reason most operators don't have it is that it was never anyone's Q3 objective.
The affordability check is the forcing function
Once you're triggering interventions at £150 net deposits per rolling 30 days, you can't run that off nightly batch. You need the rolling window computed on every deposit, the customer's affordability evidence retrievable in the decisioning path, and the decision logged with enough context that a reviewer six months later can tell you why the customer was or wasn't asked for a payslip.
If your team is doing that in a stored procedure that got written in 2019 and touched by four people since, you know the risk. The rule fires correctly ninety-something percent of the time and the other few percent become the case file.
What the winning operators are budgeting for
Kindred publicly reported a £14M compliance-team cost in 2023. That's the running headcount number. It doesn't include the engineering spend to make that team's job possible, which at a serious operator is comparable and often larger.
The operators treating this as an engineering problem, not a headcount problem, are the ones who'll absorb the next wave of regulation without adding fifty people. The EU AI Act's high-risk obligations start applying from 2 December 2027, and any automated affordability or risk-scoring model you run will land inside that scope. The data model you build for AML this year is the same data model that keeps you defensible under the AI Act two years from now.
The 15% GGY number is a bill. You either pay it in engineering now or you pay it in enforcement later.