针对中小企业软件的嵌入式金融与银行业务即服务 (BaaS)：垂直 SaaS 如何增加支付、借贷和发卡功能

Toast——一家针对餐饮行业的销售点（POS）平台——去年从金融服务中赚取了约 50 亿美元。而其最初构建的核心产品——软件订阅——仅带来了 9.36 亿美元。现在，金融科技这根“尾巴”的规模已经是 SaaS 这只“狗”的五倍。

同样的模式正在垂直软件领域上演：Shopify 的商家解决方案占其收入的 73%。ServiceTitan 上市时的收入构成为 71% 的订阅和 25% 的金融科技，但观察净新增收入的分析师发现，这一比例正趋于 55/45——支付业务的增长速度超过了软件核心。到 2026 年，当一家垂直 SaaS 公司进行 B 轮融资时，投资者的问题不再是是否要嵌入支付，而是使用哪种嵌入式金融技术栈，以及贷款和发卡功能的跟进速度有多快。

这就是业界所称的嵌入式金融——在非金融软件内部提供的金融产品——而其底层的管道则是银行业务代发 (BaaS)。这个机会是真实存在的：据预测，美国平台的嵌入式金融收入将从 2021 年的约 220 亿美元增长到 2026 年的 510 亿美元，且 BaaS 市场到 2031 年的年复合增长率（CAGR）将达到 17.8%。但在这一机遇身旁，也堆满了由于同意令、被冻结的项目和审计遗漏而产生的“坟场”，大多数掉入陷阱的创始人直到监管机构找上门才意识到自己正在经营类似银行的业务。

本指南将深入探讨什么是嵌入式金融，为什么垂直 SaaS 是其天然的家园，2026 年的技术栈是什么样的，如何选择供应商，以及那些可能将充满希望的发布变成生存危机的合规陷阱。

什么是“嵌入式金融”的真正含义

嵌入式金融是金融产品——支付、存款账户、借记卡、贷款、保险、薪资——在表面上并非金融产品的软件内部交付的简称。例如，一个建筑软件平台，如果它允许承包商接受客户的 ACH 支付、将现金存放在子账户中，并针对未付发票申请即时垫款，那么它就在经营嵌入式金融。同样，一个为兽医技术员发放品牌借记卡以购买用品的兽医诊所管理系统也是如此。

这些功能背后的技术引擎大多是银行业务代发 (BaaS)：一家受监管的银行（“合作银行”）出租其牌照、对 ACH 和银行卡网络的访问权限以及受 FDIC 保险的账本给金融科技中间件提供商，后者再将这些能力转化为普通软件公司可以调用的简洁 API。软件公司本身从未持有银行牌照，但如果仔细阅读细则，你会发现它承担了一长串运营和合规责任，看起来非常像是在经营一家银行。

嵌入式金融技术栈主要由三种产品构成：

• 嵌入式支付：代表 SaaS 平台的终端客户接受银行卡和 ACH 支付。这是“敲门砖”——最容易部署、实现收入最快，也是其他所有功能的基础。
• 嵌入式贷款：根据未来应收账款提供的现金垫款、授信额度产品，以及利用平台的原生交易数据进行承保的定期贷款。其抽成率和净利差远高于支付业务。
• 发卡与账户：品牌借记卡、虚拟卡和受 FDIC 保险的运营账户（如为施工队提供的“消费卡”、为零工提供的“收益账户”、为买家提供的“门店信用卡”）。

这些层级中的每一层都会与其它层产生复利效应，因为每一层都在捕获更多的客户营运资金流。

为什么垂直 SaaS 拥有不公平的优势

通用的支付应用看到的只是孤立的刷卡行为。而垂直 SaaS 平台看到的是产生该刷卡行为的合同、根据合同安排的工时、必须在周五前支付的材料发票、同邮编区域内每位客户的历史季节性规律，以及该经营者正趋向于透支的银行余额。

这种上下文环境就是护城河。它同时改变了三件事：

1. 核保变得更便宜且更准确：一家建筑 SaaS 公司知道哪些承包商能按时拿到钱，哪些公司的账面上总有 90 天的应收账款。这使得现金垫款产品比银行提供的通用小微企业贷款（银行只能看到税表）要稳妥得多。
2. 分销成本大幅下降：客户已经在应用内部。新金融产品不需要获客漏斗——在用户已经在使用的屏幕上放置一个横幅即可。行业分析师估计，成功嵌入金融产品的平台，其单客收入可翻三到四倍。
3. 留存率产生复利效应：一旦薪资、支付和授信额度都通过你的软件运行，切换成本将变得极其高昂。金融科技层将每月 99 美元的订阅服务变成了每年 5,000 美元的金融服务账户。

这就是为什么垂直 SaaS 的金融科技剧本在短短四年内，从“实验性的副业”变成了“B 轮融资的默认规划假设”。

2026 年技术栈：各司其职

嵌入式金融供应商图谱异常拥挤，且类别存在重叠。以下是 2026 年中小企业 (SMB) 软件团队最常列入候选名单的供应商简化视图：

支付处理与编排

• Stripe Connect 和 Stripe Treasury。 开发者优先的默认选择。强大的 API、优秀的文档，涵盖了从银行卡收单到余额存储及发卡的广泛领域。最适合希望由单一供应商处理大部分技术栈的团队。
• Adyen for Platforms。 按交易量定价且全球实力雄厚。在处理支付额超过 5000 万美元时具有更好的经济性；入驻流程较慢，且对较小规模的项目不够慷慨。
• Finix 和 Payabli。 “PayFac 即服务” —— 它们帮助平台在无需构建完整监管体系的情况下成为支付服务商（或至少看起来像一个）。

银行与账户（BaaS 中间件）

• Unit。 对于希望持有客户余额或发行品牌卡的美国 SaaS 公司而言，这是最快的上线路径。产品强大，但与少数几家合作银行（sponsor banks）高度耦合。
• Treasury Prime。 多银行 API —— 当你希望获得银行级功能（如 FDIC 转递保险和实时支付）而又不锁定于单一合作银行时非常有用。
• Synctera。 以合规为核心的中间件，试图从第一天起就将 BSA/AML 工具引入开发者体验。
• Column。 一家同时开放自身 API 的银行，去掉了中间件这一层。

发卡业务

• Marqeta, Lithic, Highnote。 用于品牌借记卡、预付卡以及日益增多的信用卡项目的发卡基础设施。Marqeta 擅长规模化；Lithic 吸引那些追求精简且对开发者友好的团队；Highnote 则倾向于信用和消费类产品。

信贷与资本

• Parafin, Kanmon, Liberis。 嵌入式信贷 API，利用平台交易数据进行承销，并处理放款、贷后管理以及（在某些情况下）资产负债表业务。

账本与资金移动

• Modern Treasury。 平台内账本基础设施的参考实现；被 Gusto 和 Marqeta 等公司用于在资金到达银行前理清自己的账目。
• Dwolla, Moov。 专注于 ACH 的程序化资金移动，通常与卡处理器配合使用。

大部分运行中的项目都会结合其中的三到四种 —— 例如，一个物业管理平台可能会使用 Stripe 进行银行卡收单，使用 Unit 处理房东收益账户，使用 Marqeta 为物业经理发行品牌借记卡，并使用 Parafin 提供基于租金收入的现金垫款。

务实的阶段性计划

最常见的错误是试图在一次重大发布中同时推出支付、信贷和卡片。千万不要这样做。每一层的合规、运营和经济复杂性各不相同，几乎所有案例中的正确顺序都是一致的。

第一阶段 —— 支付（0 到 6 个月）。 为你客户的客户增加银行卡收单功能。这是风险最低、业务量最大的层级。构建集成使平台能从每笔交易中获得一小部分收益（通常为 30 到 100 个基点）。利用这一阶段巩固客户入驻、KYB（了解你的业务）检查和欺诈监控。

第二阶段 —— 账户与拨付（6 到 12 个月）。 一旦支付功能稳定，增加客户在平台内持有余额、发送 ACH 支出以及针对特定支出类别发行虚拟卡的功能。品牌借记卡通常是第二个卡类产品，而非第一个。

第三阶段 —— 信贷与资本（第二年）。 应收账款现金垫款排在首位 —— 它们期限短、易于承销，且能从后续入账中自动回收。定期贷款和信贷额度排在后面，因为它们需要更深厚的信贷、催收和坏账核销运营能力。

贝恩公司（Bain & Company）的数据显示，遵循这一顺序的平台，其抽成率（take rates）明显更高，坏账率则低于那些跨越式发展的平台。尽早推出信贷业务的诱惑力很大，因为其单位经济效益远好于支付，但吸收 4% 坏账率所需的运营成熟度是真实存在的，而这在第一年几乎总是缺失的。

没人想谈论的合规陷阱

2024 年 2 月，美国联邦存款保险公司 (FDIC) 针对两家银行发布了同意令，原因是涉及 BaaS 相关的安全性和稳健性问题 —— 主要是《银行保密法》(BSA) 合规和第三方监管失败。Piermont Bank 的命令触及了通过 Treasury Prime 和 Unit 运营的项目。Sutton Bank（与 Robinhood、Square 和 Upgrade 等金融科技公司合作）也收到了类似的调查结果。随后在 2024 年和 2025 年出现了更多命令。FDIC 报告称仅在 2025 年 5 月就发布了 12 份强制执行令。货币监理署 (OCC) 也对国民银行方面采取了类似的行动。

当合作银行接受同意令时，下游平台收到的不仅仅是一封严厉的信函 —— 项目通常会冻结，新客户入驻停止，在某些情况下，现有余额变得难以移动。那些感觉自己只是在运行“一个 SaaS 功能”的创始人突然发现，他们的路线图被一个从未谋面的监管机构所控制。

一些特定的义务经常让软件公司栽跟头：

• KYC 与 KYB（了解你的客户 / 了解你的业务）。 每位持有余额、获得卡片或收到贷款的终端用户都必须按照合作银行要求的标准进行身份验证 —— 而不是你的产品团队认为足够的标准。
• 受益所有权与 CIP。 客户识别程序 (CIP) 规则适用于企业客户，且对持股 25% 门槛的受益所有人信息的收集规则是被严格执行的。
• 交易监控与 SAR 申报。 可疑活动报告 (SAR) 不是可选的。平台通常进行一线监控；合作银行负责申报。如果监控薄弱，银行会遭受监管打击，而平台则面临合同终止。
• 营销与信息披露。 你对 FDIC 保险、利息和信贷条款的描述是受监管的。没有星号注释的“FDIC insured”比几乎任何其他短语引起的停止令都要多。
• 投诉处理与 Reg E。 消费金融产品带来了消费者保护义务，包括处理争议交易的具体时间表。

一个实用的经验法则：如果某项功能在你自己经营时需要牌照，那么你的合作银行合规团队也会这样对待它，即便你的产品经理没有这么想。

选择自建、购买还是合作伙伴

有三种合理的路径，而正确的答案取决于资本、监管胃口，以及金融服务在长期路线图中的核心程度。

纯合作伙伴 / 推荐模式。 平台将客户推荐给金融提供商，并赚取固定费用或小额收入分成。风险最低，收益最低，上线最快。适用于金融业务是辅助而非核心的 SaaS 公司。

通过 BaaS 中间件嵌入。 平台在客户眼中看起来和感觉上都像金融提供商，但受监管的活动由合作银行（Sponsor Bank）和中间件合作伙伴承担。大多数垂直领域的 SaaS 方案都处于这一阶段。分成率是实打实的，合规负担也是实打实的，且单位经济效益在规模适中时就开始显现。

直接申请牌照、许可或成为 PayFac。 少数平台最终会获得资金转移牌照（Money-Transmitter License），成为注册支付服务商（PayFac），或追求银行牌照。这非常昂贵、缓慢，只有当项目产生数千万美元的金融服务收入，且省下的中间件费用超过监管成本时，才具有意义。

一个简单的测试：如果你当前或计划的金融服务年收入低于 500 万美元，请选择合作伙伴或使用中间件。在 500 万到 5000 万美元之间，中间件几乎总是胜出。超过 5000 万美元，你至少应该开始建模，计算将更多技术栈转为自研的成本。

数字游戏：现实的经济模型

经济模型因产品而异。在制定财务计划时，请使用这些 2026 年的粗略基准作为起点，然后根据你的垂直领域进行调整：

• 银行卡收单： 在合作银行和中间件分成后，平台可获得处理金额的 30 到 100 个基点（bps）。
• ACH 转账： 个位数美分到低额固定费用，加上增值业务流中极小的百分比分成。
• 发行的借记卡 / 消费卡： 交换费分成通常为平台带来消费额 50 到 100 个基点的净收益，减去制卡和项目管理成本。
• 应收账款预付（Cash advances）： 有效年化利率（APR）在 30% 到 60% 之间，对于审核良好的账簿，核销率为 2% 到 6%。扣除资金成本后的净利润可达发放额的 8% 到 15%。
• 定期贷款： 年化利率较低，期限较长，运营成本较高。利润很大程度上取决于资金成本和催收业务。

特别是对于 B2B 嵌入式 ACH 支付，行业预测到 2026 年，平台将从增值服务中获取约 40 亿美元的净收入，而嵌入式银行卡交易额将再为平台增加约 8 亿美元的收入。这些数字之所以能够叠加，是因为捕获这些收益的是拥有客户关系和交易上下文的平台，而不是拥有支付轨道的银行。

避开这五个错误

在失败或陷入困境的项目复盘中，这些模式反复出现：

1. 在配置合规人员前就开始构建。 嵌入式金融项目的首位雇员不应是工程师或产品经理，而应是具有实际 BSA/AML（银行保密法/反洗钱）经验的人，理想情况下还应具有之前的合作银行关系。
2. 将合作银行视为供应商而非监管机构。 合作银行的合规团队对你的路线图拥有一票否决权。尽早让他们介入，即使在非必要时刻也是如此。
3. 对“小”客户跳过 KYB。 “小”不能成为例外。“我们认识这个客户”也不能成为例外。规则适用于每一个账户持有者。
4. 低估贷款的资金成本。 预付款的净利差在电子表格上看起来很美，直到你加上信用额度成本、核销成本、服务成本以及周期性的坏账计提。
5. 让营销走在法律合规前面。 大多数针对消费者金融服务的执法行动都可以追溯到单个广告、单个网页或应用内的一个横幅。金融产品的营销文案需要严格的审核流程和记录存证。

纯文本会计的用武之地

嵌入式金融创造了一个几乎无人提及的技术问题，直到它造成伤害：账本爆炸（the ledger explosion）。每一个客户余额、每一次刷卡、每一笔付款、每一笔贷款发放、每一笔追回以及每一笔退单，现在都是你系统中的会计事件，而不仅仅是在银行系统中。你需要将你的账目与合作银行的对账单、卡处理机构的结算文件以及贷款服务商的报告进行对账——且通常是每日进行。

像 Modern Treasury 这样的供应商之所以存在，正是因为传统分类账无法跟上资金流动的速度。对于公司内部财务——即首席财务官（CFO）必须认证的那些账目——同样的原则也适用：一旦金融服务开始流经你的平台，账本透明度、审计追踪以及针对外部数据源编写对账脚本的能力，将比你仅作为纯 SaaS 订阅业务时变得更为重要。

让你的账目像你的产品一样透明

嵌入式金融将软件公司转变为处理资金流动的公司 —— 支撑你业务的会计基础架构必须至少与你交付给客户的金融产品一样出色。Beancount.io 提供纯文本、版本控制的会计方案，完全透明、可脚本化，并专为金融科技型 SaaS 业务所需的高速对账而设计。这里没有黑盒，也没有供应商锁定 —— 你的账目存储在可以逐行审计的文本文件中。免费开始使用，了解为什么随着金融技术栈变得日益复杂，开发者和财务团队纷纷转向纯文本会计。