
法人主体与资金结构:跨境支付架构真正的地基
原创2026/7/2大约 9 分钟
法人主体与资金结构:跨境支付架构真正的地基
商户和谁签约、钱放在哪里、收入由谁确认,会直接决定产品承诺、账务模型与合规定性。
为什么值得讨论
主体结构不是公司注册层面的附录,而是所有订单、账户、申报、税务和资金责任的前置输入。本文建立这些映射关系。
适合读者:创始团队、支付产品、法务合规、财务和平台架构负责人。
时效与责任边界
本文根据截至 2026-07-02 的行业经验与公开规则整理。监管、牌照、税务和数据要求会持续变化,请在实际决策前使用目标辖区权威资料并咨询专业顾问。本文仅作技术与产品研究,不构成法律或合规建议。
1. 为什么主体结构是地基
同一个产品功能,在不同主体结构下的合规定性完全不同:
| 问题 | 由主体结构决定 |
|---|---|
| 商户协议怎么写 | 签约主体是谁、承担什么义务、适用哪国法律 |
| 平台是否"无牌经营" | 平台角色是技术服务商还是资金链条参与方(见 §2) |
| Safeguarding 义务归谁 | 客户资金落在哪个主体名下的哪个账户 |
| 税怎么交 | 收入确认主体、商户税务属地(10 篇:计费引擎设计:复杂费率如何准确、可解释、可运营 §5) |
| 申报谁来报 | 各辖区申报义务主体(11 篇:申报系统设计:让监管数据从交易源头就正确) |
| 账套怎么建 | 一主体一账簿(06 篇:金融账务核心:多币种账户与复式记账怎么设计 legal_entity 维度) |
2. 平台角色定性(一期"借牌"模式的红线)
2.1 两种角色的分界
| 角色 | 定义 | 合规含义 |
|---|---|---|
| A. 技术服务商(TSP) | 只提供系统与信息服务,资金指令的法律发起与执行均在持牌合作方与商户之间完成 | 不需支付牌照,但不得实质触碰资金、不得对商户做资金承诺 |
| B. 资金链条参与方 | 以自己名义持有客户资金/发起资金指令/对商户承担兑付义务 | 必须持牌;无牌即"无证经营支付业务",各辖区均属高压线 |
2.2 定性判断的实质重于形式
监管看实质不看合同标签。以下任一情形成立,即倾向被定性为 B:
- 客户资金进入平台自有主体名下账户(哪怕"过一下");
- 平台对商户承诺余额兑付、汇率与到账时效(以自己名义而非转述合作方);
- 平台实质决定资金流向(路由、换汇时点)且合作方仅机械执行;
- 对客计费以平台名义收取资金类费用(而非技术服务费)。
2.3 一期借牌模式的合规设计要求
- 协议三方结构:商户 ↔ 持牌合作方(资金服务协议)+ 商户 ↔ 平台(技术/信息服务协议)+ 平台 ↔ 合作方(系统服务与获客合作协议),三份协议的权义划分互相咬合、不留空隙;
- 对客话术与页面披露:Portal 与 API 文档中资金服务的提供方标识必须是持牌方(12 篇:API 与商户体验:把复杂金融能力做成简单产品需按此校对文案),平台品牌可做界面主体但不得模糊资金服务主体;
- 红线自查清单:上线前逐条对照 §2.2,由外部律师出具定性意见——这份意见同时是与银行/合作方尽调时的关键材料;
- 演进路径:随 05 篇:跨境支付合规风控:从 KYB 到交易监控牌照路线图推进,平台主体逐步从 A 转为 B(自持牌辖区内),转换期的商户协议迁移方案要提前设计(存量商户重签是大工程,协议里预留变更条款)。
3. 参考主体拓扑
HoldCo(控股,开曼/新加坡,融资与股权载体)
├─ HK OpCo(香港运营主体)
│ · 一期对外签约主体候选(技术服务)/二期 MSO 持牌主体
│ · 资金枢纽账户候选([04 篇:换汇与头寸管理:定价、敞口与流动性的系统解法](/posts/payments/fx-and-treasury/) §5 选址联动)
├─ SG OpCo(新加坡,视 MPI 路线设立)
├─ CN TechCo(境内科技服务公司,WFOE)
│ · 研发与境内运营;不触碰资金
│ · 与境内结汇合作方的系统对接主体
└─ 未来:EU EMI 主体 / US 持牌主体(三期)设计原则:
- 资金主体与研发主体分离:境内公司只做技术,资金能力全部在境外持牌/借牌主体——既是合规要求也是融资结构的常规安排;
- 一主体一账簿:每个法人独立账套(06 篇:金融账务核心:多币种账户与复式记账怎么设计),跨主体往来必须走公司间协议与转移定价,禁止"内部账随便划";
- 牌照落在哪,主体就在哪:主体设立顺序跟随 05 篇:跨境支付合规风控:从 KYB 到交易监控牌照路线图,不提前设空壳(维护成本与实质经营要求)。
4. 三个关键映射(系统落地)
商户 ──签约──► 签约主体(contracting_entity)
交易 ──归属──► 资金持有主体(funds_entity:钱实际在谁名下)
收入 ──确认──► 收入确认主体(revenue_entity:费用开票方)- 三者可以不同(一期常态:签约=HK OpCo,资金=合作方,收入=HK OpCo 技术服务费),订单与账务模型都要能表达;
- 06 篇:金融账务核心:多币种账户与复式记账怎么设计
legal_entity维度按此落地:LedgerAccount、Journal、FeeItem(10 篇:计费引擎设计:复杂费率如何准确、可解释、可运营)均携带主体标识; - 10 篇:计费引擎设计:复杂费率如何准确、可解释、可运营税务属地 = f(签约主体, 商户所在地, 服务类型),映射表由财务维护。
5. 跨主体资金与利润流转
| 流转 | 形式 | 要点 |
|---|---|---|
| 收入分配 | 公司间服务协议(境内研发服务费、境外技术授权费) | 转移定价文档化(TP Documentation),年度基准测试 |
| 资本注入 | HoldCo → 各 OpCo 增资/股东贷款 | 用于牌照资本金要求与营运资金(19 篇:财务模型与资金规划:单位经济、垫资与压力测试) |
| 头寸调拨 | 仅在自有资金池内(04 篇:换汇与头寸管理:定价、敞口与流动性的系统解法 §5.2 隔离约束) | 客户资金永不跨主体调拨,除非两端均为该客户提供服务的持牌主体且协议允许 |
| 亏损与补贴 | 初期境外主体亏损由 HoldCo 覆盖 | 避免境内主体向境外输送利益的外汇违规形态 |
6. Safeguarding 义务归属
- 义务跟随牌照:哪个主体持牌服务商户,哪个主体承担该辖区 Safeguarding(隔离账户、审计报告、监管报表——11 篇:申报系统设计:让监管数据从交易源头就正确 §1.2);
- 一期借牌模式下义务在合作方,但平台的账务系统仍要做镜像校验(06 篇:金融账务核心:多币种账户与复式记账怎么设计日切隔离校验照做)——合作方出问题时,平台对商户的商誉责任逃不掉,数据自证能力是危机时刻的救命稻草;
- 渠道资金存放集中度限额(单一银行/合作方存放客户资金占比上限)写入风险政策(决策登记簿 对应决策),与 07 篇:渠道网关与智能路由:连接全球资金网络流量集中度红线并列——流量可以切,存量资金被冻结切不走,后者才是兑付危机的来源,预案需包含商户沟通与兑付顺序安排。
7. 与各篇的回填关系
| 篇 | 回填点 |
|---|---|
| 05 §6 | 牌照地图的每一行,落地时先回答"哪个主体去申请" |
| 06 §7 | legal_entity 维度的取值域与账套边界由本篇定义 |
| 10 §5 | 税务属地依赖签约主体(已加注) |
| 11 | 申报义务主体按辖区×主体矩阵展开 |
| 12 | Portal/API 文案的资金服务主体披露(§2.3) |
| 19 | 资本金与营运资金按主体分配 |
设计取舍
- 一期签约主体与借牌协议三方结构(外部律师定性意见为交付物);
- 资金枢纽选址 HK vs SG(与主体设立顺序绑定,04 篇:换汇与头寸管理:定价、敞口与流动性的系统解法);
- 多主体账套的会计政策与合并口径(06 篇:金融账务核心:多币种账户与复式记账怎么设计);
- 渠道资金存放集中度限额与兑付预案。
权威资料与时效核验
以下资料于 2026-07-19 完成核验。实际落地时仍应以目标辖区最新法规、监管指引与专业意见为准。
核心结论
- 技术服务商与资金链条参与方承担完全不同的监管责任。
- 签约、持资和收入主体可以不同,但必须被系统准确表达。
- 客户资金隔离与渠道集中度需要同时控制流量和存量风险。