在 2010 年代，“银行即服务”（Banking as a Service）让构建卡项目和为消费者推出账户变得前所未有的简单和便宜。曾经属于银行部门的工作，现在变成了初创公司可以快速、低成本采用和集成的 API。
编译：深潮TechFlow
过去十年，BaaS 堆栈已经成为金融科技领域的主流模式。这一模式让更多的非银行品牌进入市场。 联名卡（Co-branded Cards）已经存在了几十年。然而，航空公司奖励卡的现实是，它本质上仍然是一个银行产品，只是挂上了航空公司（如达美或美国航空）的标志，并在银行网站和移动应用中出现。这种模式更像是“白标化”（Whitelabel），而不是“即服务”（as a Service）。
实现这一点仍然需要接入银行和支付的“轨道”，例如信用卡、ACH（自动清算中心）和电汇。这为较小的银行提供了机会，它们通过与第三方（如新型银行 Neobank）合作来“出租”自己的牌照。这些新型银行和非银行机构随后通过 API 提供商组装面向客户的产品。
BaaS 消除了牌照的限制，但保留了结算的限制。
在 BaaS 模式中，资金的归宿在哪里？在 BaaS 模式下，资金存放在银行。在美国，这通常以“FBO”（For Benefit Of，即受益人账户）结构的形式存在。
尽管许多金融科技公司最终会获得自己的州际资金传输牌照，但 FBO 结构通常是更优的选择，特别是对于非金融品牌而言。在欧洲，许多公司则会选择获得电子货币机构（EMI）牌照等。
在高层次上，FBO（For Benefit Of）账户使企业能够在不受某些资金传输类型昂贵监管的情况下管理客户资金。 如果你为客户移动资金，FBO账户就像一个巨大的账户。如果你有 1000 个客户的资金，这些资金都会混合在一个大账户中。
为了解决这个问题，你可以使用子账簿或“虚拟账户”来拆分资金。这些可以由新型银行（如 Chime）构建，由支付公司等提供商提供，或者有时由银行作为附加服务提供。
编译：深潮TechFlow
在 BaaS 模式下，谁负责客户资金的追踪并不明显。
资金在法律上存放于 FBO 账户中。但“虚拟账户”的管理者负责确认每一美元属于谁。
这听起来有些复杂，尤其是当持有 FBO 的银行和子账簿提供商无法就账户中的资金对账时。这正是 Synapse/Evolve 事件中出现的问题，导致超过 10 万客户无法访问他们的资金。
了解资金的存放位置以及各方的职责至关重要。