研究档案 / 合规与风险观察
别把MGA名单当证据：马耳他B2B牌照只是“入场券”，不是责任判决书
别把MGA名单当证据：马耳他B2B牌照只是“入场券”，不是责任判决书
马耳他B2B牌照名单仅能作为特定时间点的核查线索，无法单独证明主体实际承担的工作、合同关系或其他司法辖区的许可状况。
为什么名单不等于实际业务全景
MGA登记页虽列出获批游戏类型和服务商，但无法反映主体实际业务全景，也不能据此推断上下游合同关系或实时经营状态。
打开马耳他博彩管理局（MGA）的许可登记页，你很容易看到类似 MGA/B2B/246/2013 这样的编号记录。页面列出了获批的游戏类型和服务提供商，看起来像是一份权威的名册。很多人据此认为，只要名字在列，就代表该主体正在实际承担业务，甚至能推断出上下游的合同关系。这种直觉往往导致误判。
这份登记本质上是静态快照，而非动态的业务流水账。它仅记录了特定时间点的合规状态，却缺失了关键的过程细节[1]。监管信息无法自动还原“谁在真正干活”的场景。例如，集团牌照的名义持有人可能只负责缴纳费用、提交报告，而具体的产品运营和交付仍需单独获批[2]。
这就好比餐厅营业执照上写了主厨的名字，不代表当天站在灶台前炒菜的人一定是他。在博彩供应链中，软件供应、服务器托管与面向客户的运营，在概念上完全可以由不同主体分担[3]。名单上的存在，只能证明该主体在某个时刻拥有某种资格，却不能证明其此刻是否在执行某项具体工作，也无法佐证彼此间是否存在实质性的合同约束。
更深层的问题在于，许多争议其实源于对“持有牌照”这一概念的语境错位。人们常将“获得准入资格”等同于“履行经营义务”，但这忽略了监管逻辑中的分层设计：MGA 发放的是“入场券”，而非“岗位说明书”。一家公司可能因为技术架构调整或市场策略变化，在拥有 B2B 牌照的情况下，将实际的数据处理权完全外包给第三方，自己仅保留名义上的持牌身份。此时，名单依然显示该公司在列，但其实际承担的法律责任边界已发生根本性转移。若仅凭名单判断，极易将“名义责任”与“实质运营”混淆。
更关键的是，这份名单的效力范围仅限于马耳他司法辖区。它完全无法证明名单中的主体在其他国家或地区是否持有相应许可。若试图用这一张表来推导全球范围内的责任归属或业务全貌，显然缺乏依据。因此，MGA 许可登记页应当被视为一条核查线索，而非定论式的证据。
从托管案例看：名单能否直接推导职责
即便监管指引提及托管场景将角色拆分，名单中出现不同主体也不代表能自动认定各自职责，必须结合具体事实细节分析。
监管指引里曾举过一个具体的托管例子：软件企业把游戏放在自有服务器上，再由另一家运营方的网站向客户开放访问。[3] 这个场景让很多人产生联想——既然角色可以拆开，那是不是意味着只要看到名单里有不同主体，就能自动认定谁负责什么？这种推论看似顺理成章，实则忽略了关键细节。
那个例子确实揭示了一个事实：供应、托管与运营在概念上是可以由不同主体承担的。[3] 但这只是展示了“可能性”，而非“普遍性”。单个案例无法证明整个行业通常如何分工，更没有交代合同义务、数据处理责任或故障处置流程等核心信息。[3] 就像你看到一辆车停在路边，不能仅凭此就断定车主是否拥有驾驶资格，更不能推断这辆车是否正在执行某项特定任务。
当我们面对 MGA 许可登记页时，情况更为复杂。页面列出了如 MGA/B2B/246/2013 这样的 B2B Critical Supply Licence 记录，并标注了获批的游戏类型及服务提供商。[1] 这份名单可以作为特定时间点的核查线索，却绝不能单独用来证明名单中每一主体实际承担的工作、彼此之间的合同关系，或是其在其他司法辖区的许可状况。[1]
为了进一步打破这种线性思维，我们可以引入一个更具现实参考价值的视角：在当前的云原生架构趋势下，基础设施的“物理归属”与“法律归属”正日益分离。过去，我们习惯通过查看服务器机房位置或硬件所有权来判断责任方；但现在，一家马耳他持牌的 B2B 供应商可能将其所有游戏实例部署在 AWS 或 Azure 的全球节点上，而数据控制权则通过 API 网关被另一家位于塞浦路斯的运营实体实时调用。在这种架构下，MGA 名单上显示的仅仅是“持牌方”，而真正的“数据控制者”和“风险承担者”可能隐藏在复杂的云服务协议背后。如果调查者仍执着于名单上的公司名称去推导责任链条，就会陷入“找错人”的困境。
MGA 的游戏提供商与后台服务指引虽然将特定软件的供应与管理纳入关键博彩供应范围，且提到集团牌照名义持有人需承担主要缴费及报告责任，但这些内容往往以摘要形式呈现。[2] 由于现有摘录不完整，它们只能说明监管文本会以活动和责任分类，却无法替代对完整现行规则及具体牌照条件的核对。[2]
因此，单纯依赖产品描述或简单的名单关联来推定具体的职责归属，存在巨大的逻辑漏洞。真正的合规判断，必须建立在完整的合同条款、技术架构文档以及跨辖区的许可验证之上。
如何正确利用马耳他B2B牌照名单：从线索到实证
正确利用MGA名单需将其视为初步筛查工具而非最终判决，构建完整合规证据链还需引入更多维度的核查动作以验证实际责任。
把马耳他博彩管理局（MGA）的许可登记页当成最终判决，是许多合规调查中最常见的误判。这份名单确实列出了获批的游戏类型和服务提供商[1]，但它本质上只是一张特定时间点的快照。它无法证明名单上的主体实际承担了什么工作，彼此间是否存在合同关系，也无法反映其在其他司法辖区的许可状况。因此，必须将 MGA 名单视为初步筛查工具，而非最终法律证据。要构建完整的合规证据链，你需要引入更多维度的核查动作。
构建完整的合规证据链
仅凭一份注册记录无法还原真实的业务全貌。监管指引虽然指出集团牌照名义持有人需承担主要缴费及报告责任，且游戏软件的供应与管理属于关键博彩供应范围，但这只是框架性的分类说明[2]。现有摘录并不完整，不能替代对具体牌照条件和现行规则的逐条核对。当面对复杂的托管案例时，软件企业可能在自有服务器运行游戏，再由另一运营方对外提供服务[3]。这种架构下，概念上的分离并不意味着责任的自动转移。
为了厘清真相，你需要收集以下关键文件来填补名单留下的空白：
- 服务合同与 SLA：明确界定各方在数据处理、故障处置及客户支持中的具体义务。
- 技术架构数据流图：直观展示资金、用户数据及游戏逻辑在不同服务器间的流转路径。
- 多辖区合规确认函：验证该主体在其他司法管辖区是否持有有效牌照。
- 实时监管状态监控：由于监管状态可能随时间变化，静态名单无法覆盖动态风险。
| 核查维度 | MGA 名单提供的信息 | 必须补充的实证材料 |
|---|---|---|
| 业务范围 | 获批的游戏类型列表 | 具体的产品垂直类别及事先获批证明 |
| 责任归属 | 集团名义持有人的缴费义务 | 详细的服务合同与责任划分条款 |
| 技术架构 | 无相关技术细节 | 服务器托管位置及数据流向图 |
| 跨区状态 | 仅限马耳他辖区 | 其他司法辖区的有效许可证明 |
实操建议：在获取 MGA 名单后，不要止步于名称匹配。请执行“反向穿透”步骤：找到名单中目标主体的官方网站或公开披露的技术白皮书，重点查找其“合作伙伴”或“基础设施提供商”章节。如果对方宣称使用第三方云服务商（如 AWS, Google Cloud），立即要求对方提供该云服务的区域配置截图及数据驻留声明。这一步能迅速验证其实际运营模式是否与名单上的“传统持牌商”形象相符，从而发现潜在的架构隔离或责任转嫁风险。
名单只能告诉你“谁在这里”，却无法解释“他们做了什么”。只有将合同审查、技术分析及多辖区确认结合起来，才能形成有说服力的合规判断。
FAQ：关于马耳他B2B牌照常见疑问
Q: 我能在MGA官网上查到所有正在运营的公司吗？ A: 官网提供的是特定时间点的许可状态快照，并非实时业务流水。有些公司可能已暂停业务但未注销，或者正在申请续期，名单未必能反映当下的实际运营情况。
Q: 如果一家公司在名单上，是否代表它在所有国家都合法？ A: 绝对不是。马耳他牌照仅在马耳他司法辖区内有效。若要开展全球业务，必须逐一核实目标市场的具体许可要求，不能简单套用马耳他的名单作为全球通行证。
Q: 仅凭MGA名单能作为法庭证据吗？ A: 在大多数司法实践中，单纯的名单记录不足以作为判定法律责任的直接证据。法院通常需要结合合同、技术日志、资金流向等多重证据链来综合认定。
参考来源
- Mga · https://authorisation.mga.org.mt/verification.aspx?lang=EN&company=47a747e0-8923-4414-9bb6-0be487aa690f&details=1（S级）
- Game Providers and Back Office - Malta Gaming Authority · https://www.mga.org.mt/licensee-hub/applications/b2b-licences/game-providers-and-back-office/（S级）
- Non-remote gambling software licence · https://www.gamblingcommission.gov.uk/licensees-and-businesses/licences-and-fees/non-remote-gambling-software-licence（S级）