打开你的销售点应用程序、开票工具或电子商务仪表盘，很大概率会有一个“企业账户”或“即时付款”按钮映入眼帘。放置这个按钮的很可能不是一家银行，而是你每天都在使用的软件公司——它已经悄然成为小企业持有、转移和借贷资金增长最快的方式之一。
这就是嵌入式金融：将银行类产品——账户、借记卡、支付、贷款——直接构建在企业主已经使用的软件平台内，而非由单独的银行附加而成。全球嵌入式金融市场从2025年的大约1480亿美元增长到2026年的约1970亿美元，分析师预计到2030年将达到近5880亿美元。仅在美国，到2026年底，嵌入式金融科技产品预计将处理超过7万亿美元的交易——高于2021年的2.6万亿美元。非银行发卡是这一转变的重要组成部分：平台和软件公司现在在小企业卡交易量中占据了快速增长的份额，而这部分曾经完全属于银行。为这些平台和“赋能者”提供动力的收入预计将从大约20亿美元攀升至110亿美元。
翻译过来就是：小企业主过去只需要做一次的决定——“我用哪家银行？”——现在变成了他们每次选择软件时都会反复做出的决定，而且往往没有完全意识到这一点。
为什么软件公司变成了银行
这一切的发生并非因为Shopify或Square某天醒来想成为一家银行。原因在于，掌控财务关系是一桩极其有利可图的生意——而且实现这一目标的基础设施变得廉价且易于接入。
现在有一批“银行即服务”基础设施提供商负责处理受监管的、合规性强的各种管线工程，这样软件公司就不必自己成为银行：
- Stripe（Treasury, Issuing, Capital）为包括Shopify在内的平台提供金融功能支持。
- Marqeta 是许多嵌入式卡计划背后的主导卡片发行处理商。
- Unit 和 Cross River Bank 让软件公司能够嵌入账户和贷款服务，背后由一家发起银行支撑。
- Parafin 为Square和DoorDash等平台提供商户融资支持。
结果是实实在在的产品，而非空想。Square将企业银行服务——账户、储蓄和短期信贷——直接构建到商家已用于管理销售的同一仪表盘中。Shopify Balance为商家提供一个直接关联其店铺收入的企业账户和借记卡，资金到账速度比等待传统银行转账更快；仅Shopify Capital在2025年就为商户提供了42亿美元的融资。Toast为餐馆做了类似的事情，ServiceTitan则为家政服务承包商提供服务。这种模式几乎在每个垂直领域的SaaS类别中重复出现：该软件已经实时看到你的收入，因此它能够比只看月度报表的银行更快地进行承销、发卡或预借现金。
为什么企业主接受这种交易
这种吸引力并非空泛。美国三分之二的小企业正在积极寻找新的银行合作关系，大约80%的金融机构本身预计将在未来两年内扩大小企业服务——这默认承认了它们正在失去阵地。与此同时，信用卡已悄然成为小企业的默认融资工具：大约一半的美国小企业使用企业信用卡，另外四分之一的企业通过个人信用卡支付业务开支，这主要是因为批准是即时的，所需文件最少，且无需抵押品。
嵌入式金融直接迎合了这种偏好。当你的销售点系统已经知道你的每日收入时，它能够提供银行分行根本无法比拟的当日承销。当你的开票软件已经持有未付应收账款时，它可以无需贷款委员会批准就据此提供预付款。对于一个多年来一直看着各种独立工具——支付、薪资、银行、记账——笨拙地无法互相沟通的企业主来说，“一切都集成在我已经使用的应用程序里”是一个真正有吸引力的卖点。
开户流程中无人提及的权衡
便利性伴随着一个结构性陷阱：当你的银行账户存在于一个软件平台内部时，你实际上并非直接与银行打交道——你是通过一家软件公司*与银行打交道，而这个中间层至关重要。
最清晰的警示案例是2024年Synapse的倒闭，这是一家金融科技中间件提供商，它将来自数十个应用程序的客户资金汇总路由到合作银行的“受益人利益”综合账户中。当Synapse倒闭时，超过10万名客户共计2.65亿美元的存款被冻结。问题不在于基础银行没有保险——它是有FDIC保险的——而在于FDIC保险保护的是银行倒闭，而不保护中间商未能准确记录谁的钱是谁的。Synapse自己的子分类账，即本应准确说明综合账户中每一分钱属于哪个客户的记录，无法对账，一年多后仍有部分客户在等待资金。作为回应，FDIC已采取行动，针对此类第三方安排加强记录保存规则。
这并不意味着嵌入式银行产品默认不安全——上文提到的那些资本充足的大型平台拥有强大的银行合作伙伴关系，并且一直运营良好，没有出过事故。但这确实意味着尽职调查的问题不同于“这是一家真正的银行吗？”。在将实际运营资金转移到平台的银行功能之前，一个更好的检查清单是：
- 实际的FDIC承保银行合作伙伴是谁，是否被清晰注明，而不仅仅是通过页脚的徽章暗示？
- 资金是存放在独立名义账户中（提供按客户分类账的FBO账户），还是存放在一个大型综合账户中，仅靠平台自身的内部记录来追踪你的份额？
- 如果软件公司本身倒闭，你的资金会怎样——不是银行倒闭，而是横亘在你和银行之间的这家软件公司倒闭？
- 如果你需要离开，能否以开放格式导出你的交易历史，还是它被锁定在平台的专有仪表盘内？
最后一个问题的重要性超出了转换成本。金融活动越多地被嵌入到一个平台内，你的记账工作就越会分散在各个工具中，每个工具只持有你业务的片面信息——这里一笔Shopify Balance交易，那里一笔Square贷款还款，另一个地方的一笔Toast付款——除非你有意培养整合的习惯，否则这些信息都不一定能与你的总账清晰地勾稽对账。
银行、平台，还是两者兼有？一个实用框架
大多数企业主实际上并不面临“传统银行”和“嵌入式金融平台”之间的非此即彼的选择——在实践中，成功的设置通常是两者结合，按职能分工：
将嵌入式产品用于对速度敏感、与收入挂钩的需求。 如果你的销售点或电子商务平台已经实时看到每一笔销售，那么它的即时付款、运营资金预借或基于收入的卡在短期现金流平滑方面确实难以被超越——为缓慢的一周支付工资、在繁忙的一周前补充库存、或者填补发出大额发票与收到付款之间的缺口。这些产品是基于传统银行无法触及的数据进行承销的，这正是它们能在几分钟而非几周内做出批准的原因。
将你无法承受失去访问权限的资金保留在传统（或至少是独立）的银行账户中。 储备金、预扣税款、工资资金以及任何用于有硬性截止日期的义务的资金，都应该放在一个你不会因软件供应商的宕机、定价变化或——在Synapse情景中——偿付能力而面临风险的地方。银行账户的设计就是枯燥的，而当账户里的钱必须在你需要时绝对可用时，枯燥就是一种优点。
根据时间跨度而非噱头来匹配工具。 一个好的经验法则：几天内会用到的钱可以合理地存放在为速度优化的嵌入式产品中；而你持有数周或数月、或者已有明确用途的钱，则应存放在你与它之间活动部件最少的账户中。很多企业主最终会同时运行两者——一个Shopify Balance或Square账户用于日常销售周转，一个传统的企业支票账户作为实际的储备金。
真正吃亏的企业通常不是那些使用嵌入式金融产品的企业——而是那些将嵌入式产品视为其唯一金融关系，对于底层银行合作关系位于何处，或者如果中间的软件公司出现问题会发生什么毫无了解的企业。
当你的银行是一堆应用程序时如何保持账目清晰
无论你的资金是存放在传统银行还是三个不同的嵌入式金融产品中，会计基础原则不会改变：每笔进出的美元都需要记入正确的账户、正确的日期、并正确分类。发生变化的是整合所有这些信息所需的纪律，因为嵌入式金融意味着你的“银行对账单”不再是每月一份PDF文件——而是持有你部分资金的每个平台的导出文件（或者，如果你幸运的话，是API数据源）。
这正是纯文本、版本控制式记账的用武之地。Beancount.io 允许你从多个来源——一个Shopify Balance账户、一笔Square贷款、一个传统的企业支票账户——提取交易，汇入一个你完全拥有、可审计的分类账，而不是将你的财务状况信任给任何碰巧在当天给你展示仪表盘的应用程序。每项记录都是透明的、可比较的、可移植的，因此切换平台（或者仅仅是希望跨越五个平台获得一个单一事实来源）绝不意味着重新开始你的记录。免费开始使用，无论你的企业银行账户实际存放在多少个地方，始终保持一个清晰的总账。