Written by: Jakub Pietroszek, Partnership Manager, Digital Colliers
Your compliance team can tell you what a player looks like right now. Their risk band, their source-of-funds status, their affordability flag, their PEP screen result. What most teams can't tell you, without a painful SQL archaeology session, is what that same player looked like on the 14th of March last year. That gap is the shape of the problem.
The question that breaks your schema
Regulators don't ask about current state. They ask about historical state. When the UK Gambling Commission opens a file on you, the question is almost never "what's this player's risk band today." It's some version of: on the day this player deposited £4,200, what did you know about them, and what should you have done about it.
If your players table has a single row per player with columns that get overwritten every time KYC re-runs, you literally cannot answer that question. You can guess. You can reconstruct from event logs if you kept them. You can't query it. And roughly 1 in 4 UK-licensed operators fails to achieve a satisfactory AML rating on first assessment, which tells you how many teams are learning this the slow way.
Why KYC tables are almost always current-state
Most backends model customers as mutable objects. It's the obvious thing to do. The vendor pushes you a new risk score, you UPDATE players SET risk_band = .... The player uploads a new proof of address, you overwrite the old one. The affordability threshold changes, you re-evaluate everyone against the new rule.
That model works fine for operating the business. It falls apart the moment your obligations became temporal, which under the UK RCI guidance (in force since 31 August 2022, expanded through 2024) they clearly are. The regulator's question is not "is this player affordable today." It's "was this player affordable at the £150 net-deposit trigger in the rolling window ending on a specific Tuesday."
Current-state schemas can't answer temporal questions. Full stop.
How to model time-versioned KYC
The pattern isn't exotic. Accountants have used it forever. In database terms it's bi-temporal modelling, and the shape looks like this:
- Every KYC attribute gets an effective-from and effective-to timestamp.
- Updates never overwrite. They close the previous row and insert a new one.
- Every row also carries a knowledge-time: when did we learn this, versus when was it true.
- Queries take a date parameter.
AS OF '2024-03-14'is a first-class thing.
The bi-temporal split matters more than people expect. "When did the player become high-risk" and "when did we find out the player became high-risk" are different questions, and audits ask both. If a vendor tells you on day 30 that something was true on day 5, you need to record both dates.
Some teams bolt this on with an audit log table and call it done. That works until you need to actually reconstruct the player. Then you're writing a hundred-line recursive query every time a regulator asks a question, and you're one bug away from telling the regulator something that isn't true. Which, given UK AML penalties reach up to 15% of gross gaming yield for the most serious breaches, is not a great place to be improvising.
What the audit actually asks
The questions that break current-state schemas tend to cluster:
- What was this player's risk band on date X, and what evidence supported it.
- When did we first receive information that should have triggered a review.
- Between date A and date B, which players crossed the affordability threshold, and what did we do within 24 hours of each crossing.
- For any given rule change, which players were assessed under the old rule and which under the new one.
Every one of those questions is trivial against a bi-temporal model and nearly impossible against a mutable one.
The left-behind operators
Watch which operators are quietly rebuilding their customer data model in 2025 and 2026. It's the ones who've been through a real audit and discovered their £14M-a-year compliance function (Kindred publicly reported that figure for 2023) was spending most of its time reconstructing history from logs, spreadsheets, and vendor emails. The ones who haven't been through that audit yet still think their KYC data is fine because it's current.
Current is the wrong axis. The audit runs on time.