Compliance & safer gambling
The question is not whether the policy is right. It is whether the system can do the wrong thing.
Every control below is a code path with tests behind it. Where a control is enforced by a gate that every relevant operation passes through, we say so; where it depends on a vendor we have not connected, we say that instead.
RTS 12 — financial limits
Reductions are instant. Relaxations wait 24-hour. Removal is a relaxation.
That third sentence is the one that catches platforms out, and it is worth spelling out because it is a genuinely subtle failure.
- Multiple periods resolve to the lowest headroom. Where daily, weekly and monthly limits are all set, the binding ceiling is whichever leaves least room — not whichever was checked first.
- A parked change requires positive confirmation after the window. Silence leaves the stricter limit standing; the relaxation does not auto-apply.
- Self-exclusion cannot be shortened. A player cannot end their own exclusion early, and a one-day time-out cannot be used to unwind one.
The rest of the gate
What every money-moving operation passes through
Reality checks
Configurable session-elapsed prompts, with the setting owned per player and the interruption enforced by the platform rather than by the front end deciding to render it.
Self-exclusion
An exclusion register that gates play, deposits, marketing and account reactivation. It is checked at the gate, so a new feature does not need to remember to check it.
Affordability
Affordability signals and an Open Banking service seam for income and expenditure evidence, feeding thresholds that escalate rather than merely logging.
Markers of harm
Behavioural markers surfaced as safer-gambling interactions with a recorded outcome, so an intervention is an auditable event rather than a note in someone's inbox.
KYC policy & risk
A verification policy layer plus risk and fraud scoring that gate withdrawal and play, structured so the policy is configuration and the enforcement is not.
GDPR as code paths
Subject access export and erasure are operations, not a manual process. Erasure is refused while a self-exclusion is active, funds remain, or bets are pending — because the retention obligation outranks the deletion request in exactly those cases.
The regulatory packRegulatory return reporting is a service in the platform, not a spreadsheet somebody maintains. Ask to see the report generated live — a vendor whose regulatory return is assembled by hand every quarter will tell you a lot about the rest of the system in how they answer.
Where compliance depends on somebody else
The honest boundary
Not connected todayNo live KYC/AML vendor. The policy layer and the gates that consume it are built and tested; the identity-verification provider behind them is not connected. No GAMSTOP integration. The self-exclusion register is internal to the platform — the national scheme is a separate integration and a licensing prerequisite in Great Britain. No operating licence, no RTS test-house certification, no ISO/IEC 27001 audit. The platform is built to be put through those; it has not been through them.
None of that is unusual for a pre-launch platform, and all of it is ordinary integration work against seams that already exist and are tested. What would be unusual — and what we are not going to do — is describe a tested seam as if it were a signed vendor.
Bring your compliance lead, not just your CTO.
The limits state machine, the segmentation fail-safe and the erasure refusal conditions are the three things worth an hour of a compliance officer's time. We will walk all three in the code.