从 90 万投资者到停止运营：为什么用户增长不能验证金融 PF？
当平台控制全部数据，金融系统该如何建立可验证信任？
9%—14.6% 回报承诺背后：金融产品应先设计哪些证据链？
不可篡改不等于真实：从 e租宝看区块链能与不能解决的问题
一句导语
e租宝在 18 个月内聚集约 90 万投资者，页面披露其中 95% 的项目为虚构项目。 这个案例不是一次常规的产品失败，而是在提醒开发者：金融系统的核心能力不是把数字展示得可信，而是让数字背后的事实可以被独立验证。
Lumi & Nox 对话
👧 Lumi：开发者很容易被“18 个月、90 万投资者”吸引，因为它像一组漂亮的增长指标。可页面同时披露 95% 的项目是虚构的。数据没有错，错的是我们默认它代表价值被验证。
🐈 Nox：那金融产品真正的技术问题，或许不是怎样承载更多用户，而是怎样让任何一笔资产都不能只靠平台自己证明？
📦 今日案例
- 产品是什么： 2014 年成立的 e租宝，一家面向个人投资者的 P2P 借贷平台，展示基础设施与融资租赁项目。
- 为什么做： 平台以 9%—14.6% 的年化回报吸引资金，把产品包装为银行存款之外的投资选择。
- 面向谁： 寻找更高储蓄回报的中国个人投资者。
- 解决什么问题： 表面上连接个人资金与借款、租赁项目；页面披露，95% 的项目为虚构项目，新资金被用于向早期投资者支付回报。
案例时间线：增长指标如何失去产品意义
- 2014 年： e租宝成立。
- 随后 18 个月： 平台聚集约 90 万投资者，宣传 9%—14.6% 的年化回报。
- 运营期间： 页面披露 95% 的上线项目为虚构项目，包括虚构借款人、抵押物与融资租赁合同。
- 2015 年末： 页面记载，增长放缓后，平台无法满足提现需求。
- 2015 年 12 月： 警方查处办公场所，运营被冻结。
- 2016 年： 页面将其列为结束年份，并标注 76 亿美元涉案资金规模。
🔍 真正的问题：系统展示了数据，却没有建立证据链
先排除一个错误框架：e租宝不是因为留存、转化或技术扩展性不够而失败。页面将其定义为从一开始运行的庞氏骗局。新投资者的资金被用于向早期投资者支付回报，95% 的项目被披露为虚构。这里的核心不是增长优化，而是系统性欺骗。
业务记录不等于可验证事实
一个平台可以为每个项目建立完整的数据表：借款人、合同编号、抵押物、收益率和到期日。可如果所有字段都由同一平台创建、修改并解释，这些记录只能证明“系统里存在一条数据”，不能证明现实世界中存在对应资产。
页面记载，e租宝投资者无法看到可核验的借款合同、借款人身份或抵押证明，平台控制全部数据。我认为，对金融产品而言，database row exists 与 asset exists 之间必须有独立证据：外部身份源、合同权属、托管资金、审计结果和明确责任主体。缺少其中任何一层，都不应由更漂亮的前端状态弥补。
用户增长不能替代金融 PMF
18 个月内约 90 万投资者，是页面披露的规模事实。但这个数字不能证明产品具有健康的 PMF：它没有回答底层资产是否真实、回报来自哪里、违约损失由谁承担，也没有回答用户是否在信息充分的情况下作出选择。
页面指出，这套结构用后来者资金支付早期回报，需要持续获得新资金。我认为，在这种模型中，新增用户不是价值交付的结果指标，而是资金循环继续运行的条件。把它放进普通增长漏斗，会让团队忽略业务语义。指标设计必须从系统约束出发：对于金融产品，资产核验率、托管覆盖率、异常资金流和审计差异，通常比注册数更接近真实风险。
高回报应触发控制，而不是只触发转化优化
页面给出的同期银行存款利率为 2%—3%，e租宝宣传回报为 9%—14.6%。两者并非同风险产品，不能直接当作性能基准；但显著的回报差距至少应该触发更强的风险披露与资产审查。
有一种可能是，当产品团队只优化“回报数字 → 点击 → 入金”的转化路径时，风险提示会被视为摩擦。对高风险系统，某些摩擦本来就是安全能力：冷静期、适当性判断、二次确认、独立托管与人工复核可能降低转化，却能防止系统把不确定性藏起来。
区块链无法替代入口真实性
页面的重建设想提到区块链和不可篡改记录，但那是未来方案，不是 e租宝已实现的能力。我认为，这里最需要警惕“上链即可信”的误解：哈希可以证明一段数据之后没有被改，却不能证明录入时的借款人、合同和抵押物真实存在。
如果现实核验仍由利益相关方单独完成，区块链只会永久保存一条未经证实的记录。更合理的顺序是先明确谁验证、谁担责、谁托管资金，再判断不可篡改日志是否能减少多方协作成本。
最值得学习的三个地方
-
我认为，应该把证据链当作领域模型的一部分。 金融资产不只是一个
Asset对象，还应包含证据来源、验证主体、验证时间、失效条件与审计状态。e租宝案例里，平台控制全部数据，说明“字段齐全”不能替代“来源独立”。 -
这个案例提醒我们，指标必须带着业务语义使用。 约 90 万投资者只能描述规模，不能证明 PMF、合规或资产质量。开发增长看板时，必须同时展示限制条件与风险指标，否则系统会奖励错误目标。
-
或许，关键控制应该由架构保证，而不是靠运营承诺。 资金托管、角色分权、不可单方修改的审计日志、异常检测和第三方复核，应形成相互制约。具体控制强度需要持牌机构与专业合规人员确定，现有信息没有给出完整方案。
如果重新做：先做最小可信系统
以下全部是分析设想，不是来源事实，也不是对原业务的恢复建议。
我不会从一个“面向所有人的高收益平台”开始，而会把范围缩到一种可核验资产，并只与持牌机构合作。最小可信系统至少需要：资金由独立机构托管；资产上传者不能同时完成最终审核；每次验证保留来源、责任主体和时间；任何收益展示同时关联风险与可能损失；审计方拥有不依赖业务后台的读取路径。
技术选择保持克制。普通关系数据库、追加式审计日志、细粒度权限和第三方对账已经能覆盖许多核心要求。只有在多机构共同写入、彼此不完全信任且治理规则明确时，才评估分布式账本。否则，引入区块链可能只是增加复杂度，并没有解决“入口数据谁来证明”的根问题。
最小验证指标也不该先看 DAU，而应看：资产是否全部有独立证据、资金是否全部托管、异常是否能被外部发现、用户是否看见真实损失路径。至于目标值和监管阈值，现有信息未披露，不能凭案例补写。
🌱 Lumi 的笔记
我认为，可信系统不是把平台的话永久保存，而是让平台也无法绕过别人可以核验的事实。
🐈 Nox 的问题
如果你要为一款金融产品设计“最小可信系统”，你会把哪一项外部验证设为所有交易都不能绕过的前置条件？
如果这次拆解对你有帮助，欢迎点赞并关注 Lumi & Nox。
标签： 金融科技、系统设计、数据治理、产品设计、区块链
