一家没有银行牌照、也不是 Visa 或 Mastercard 直接会员的 Fintech，仍然可以提供发卡产品；一家没有直接收单关系的平台，也可以让大量小商户快速接入卡支付。两类业务依靠的是不同的合作结构：发卡侧使用 BIN Sponsorship，收单侧使用 Payment Facilitator（PayFac）模式。
把它们统称为「租牌照」容易误解责任边界。持牌机构、卡组织会员资格和收单关系没有转移给 Fintech。Sponsor Bank 或 Acquirer 仍在相应规则下承担责任，Fintech、Processor 与 PayFac 则按合同运营产品、系统和客户关系。
第一阶段：两种模式解决了什么门槛
发卡需求从直接会员之外出现
卡组织的会员、许可和编号管理长期以受监管金融机构为核心。非银行公司如果要为员工薪资、预付余额、差旅或垂直行业提供卡产品，单独成为直接会员通常成本高、周期长，也不一定符合项目规模。
BIN Sponsorship 让这类项目使用 Sponsor 指定的 IIN/BIN 或 Account Range 发卡。BIN 是沿用至今的常用名称，现行编号标准使用 Issuer Identification Number（IIN）；业务系统可能同时遇到历史 6 位 BIN 数据和 8 位 IIN 数据。Program Manager 获得的是约定范围内的使用权，不是整个 BIN 的所有权。
进入 2000 年代后，Sponsor Bank 关系被用于 Payroll Card、Prepaid Card 与后来的 Neobank 产品。Chime 当前仍明确披露：Chime 是 Fintech 而不是银行，银行服务和 Visa 卡由 The Bancorp Bank 或 Stride Bank 提供。面向用户的品牌、App 和运营主体，与实际 Issuer 分开运行。
收单需求从长尾商户接入出现
传统商户通常要与 Acquirer 建立 Merchant Agreement，并完成身份、业务、风险和受理资格审查。电商平台、小餐馆、个人卖家和 SaaS 平台数量增加后，逐个完成相同接入流程会产生很高的运营成本。
PayPal、Square、Stripe 提供了面向大量小商户的平台化收款产品。今天的 PayFac 已是卡组织规则中的正式角色。以 Visa 规则为例，Acquirer 需要注册 PayFac，为它分配唯一标识；PayFac 再与每个 Sponsored Merchant 签订 Merchant Agreement，并为子商户分配标识。聚合提高了接入效率，但没有把商户审查变成匿名开户。
第二阶段：发卡与收单分别怎样协作
可以用移动虚拟运营商帮助建立直觉：面向用户的品牌负责产品、App、营销和客服，底层运营商提供号码资源与网络能力。这个类比的适用范围只有角色分工，金融许可不能像普通商品一样转租。
BIN Sponsorship 的三层职责
一套发卡项目通常包含三类角色，实际项目也可能由同一机构兼任其中两类：
| 角色 | 主要职责 | 不能省略的边界 |
| Sponsor Bank / Issuer | 管理卡组织关系、BIN 或 Account Range、结算安排和项目监督 | 第三方参与不会消除银行对安全、合规和消费者保护的责任 |
| Issuer Processor | 处理授权、卡片状态、额度或余额、账务接口与卡组织连接 | Processor 的产品认证不等于拥有银行牌照或项目最终责任 |
| Fintech / Program Manager | 设计 App 和卡产品，负责获客、客服、运营与业务规则 | 只能在 Sponsor、卡组织规则和当地法律允许的范围内运营 |
设定一笔 $10 刷卡交易在约 0.5 秒内返回授权结果：Processor 在实时路径中检查卡状态、余额或额度与规则；Fintech App 展示结果并处理用户服务；Sponsor 负责相应的发卡关系、结算安排和持续监督。0.5 秒只是演示数字，不能当成行业统一 SLA。
把直接接入写成 2～3 年、把赞助模式写成 4～8 周，也只能作为周期示意。真实周期取决于国家、产品、卡组织审批、Sponsor 尽调、Processor 集成、合规准备和测试，不能据此承诺上线日期。
PayFac 把商户接入集中起来
PayFac 的工作路径可以拆成五步：
Acquirer 对 PayFac 做尽调，在卡组织完成注册，并取得 PayFac Identifier。
PayFac 收集商户资料，完成适用的 KYB、风险判断和受理资格检查，再与 Sponsored Merchant 签约。
PayFac 为每个 Sponsored Merchant 分配标识，并在交易报文中保留 PayFac 与商户身份。
交易通过 Acquirer 进入卡网络；商户仍以自己的名称、MCC 和业务类型被识别。
Acquirer、PayFac 与 Sponsored Merchant 按合同和当地规则完成结算、Payout、退款、争议与储备金管理。
「秒级开户」或「几分钟接入」通常描述前台表单、API 和自动化决策的速度，不表示 KYC/KYB、制裁筛查、商户风险分类与持续监控被简化掉。Stripe Connect、Square 和 Shopify Payments 常被放在平台化收款的讨论中；具体产品是否按 PayFac、Marketplace 或其他模式运营，要看地区、签约实体和实际资金路径。
资金也不一定先进入 PayFac 的汇总账户。Visa 2026 年 4 月公共规则列出了多种安排，包括 PayFac 控制的本地结算账户、Acquirer 持有但由 PayFac 控制的账户，以及 Acquirer 直接向 Sponsored Merchant 结算。只画一条「先到 PayFac、再分发」的路径，会把可选实现写成唯一事实。
收益来自服务差额，责任也沿链条传递
发卡侧的收入
一笔卡消费可能包含 Interchange、Scheme Fee、Acquiring 成本与商户服务费等不同组成。Issuer 获得的 Interchange 收入，可以按 Sponsor 与 Program Manager 的合同分配。Fintech 70%、Sponsor 30%只能用作算例，不代表市场通行比例；收入还要覆盖 Processor、卡片、欺诈、拒付、客服、合规和资金成本。
收单侧的收入
PayFac 可以向 Sponsored Merchant 提供统一报价，并在上游成本之上加入 Markup。假设商户报价是 2.9% + $0.30，所有上游可变成本暂按 1.5%计算，那么 1.4个百分点只是示意性的费率差。它还没有扣除固定成本、Card Scheme 与 Processor 费用、欺诈损失、Chargeback、储备金、Payout、销售、客服和工程成本，因此不能直接称为净利润。
收入模型和责任模型是同一份合同关系的两面。Visa 规则要求 PayFac 对 Sponsored Merchant 的交易、争议和相关行为承担责任；Acquirer 又要对 PayFac 与 Sponsored Merchant 在 Visa 体系内的行为负责。低价获客如果没有持续风险管理，损失会沿着同一条链条向上回传。
合规边界决定模式能否长期运行
银行使用第三方，不会因此移除自身责任。美国 FDIC、Federal Reserve 与 OCC 的联合指引明确要求银行对第三方关系做规划、尽调、合同管理、持续监控和退出管理。发卡 Sponsor 需要监督 Program Manager，收单 Acquirer 也需要监督 PayFac 与 Sponsored Merchant。
实践中至少要持续管理以下三类风险：
客户与商户风险： KYC、KYB、制裁筛查和商户分类要按适用法律与项目规则执行，自动化只能提高处理效率。
交易与数据风险： 卡状态、欺诈、Chargeback、PCI DSS、异常交易和客户投诉都需要可追溯的控制与责任人。
资金与结算风险： 结算账户、资金控制权、Payout 和储备金安排取决于司法辖区、牌照、合同与卡组织规则。中国语境中的「二清」风险不能直接套用为所有海外 PayFac 的统一账户要求。
100 万美元门槛也需要按规则原义理解。Visa 2026 年 4 月公共规则要求 Acquirer 与年度交易量超过 USD 1 million 的 Sponsored Merchant 建立直接 Merchant Agreement：新接入商户要在处理交易前签订，存量商户要在超过门槛后的两年内签订，规则同时列出若干例外。PayFac 在建立直接协议后仍可继续提供支付服务，包括结算。因此，这个门槛改变的是合同与监督关系，不是强制商户离开 PayFac，也不能外推为 Mastercard 或所有地区的统一规则。
第三阶段：BaaS 把多项能力封装成 API
如果把 BIN Sponsorship 比作租下一层办公空间，BaaS（Banking-as-a-Service）更像带运营服务的办公室：账户、账务、发卡、资金通道和合规工具通过 API 组合交付。使用方仍然没有取得整栋楼的产权，也不能把服务商的技术接口当成自己的金融许可。
Marqeta、Stripe Treasury、Unit、Galileo 等平台都提供 BaaS 或 Embedded Finance 相关能力，但它们的模块、合作银行、适用地区和责任边界并不相同。评估时可以按五类逐项核对：
| 模块 | 可能提供的能力 | 需要单独确认 |
| Accounts & Ledger | 账户、余额、复式记账、虚拟子账户和对账接口 | 账户由谁开立，资金由谁持有，存款保险是否适用 |
| Card Issuing & Controls | 实体卡或虚拟卡、限额、MCC 控制、实时授权和 JIT Funding | Issuer、Account Range、授权 SLA 与清算责任 |
| Payments & Money Movement | ACH、RTP、FedNow、Visa Direct 或其他本地通道 | 覆盖范围、最终性、退回机制、资金可用时间和费用 |
| Embedded Credit & Yield | 融资、收益或资金管理产品 | 实际贷款人、存款机构、资格、利率和监管披露 |
| Compliance Tooling | 身份资料收集、筛查、监控和案件管理 | 工具不会接管持牌机构与项目方的法定义务 |
JIT Funding 在交易发生时决定入资
传统预入资模型需要为每个持卡账户保留足够余额。假设外卖平台给 1 万名骑手各预留 $100 餐费，分散在这些账户中的资金合计就是 $1m。这里的余额属于账户或资金安排，不是存放在塑料卡片里。
Marqeta 将 Just-in-Time Funding（JIT Funding）定义为交易处理中实时为账户入资。账户无需预先保有余额，平台可以按交易详情自动判断，也可以把 Funding Request 交给企业系统决定。
JIT Funding 带来的三项价值都有边界：
减少预先入资。 企业不必为每张卡长期保留固定余额，但仍要准备可用资金，并满足结算与流动性要求。
缩小未授权使用的暴露。 没有匹配订单或业务规则的交易可以不入资；账户接管、错误规则、离线交易、后续清算和争议风险仍然存在。
保留逐笔决策依据。 订单、金额、商户和批准结果可以进入对账记录；小费追加、退款、撤销、清算差异与 Chargeback 仍需单独处理。
「余额永远为 0」「盗刷风险归零」「账实 100% 对齐」都把上述收益写得过满。授权也没有统一的毫秒级时限，响应窗口取决于 Processor、卡网络、项目配置和服务协议。
一个 API 仍然连接多条不同资金通道
BaaS 平台可以把 ACH、RTP、FedNow、Visa Direct 等能力放进统一接口，再向骑手、卖家或消费者提供标准到账与即时到账选项。统一接口简化了接入体验，每条底层通道仍有不同的时效、最终性和价格。
把 ACH 套餐固定写成「免费、1～3 天」，把 RTP、FedNow 或 Visa Direct 固定写成「3 秒到账、收费 1%～1.5%」，最多只能作为某个产品的报价示意。Nacha 当前估计，80% 的 ACH 在一个银行工作日内或更快完成结算；RTP 与 FedNow 是美国的即时支付基础设施；Visa Direct 的实际资金可用时间还取决于收款机构、账户类型、地区与合规流程。产品定价应按实际通道成本和服务条款设计。
「毕业」是重新选择责任结构
规模增长后，企业可以继续使用赞助关系、把部分能力转成直接合同，或在特定司法辖区申请自己的许可。
收单侧的 USD 1 million规则展示了第二种路径：Sponsored Merchant 与 Acquirer 建立直接协议，PayFac 仍可保留技术、运营和结算服务。发卡侧没有一个统一交易量数字会自动触发银行牌照申请，企业要根据产品控制权、资本与流动性、监管成本、地域扩张和合作稳定性决定。
现有公司也没有走同一条路线。Chime 继续公开披露合作银行；Monzo 当前合同主体是 Monzo Bank Limited；Revolut 的英国页面同时列出受 PRA/FCA 监管的 Revolut Bank UK Ltd 与获准发行电子货币的 Revolut Ltd。讨论一家 Fintech 是否「已经成为银行」时，必须落到具体国家、法律实体和产品，不能把英国、欧洲与美国合并成一张牌照。
