UKGC 要求博彩公司提交 RNG 报告，合同没写清谁做？持牌方全得背锅
博彩公司 RNG 测试报告由持牌运营方负责提交，但具体执行测试与生成报告的主体需依合同界定，否则无法形成可审计的合规责任链。
英国赌博委员会（UKGC）对 RNG 测试报告的提交要求是什么
英国赌博委员会要求持牌运营方必须主动将游戏及 RNG 测试结果上报，以此作为确认产品符合远程技术标准与公平性规格的硬性义务。
持有英国远程赌博牌照的运营方，必须主动将游戏及随机数生成器（RNG）的测试结果上报。这绝非可选项，而是维持牌照存续的硬性动作。其核心目的非常明确：确认新上线的游戏或重大更新后的版本，完全符合远程技术标准（RTS）及公平性规格[1]。
提交什么？年度审计与重大更新测试
监管机构要求的并非单次报告，而是一套持续更新的证据链。持牌方需定期提交游戏测试年度审计报告与安全审计报告[1]。这些文件必须通过 eServices 系统的 games register 渠道进行申报。重点在于证明 RNG 驱动的产品始终处于受控状态，任何代码变更都需重新验证。
这里存在一个常被外行误解的环节：许多人以为“年度审计”意味着一年只需跑一次测试，其余时间可以高枕无忧。实际上，UKGC 的逻辑是“持续合规”，年度审计只是对过去一年数据的总结性复核，而非唯一的触发点。一旦游戏在年中进行了涉及 RNG 逻辑的代码更新（哪怕只是修改了赔率权重），无论是否到年度节点，都必须立即触发新的专项测试并提交报告。如果运营方误以为只要过了年审日期，期间的所有更新都可以“打包”等到明年一起汇报，那将直接构成违规。真正的合规节奏是：任何代码变动即触发测试，测试完成即准备提交，年度审计则是将这些分散的报告串联成完整的证据闭环。
如何证明？统计分析与非自适应原则
光有数据不够，必须通过特定的逻辑来解释数据。RTS 7A 标准要求随机结果必须达到“可接受地随机”[2]。这意味着系统不能带有补偿机制，禁止出现为了平衡输赢而调整概率的自适应行为。合规的证明方式是利用统计分析以及行业通常认可的测试方法，量化随机性的分布特征[2]。
这种要求揭示了技术责任的双重结构：监管层面对持牌运营主体设定了提交义务，但技术实现层面却分散在平台商、供应商和实验室之间[1][2]。如果合同未明确界定谁负责生成报告、谁触发测试、谁保管日志，那么所谓的“合规就绪”只是采购时的一个承诺，无法转化为可审计的责任链条[3]。
为什么“合规就绪”不等于持牌方完成了提交义务
合规就绪仅指技术层面达标，不等于持牌方完成提交义务，后者必须通过官方渠道持续证明随机结果满足统计分析与非自适应行为标准。
英国赌博委员会要求牌照持有人通过 eServices 的 games register 提交游戏与 RNG 测试结果，目的是确认新游戏或重大更新符合远程技术标准（RTS），并验证 RNG 驱动产品是否满足公平性规格[1]。这种提交不是形式上的备案，而是对随机结果是否达到“可接受地随机”的持续证明，且必须包含统计分析与非自适应行为的验证[2]。
供应商承诺的局限性
许多平台商在宣传中强调拥有”compliance-ready infrastructure”（合规就绪的基础设施）[3]。这听起来像是已经铺好了路，但仔细拆解会发现，它仅仅代表供应商具备准备合规材料的能力，而非已经完成了具体动作。这种基础设施无法单独证明某一款具体游戏已经通过了 RNG 测试，也无法证实某次重大更新后的报告已正式提交给监管机构[3][1]。
这就好比一家餐厅宣称自己拥有全套卫生认证厨房，但这不代表每一道端上桌的菜都经过了当局的抽检。监管页面确立了持牌方的最终提交义务，却未界定具体操作主体——前台、后台、账户还是 RNG 模块，究竟由平台商、游戏供应商还是独立实验室负责[1][2]。若合同未明确报告生成者、测试触发条件及日志保管期限，所谓的“合规就绪”就只是采购入口，无法转化为可审计的责任链。
| 维度 | 供应商的“合规就绪”声明 | 持牌方实际需要的证据 |
|---|---|---|
| 覆盖范围 | 通用基础设施能力 | 特定游戏版本的具体测试数据 |
| 证明对象 | 具备准备报告的潜力 | 报告已生成并成功提交至 UKGC |
| 责任归属 | 技术实现层面的准备 | 法律层面的最终提交义务 |
| 审计价值 | 无法直接作为合规凭证 | 唯一可被监管机构采信的依据 |
| 风险点 | 缺乏具体项目关联 | 缺失即视为违规 |
持牌方不能仅凭采购平台的“合规声明”免除向 UKGC 提交数据的法律责任。技术责任呈现出双重结构：监管责任落在运营主体，而技术实现可能分散在多方之间[1][2]。一旦合同模糊，供应商的承诺就无法填补具体的执行缺口。
实操建议：建立“变更即触发”的自动化清单
针对上述责任模糊地带，建议持牌方在签署白标协议时，强制引入一份名为《RNG 变更与测试触发清单》的附件，而非仅仅依赖通用的服务条款。这份清单不应只写“供应商负责测试”，而应明确定义三个具体动作的自动触发机制：第一，当游戏供应商发布新版本包（Build ID）时，系统必须自动向持牌方发送包含哈希值的变更通知；第二，清单需规定从收到通知到完成第三方测试的“最长等待窗口期”（例如 5 个工作日），超时未提交测试报告即视为违约；第三，明确日志存储的物理位置，要求供应商开放只读权限接口，允许持牌方随时调取原始测试日志，而非仅查看摘要。通过这三个步骤，将原本模糊的“合作默契”转化为具有法律效力的“自动化合规流程”，确保在审计员介入前，责任链条不会断裂。
博彩公司 RNG 测试报告谁提交？拆解技术责任的双重结构
监管文件虽规定牌照持有者承担提交义务，但实际测试与报告生成分散于平台商、供应商及实验室，若合同未明确归属则导致责任链断裂。
监管文件只要求牌照持有者提交结果，却没写明具体由谁动手[1]。这种模糊让“合规就绪”变成了一句空话。英国赌博委员会（UKGC）把提交义务压在了持牌运营主体肩上，但生成报告、执行测试、保管日志的技术动作，往往分散在平台商、游戏供应商和独立实验室手里[2]。当合同没把这些动作的归属写死，责任链就断了。
责任链条中的关键缺口
很多白标方案宣传自己“合规就绪”，但这只是供应商的单方面承诺[3]。它无法证明你的某款新游戏通过了 RNG 测试，也无法确认重大更新后的数据已按 RTS 7A 标准提交[1]。RTS 7A 明确要求随机数必须达到“可接受地随机”，且禁止自适应补偿行为，这需要持续的统计分析和非适应性验证[2]。如果合同里没规定谁负责触发测试、谁在版本变更后第一时间通知、以及故障发生时的日志权限归谁，一旦审计员来查，持牌方就是那个背锅的人。
| 环节 | 常见误区 | 实际风险点 |
|---|---|---|
| 报告生成 | 默认供应商自动完成 | 若未约定格式与提交人，持牌方需补交 |
| 版本变更 | 视为内部技术调整 | 未触发重新测试即上线，违反 RTS 7A |
| 日志保管 | 假设云端自动存档 | 缺失故障处置权限导致无法追溯源头 |
| 测试触发 | 仅依赖年度审计 | 重大更新未单独测试即构成违规 |
表格里的每一行都是潜在的审计雷区。比如版本变更，如果只是小修小改，供应商可能懒得通知；但在 UKGC 眼里，任何影响 RNG 逻辑的改动都算“重大更新”，必须重新测试并提交结果[1]。没有明确的触发机制，这个漏洞就会一直存在。
白标模式下的特殊风险
在白标架构里，前台界面、后台管理、钱包系统与 RNG 核心模块往往分属不同控制方。平台商管代码，供应商管算法，运营商管牌照。这种物理隔离放大了合同模糊带来的后果。所谓的“合规就绪”如果缺乏具体的交付清单，就只是一个采购入口，而不是一个可审计的责任闭环[3]。你买到的是一套能跑通的系统，却不一定是一份能过审的合规证据。
真正的合规不是看供应商说了什么，而是看合同里有没有明确：报告由谁生成、测试何时触发、日志存哪里、故障谁处理。只有把这些细节从“默认状态”变成“契约条款”，持牌方才能把监管责任和技术实现真正拼合在一起。否则，无论系统多先进，面对审计时依然是一笔烂账。
FAQ：关于 RNG 测试与 UKGC 提交的常见问题
Q: 如果游戏供应商声称他们的系统是“合规就绪”的，我还需要自己提交报告吗？ A: 是的。UKGC 明确规定，最终的提交义务在于持牌运营商。供应商的“就绪”声明仅表示其具备生成报告的技术能力，并不能替代运营商向监管机构履行法定的提交动作。
Q: 什么样的游戏更新被视为“重大更新”需要重新测试？ A: 根据 RTS 7A 标准，任何可能影响随机数生成逻辑、赔率结构或输出分布的代码变更，都被视为重大更新。即使是微小的底层修改，只要涉及 RNG 核心，都必须重新测试并提交新的测试报告。
Q: 如果合同中没有明确指定谁来提交报告，出了事谁负责？ A: 在法律层面，牌照持有人（持牌方）承担最终责任。如果合同模糊导致无人提交或提交错误，监管机构会直接追究持牌方的责任，因为这是持牌方未能建立有效审计链条的后果。
参考来源
- Gaming machine and remote games information requirements · https://www.gamblingcommission.gov.uk/licensees-and-businesses/guide/gaming-machine-and-remote-games-information-requirements（A级）
- Remote gambling and software technical standards (RTS) - RTS 7 – Generation of random outcomes · https://www.gamblingcommission.gov.uk/standards/remote-gambling-and-software-technical-standards/rts-7-generation-of-random-outcomes（A级）
- Turnkey Sweepstakes Platform | Metablock iGaming · https://metablockigaming.com/turnkey-sweepstakes-platform（B级）