客户分布：同样是持牌，为什么服务的人完全不同
所属：第二部分 · 产品（第 2–9 章） 前置：第 2 章（机构服务不等于出租牌照）；第 3 章（同一套支付网络可以同时服务个人、企业与平台） 本章主问题：牌照相似或不同的公司，为什么会形成完全不同的客户边界？ 本章新概念：金融服务客户、集成伙伴、终端用户、客户边界的三类约束
一、牌照只回答第一问：法律允许公司做什么¶
只看牌照，很容易把客户分布想成一张监管地图的投影：银行服务持牌机构，支付机构服务普通用户，加密牌照服务加密客户。现实并不是这样。
同一张银行牌，既可能承载零售存款，也可能只做机构结算；同一类 PI／EMI，既可能直接服务个人，也可能把跨境付款能力嵌入银行或平台；一家公司的客户是加密企业，也不等于这家公司正在提供加密资产服务。
要比较 Banking Circle、Wise、Revolut 与 Fiat24，先固定四个角色：
- 供应商：本章正在分析的四家公司。
- 金融服务客户：以自己的名义与供应商建立账户或受监管服务关系的一方。它可能就是终端用户，也可能是一家机构。
- 集成／分发伙伴：把供应商的能力接进自己的界面或流程的一方。接了 API，不等于它因此取得供应商的牌照。
- 终端用户：最终使用账户、卡、汇款或加密服务的人或企业。它与谁建立金融服务关系，要看具体合同，而不是看谁展示前端页面。
这是四种关系角色，不是互斥客群；同一主体可以兼任多个角色。Fiat24 的终端用户同时也是它的金融服务客户，Wise Platform 的伙伴也可能兼任金融服务客户与集成伙伴。第 2 章所说的“BC 机构客户”，就是本章“金融服务客户”中的一种。
先把分析对象固定为一个候选客户—场景组合，例如“某类企业在某个辖区申请某项账户服务”。每个候选组合都同时受到三类约束：
- 活动资格：法律允许供应商执行哪些受监管动作？
- 产品与合同关系：谁签约、谁持有账户或余额、谁面对终端用户、谁执行那项动作？
- 风险政策：在法律允许的范围内，公司愿意接受哪些行业、地区、客群与使用场景？
图按阅读顺序把三类约束展开，不表示公司在业务上一定先审牌照、再签合同、最后才做风控。
因此，本章的主干不是“客户身份决定牌照重量”，而是：
实际服务的客户—场景组合 = 法律允许 ∩ 产品关系成立 ∩ 风险政策接受。
决定供应商需要什么资格的，是供应商自己执行什么活动、谁控制客户资金或资产、谁与终端用户建立法律关系；客户有没有牌照，只是风险与责任分析中的一个变量。
二、把四家公司放进同一组问题¶
以下比较的是截至 2026-08-24 的公开产品与合同关系，不是用“零售、机构、加密”三个标签给公司画互斥边界。同一家公司可以同时存在多种模式。
| 公司 | 谁直接取得账户或金融服务 | 存在下一层终端用户时，谁维持终端关系 | 与本章关系结构相关的产品 | 不能据此推出什么 |
|---|---|---|---|---|
| Banking Circle | 银行、非银行金融机构，以及符合风险政策的非受监管企业；不服务个人消费者 | 机构客户可以再服务自己的客户；这些终端客户与 Banking Circle 没有直接关系 | 机构账户、收付、清算、外汇，以及特定数字资产服务 | “做机构后台”不等于把银行牌照租给客户；也不能把所有 Banking Circle 客户都写成持牌机构 |
| Wise | Wise Account／Business 由个人与企业直接取得；Wise Platform 中，金融服务客户可能是伙伴，也可能是嵌入场景中的终端用户 | 随集成模式变化：受监管金融机构可以代表自己的客户付款，嵌入伙伴可以把 Wise 账户接进自己的界面，企业伙伴也可以只管理自己的 Wise Business 资金 | 跨境报价、换汇、收付、账户与卡，以及可嵌入的跨境支付网络 | “有 API”不表示伙伴取得 Wise 的牌照；Wise Platform 也不是单一合同结构 |
| Revolut | 个人与企业直接成为相应 Revolut 实体的客户；加密产品也由获准实体提供 | Business API 主要自动化企业客户自己的账户；Crypto Ramp 则让伙伴把用户导向 Revolut 的买卖流程 | 账户、卡、收付、投资与已获准的加密资产服务 | “开放 API”不等于替第三方给其用户发账户；加密也不是边缘虚线功能 |
| Fiat24 | 终端用户与运营方 SR Saphirstein AG 建立双边金融服务关系 | 钱包是联合品牌与集成入口；账户由 Fiat24 体系提供，Fiat24 做身份核验，伙伴不会因此取得牌照 | 代币化账户、卡、支付与单向加密资产卖出换法币，通过钱包界面分发 | “钱包把 Fiat24 接进来”不等于钱包成为账户提供者，也不等于 Fiat24 把牌照租了出去 |
这张表揭示了两条容易被混在一起的轴：
- 直接入口还是伙伴入口，描述产品从谁的界面进入；
- 关系到哪一层，描述供应商直接面对终端个人／自用企业，还是面对会继续服务下一层用户的机构／平台。
两条轴相互独立，可以形成多种组合。Wise 既有直接零售，也有机构嵌入；Fiat24 可以从钱包界面进入，但金融服务关系仍直接落在终端用户与运营方之间；Banking Circle 的前台机构客户可以服务自己的终端客户，而后者不因此成为 Banking Circle 的客户。
三、API 与 BaaS（Banking-as-a-Service）都不足以说明责任边界¶
API 只说明系统之间怎样传递资料、指令与状态。BaaS 则是一个覆盖面很宽的市场称呼；单凭这个标签，无法知道谁在提供受监管服务。
看到“嵌入式金融”、白标（由伙伴品牌呈现）或 BaaS 时，应继续问四件事：
| 要核对的问题 | 要辨认的边界 |
|---|---|
| 账户或服务合同写的是谁 | 谁是供应商的金融服务客户，谁承担主要合同义务 |
| 余额在谁名下、谁对余额记录负责、客户资金或资产由谁控制 | 帮助识别账户或资产关系落在哪个主体；单纯维护技术账本仍不足以下结论 |
| 谁做客户身份核验（KYC）、交易监控、制裁筛查、投诉处理 | 日常责任怎样分配；外包了哪些步骤、哪些责任仍不能转走 |
| 前端品牌和 API 属于谁 | 用户从哪里进入、伙伴怎样分发产品；它本身不证明牌照归属 |
用这四问回看四家公司，差别会比“做不做 BaaS”更清楚：
- Banking Circle 向机构客户交付银行与支付服务；在客户继续向下服务终端用户的模式中，前端和终端关系仍由机构客户经营。
- Wise Platform 至少包含代理行、嵌入式与企业自用等不同模式，责任边界要逐一看产品与合同。
- Revolut Business API 要求企业先有 Revolut Business 账户，主要用于自动化自己的收付；Crypto Ramp 是另一种关系——伙伴提供入口，用户进入 Revolut 的加密交易流程。
- Fiat24 的钱包伙伴负责集成与分发，但公开条款把金融服务合同放在 Saphirstein 与终端用户之间。
牌照和清算席位始终留在获准主体名下。伙伴能够调用一项服务，不等于取得了提供这项服务的资格。
四、碰到加密，先分活动，再看客户¶
“做加密”至少可能指三种不同关系。它们的资格问题不能互相替代。
| 关系／活动 | 供应商自己在做什么 | 欧盟首先要核对什么 | 客户是持牌加密公司，能否替代供应商资格 |
|---|---|---|---|
| 发行 EMT | 发行与单一官方货币挂钩的电子货币代币 | 一般规则下，MiCA 第 48 条要求发行人是信贷机构或 EMI，并履行通知、白皮书等要求；PI 身份本身不够 | 不能。资格看发行人是谁 |
| 提供加密资产服务 | 例如托管、交易平台、兑换、执行或转移 | 第 59 条给出两条准入路径：按第 63 条取得 CASP 授权，或由符合第 60 条的既有金融机构在相应范围内履行通知程序 | 不能。客户自己的 CASP 身份不会覆盖供应商执行的服务 |
| 向加密企业提供法币账户或支付 | 给交易所、发行人或 Web3 企业提供法币收付 | 先看银行／支付活动的许可、客户尽调、资金来源、制裁与交易监控；不能仅因客户属于加密行业就判定供应商在做 MiCA 服务 | 不能替代，也不必然触发同一类加密资格；关键仍是供应商执行的动作 |
前两行分别落在总览的“加密货币发行”和“加密资产服务”两列；第三行仍是银行／支付服务，只是客户来自加密行业，不是第三类加密牌照。
把这三类关系放回四家公司，会得到比“在不在加密圆里”更准确的结论：
- Banking Circle 可以同时以不同身份出现：为数字资产机构提供法币银行与支付服务，由欧盟银行主体发行 EURI，也依 CASP 授权提供稳定币转换与结算。写作时已确认法币换稳定币上线，反向仍标为 Coming Soon；方向与承载主体见第 2 章。每项活动仍要分别找主体和资格，不能压成“它什么加密业务都能做”。
- Wise 的账户政策不支持用 Wise 账户买卖或交易加密资产，也禁止向加密交易所或钱包转账；来自平台的入账并非“对方持牌就一定允许”，Wise 仍会按许可状态与风险容忍决定是否接受或退回。卡片是另一套规则：在交易合法且发卡地区支持时，Wise 卡可以用于加密平台。Wise Business 通常也不接受从事加密业务的企业。这里同时包含产品选择与风险政策，不能从未上线反推它法律上永远不能做。
- Revolut 的欧洲加密主体 Revolut Digital Assets Europe Ltd 已取得 CySEC 的 MiCA CASP 授权；集团目前提供加密买卖、Revolut X 与 Crypto Ramp 等产品。加密已经是一条明确的受监管产品线，不宜再画成零售账户旁边一个“顺手加上”的小角落。
- Fiat24 的运营主体位于瑞士，首先应按瑞士法律与 FINMA 许可范围分析，不能直接套用 MiCA 的发行人与 CASP 分类。公开产品已能确认的是单向把加密资产卖出换成法币，不提供反向买入或客户托管；具体机制见第 9 章。终端用户关系和身份核验留在 Fiat24 体系内，每项受监管动作仍要分别核对执行主体与许可依据。
五、客户持牌状态会改变尽调，但不决定供应商的“牌照档位”¶
受监管客户通常能提供牌照、治理、审计和反洗钱制度等材料。这些信息会影响风险评级、尽调深度和持续监控方式；在法律允许且条件满足时，供应商也可能依赖第三方完成部分客户尽调步骤。
但这不意味着供应商可以把责任整体交给客户。欧盟反洗钱规则第 25 条明确：即使依赖第三方，最终客户尽调责任仍由依赖方承担。Banking Circle 的风险政策也明确说明，它要完成自己的客户尽调；机构客户查过自己的用户，不等于 Banking Circle 可以跳过对机构客户及其业务的审查。
更不能把合规成本写成“机构数 × 单次尽调”与“用户数 × 链上追踪”的简单乘法。实际成本至少还受三组因素影响：
- 风险复杂度：服务活动、资金流，以及客户的地区、行业和所有权结构；
- 规模与路径：交易量、速度、币种、跨境路径，以及是否存在下一层终端用户；
- 责任与运营：谁做第一线监控，数据质量、自动化程度、异常调查与合同分工。
因此，正确的因果方向是：
| 要解释的结果 | 首要决定因素 |
|---|---|
| 供应商需要哪类资格 | 供应商自己执行的受监管活动、控制的资金或资产，以及所在辖区 |
| 某类客户能否进入 | 法律允许范围、产品关系与公司的风险政策 |
| 尽调与监控怎样做 | 客户风险、资金流、可获得的证据及责任分配 |
| 合规成本有多高 | 客户与交易规模、风险复杂度、运营方式和自动化水平共同决定 |
这也解释了为什么瑞士 FinTech 牌照的 1 亿瑞郎上限不能被称为 Fiat24 的“合规产能”。1 亿瑞郎是公众存款上限；第 1b 条另外把特定加密资产纳入许可范围。公众存款不得由机构投资，也不得支付利息。无论如何，这都不是用户数上限，也不能据此推断 KYC、客服或监控会在何时触及运营瓶颈。
六、以后怎样判断一家公司的客户边界¶
遇到新公司时，仍按本章的三类约束判断：
- 活动资格
- 供应商执行的是账户、支付、换汇、发卡、托管、交易、发行，还是只提供软件？
- 执行该动作的是哪个法律主体，位于哪个辖区，具体许可允许到哪里？
- 产品与合同关系
- 谁以自己的名义签约，账户、余额或资产关系落在谁身上？
- 若另有伙伴与终端用户，谁对客户余额记录负责，谁做 KYC、监控、制裁筛查和投诉处理？
- 风险政策
- 在法律允许的组合中，公司实际接受哪些行业、地区、客群与使用场景？
- 把“法律允许”“产品已上线”“当前主战场”分成三种状态，不从其中一种跳到另一种。
到这里，四家公司的差别就不再是一张模糊的客户维恩图：
- Banking Circle 以机构金融服务为主；存在下一层终端用户时，终端关系留在机构客户一侧；
- Wise 同时经营直接客户与多种嵌入模式，核心是跨境支付网络；
- Revolut 直接服务个人和企业，也把加密做成由获准实体承载的产品线；
- Fiat24 借钱包分发，但把终端用户的金融服务关系留在自身体系。
客户边界不是牌照地图的投影，而是活动资格、产品／合同关系与风险政策共同约束的结果。
七、来源¶
- 客户与责任关系：Banking Circle 风险偏好政策、Banking Circle 投诉政策、Wise Platform、Wise Platform 集成模式、Revolut Business API、Revolut Crypto Ramp API、Fiat24 伙伴条款、Fiat24 客户信息与 KYC
- 加密活动与资格：MiCA 合并文本、第 48 条、第 59 条、第 60 条、EBA：PSD2 与 MiCA 的衔接
- 四家公司当前边界：Banking Circle 数字资产机构业务、EURI 官方材料、Banking Circle CASP 服务公告、Wise 加密政策、Revolut 2025 年报、CySEC 的 Revolut CASP 登记、Fiat24 开发者文档
- 尽调与牌照上限：欧盟反洗钱指令第 25 条、EBA 对第三方依赖的说明、FINMA：瑞士 FinTech 牌照、FINMA FinTech 持牌机构名单
上一章：第 3 章 Wise：把跨境汇款拆成两端本地支付
下一章：第 5 章 Revolut：把一套监管栈逐区落地