Arch Day 6: 商业模式架构 — 牌照、平台与网络效应

日期: 2026-04-04 阶段: 第一阶段 - 架构基础 标签: #商业模式 #BMC #平台经济 #金融牌照 #网络效应

---

核心概念

一句话定义

商业模式架构不是"填一张Business Model Canvas"，而是理解商业模式的底层约束(牌照、监管、网络效应)如何决定技术架构的边界和可能性 — 在金融行业，牌照类型决定了你能做什么业务，监管要求决定了架构必须满足什么约束，网络效应决定了平台的增长飞轮。

为什么资深架构师仍需关注

1. 架构不是技术孤岛: 如果不理解商业模式，架构师就会设计出"技术上完美但商业上不可行"的方案
2. 牌照约束是最硬的架构约束: 在金融行业，比技术约束更硬的是牌照约束——你没有支付牌照就不能做资金清算，架构再好也没用
3. 平台架构需要理解网络效应: 双边市场(如支付平台、借贷平台)的架构设计需要理解"鸡和蛋"问题
4. 商业模式决定系统边界: 你是做SaaS还是做平台？是自营还是代销？这些商业模式决策直接影响系统架构

常见误区与反模式

---

知识点详解

知识点1: Business Model Canvas在金融行业的适配

标准的BMC有9个模块。在金融行业，需要做以下适配：

金融BMC增强版(11个模块)

标准BMC(9个模块):
┌─────────┬─────────┬────────┬─────────┬─────────┐
│ Key     │ Key     │ Value  │ Customer│ Customer│
│Partners │Activities│Proposit│Relation │ Segments│
│         │         │        │         │         │
├─────────┼─────────┤        ├─────────┼─────────┤
│ Key     │         │        │         │         │
│Resources│         │        │ Channels│         │
│         │         │        │         │         │
├─────────┴─────────┴────────┴─────────┴─────────┤
│ Cost Structure              │ Revenue Streams   │
└─────────────────────────────┴───────────────────┘

金融增强版(+2个模块):
┌──────────────────────────────────────────────────┐
│ +模块10: 牌照与合规(Licenses & Compliance)         │
│   - 持有哪些牌照？                                 │
│   - 受哪些监管约束？                               │
│   - 合规成本占比？                                 │
├──────────────────────────────────────────────────┤
│ +模块11: 风险管理(Risk Management)                 │
│   - 承担什么风险？(信用/市场/操作)                  │
│   - 风险准备金要求？                               │
│   - 风险转移机制？(保险/对冲)                      │
└──────────────────────────────────────────────────┘

金融BMC填写要点

Value Proposition(价值主张)的金融特殊性:

Revenue Streams(收入来源)的金融典型模式:

金融收入模式分类:

1. 利差收入(Net Interest Income):
   银行吸收存款(付利息) → 发放贷款(收利息) → 利差=收入
   架构影响: 需要存贷款管理、利率定价引擎

2. 手续费收入(Fee Income):
   交易手续费、管理费、顾问费等
   架构影响: 需要灵活的费率管理和计费引擎

3. 交易收入(Trading Revenue):
   做市利润、汇率差价等
   架构影响: 需要实时定价引擎、头寸管理

4. 平台分润(Platform Revenue):
   代销产品的佣金、流量分成等
   架构影响: 需要产品货架、分润计算引擎

5. 数据收入(Data Revenue):
   信用评分服务、数据分析服务
   架构影响: 需要数据产品化平台
   合规注意: 数据使用必须合规(征信牌照等)

6. 订阅收入(Subscription):
   会员服务、SaaS订阅
   架构影响: 需要会员体系、订阅管理

知识点2: 金融牌照对架构的影响(核心知识)

**这是金融架构师最需要理解的非技术约束。**牌照决定了你的系统边界——哪些业务可以做，哪些功能必须有，哪些数据必须保留。

主要金融牌照类型与架构约束

牌照约束→架构约束的映射

以支付牌照为例:

牌照要求 → 架构约束

1. "备付金100%存管于央行"
   → 架构必须: 与央行备付金系统对接
   → 资金流: 客户→支付机构→央行(不能挪用)
   → 系统需求: 实时备付金核对系统

2. "反洗钱义务"
   → 架构必须: AML系统(实时监控+可疑报告)
   → 数据需求: 客户身份信息、交易记录保留5年
   → 系统需求: 与央行反洗钱中心报送系统对接

3. "交易限额"
   → 架构必须: 限额管理引擎(日限额/月限额/年限额)
   → 每种支付方式有不同的限额
   → 系统需求: 实时限额校验

4. "数据本地化(如适用)"
   → 架构约束: 数据不能出境
   → 部署需求: 境内数据中心
   → 系统设计: 多区域部署时的数据隔离

5. "业务连续性"
   → 架构约束: RPO<1h, RTO<4h(监管最低要求)
   → 部署需求: 同城双活/异地灾备
   → 系统设计: 高可用架构

无牌照时的架构策略

如果没有金融牌照但想做金融业务:

策略1: 助贷模式(Referral)
  "我推荐客户，银行放贷"
  架构: 只做前端获客和风控评估，不碰资金
  系统边界: 客户端→风控引擎→银行API(资金在银行)
  收入: 推荐费/服务费

策略2: 导流模式(Traffic)
  "我提供流量，金融机构提供产品"
  架构: 只做产品展示和用户匹配
  系统边界: 客户端→产品货架→金融机构跳转
  收入: CPA(按获客付费)

策略3: SaaS模式(Technology)
  "我提供技术系统，金融机构自己运营"
  架构: 标准化SaaS平台(多租户)
  系统边界: 不碰资金和客户数据(或仅代理)
  收入: SaaS订阅费

策略4: 合作持牌(Joint Venture)
  "与持牌机构合资设立新公司"
  架构: 完整系统但合规由合作方把关
  收入: 利润分成

最危险的做法:
❌ 无牌照做资金池(违法)
❌ 无牌照做P2P(已全面清退)
❌ 用虚拟货币绕过牌照(监管风险极高)

知识点3: 平台商业模式与网络效应

平台类型分类

金融平台类型:

1. 交易平台(Transaction Platform):
   连接买卖双方，撮合交易
   例: 支付宝(商户↔消费者)、券商(买家↔卖家)
   收入: 交易手续费
   网络效应: 跨边(更多商户→更多消费者→更多商户)

2. 创新平台(Innovation Platform):
   提供基础能力，第三方在上面开发
   例: 蚂蚁开放平台(ISV在上面开发)、Stripe Connect
   收入: API调用费/分润
   网络效应: 跨边(更多能力→更多ISV→更多终端用户)

3. 信息平台(Information Platform):
   聚合和分发信息
   例: 天天基金(基金信息)、东方财富(股票信息)
   收入: 广告/代销佣金/会员
   网络效应: 同边(更多内容→更多用户→更多内容)

4. 混合平台:
   同时具备多种平台特征
   例: 蚂蚁(交易+创新+信息)

网络效应详解

跨边网络效应(Cross-side):
  定义: A边用户增加 → B边用户价值增加
  例: 支付宝商户越多 → 消费者越愿意用
  架构影响: 需要同时服务两边，且两边的体验都要好

同边网络效应(Same-side):
  定义: 同一边用户增加 → 同一边用户价值增加
  例: 社交网络(微信)越多人用越有价值
  负同边效应: 同类商户越多 → 竞争越激烈(外卖平台的餐厅)

本地网络效应:
  定义: 网络效应限于地理区域
  例: 打车平台(只有本地的司机和乘客有关)
  架构影响: 多区域部署、区域化运营

数据网络效应:
  定义: 用户越多 → 数据越多 → 产品越好 → 用户更多
  例: 风控模型(数据越多→模型越准→用户体验越好)
  架构影响: 数据飞轮设计(采集→训练→优化→采集)

平台冷启动策略(金融场景)

金融平台的"鸡和蛋"问题:

问题: 没有商户→消费者不用→商户不来

冷启动策略:

1. 补贴一方(Subsidy):
   补贴商户零手续费 → 吸引商户 → 用户跟来
   例: 支付宝早期免费让淘宝商户接入
   架构: 需要灵活的费率管理(区分补贴期和正常期)

2. 自营启动(Seeding):
   先做自营业务积累用户 → 再开放平台
   例: 京东先做自营电商 → 再开放第三方商家
   架构: 需要支持自营→平台的架构演进

3. 单边价值(Single-side Value):
   先给一边提供独立于平台的价值
   例: Stripe先提供支付API(开发者工具价值) → 再做平台
   架构: 核心API必须独立于平台逻辑

4. 大客户策略(Marquee User):
   先签大客户(有号召力的) → 其他跟进
   例: 先接入头部银行到Open Banking平台
   架构: 需要支持大客户定制而不影响标准化

知识点4: Platform Canvas(平台画布)

Platform Canvas是BMC的平台增强版，增加了平台特有的设计要素:

Platform Canvas结构:

┌─────────────────────────────────────────────────┐
│              平台愿景(Platform Vision)             │
├────────────┬──────────────┬─────────────────────┤
│ 生产者侧   │   核心交互    │   消费者侧          │
│ (Producer) │(Core Inter.) │   (Consumer)        │
├────────────┼──────────────┼─────────────────────┤
│ 生产者画像  │ 价值单元     │ 消费者画像          │
│ 生产者激励  │ 筛选机制     │ 消费者激励          │
│ 生产者工具  │ 信任机制     │ 消费者工具          │
├────────────┼──────────────┼─────────────────────┤
│            │ 平台治理规则  │                     │
│            │ 网络效应设计  │                     │
│            │ 数据策略     │                     │
├────────────┴──────────────┴─────────────────────┤
│ 平台基础设施(Architecture & APIs)                 │
├─────────────────────────────────────────────────┤
│ 盈利模式(Monetization)  │ 增长策略(Growth)      │
└─────────────────────────┴───────────────────────┘

---

对比分析

Stripe / 蚂蚁 / Nubank 商业模式对比

牌照与监管约束对架构的影响分析

Stripe的牌照策略与架构:

Stripe的牌照版图:
- 美国: Money Service Business (MSB)
- 欧盟: E-Money License (爱尔兰)
- 英国: E-Money License
- 日本: Payment Service Provider
- ...40+国家的支付牌照

架构影响:
1. 多国牌照 → 每个国家有不同的合规要求
   → 架构需要: 合规规则引擎(按国家配置)
2. 只有支付牌照 → 不能做存贷款
   → 架构选择: Stripe Treasury(与银行合作)
   → 系统边界: 资金由银行托管，Stripe只做技术
3. PCI-DSS合规 → 卡数据处理有严格要求
   → 架构需要: 独立的卡数据安全域(Tokenization)

蚂蚁的牌照策略与架构:

蚂蚁的牌照版图(受监管整改后):
- 支付: 支付宝(支付牌照)
- 银行: 网商银行(民营银行牌照)
- 保险: 相互宝(保险牌照)
- 基金: 天弘基金(基金管理)
- 征信: 芝麻信用(征信牌照)
- 小贷: 花呗/借呗(小贷牌照→消金牌照)

架构影响:
1. 多牌照 → 每个牌照是独立法律实体
   → 架构需要: 集团级统一平台 + 各牌照独立系统
   → 数据隔离: 不同牌照的数据不能随意共享
2. 监管整改 → 要求将金融业务纳入金控集团
   → 架构变更: 从"技术公司做金融"到"金控公司用技术"
   → 系统改造: 资本充足率计算、并表监管报表
3. 花呗/借呗联合贷款模式被限制
   → 架构变更: 从联合贷款到助贷模式
   → 系统改造: 资金来源从ABS变为银行自有资金

Nubank的牌照策略与架构:

Nubank的牌照策略:
- 2013: 信用卡服务(支付机构牌照)
- 2018: 获得银行牌照(数字银行)
- 此后: 投资服务、保险等

架构影响:
1. 先支付后银行 → 架构分阶段演进
   → Phase 1: 轻量级信用卡系统
   → Phase 2: 全功能核心银行系统
   → 关键: Phase 1的架构必须能平滑升级到Phase 2

2. 巴西本地监管(央行PIX即时支付系统)
   → 架构必须: 接入PIX(巴西央行即时支付)
   → 优势: PIX让Nubank的转账体验与大行持平

3. 低成本策略 → 纯线上运营
   → 架构选择: 全云原生(AWS)
   → 无分行系统、无ATM管理、无现金处理
   → 运营成本是传统银行的1/5

商业模式对架构模式的映射

---

架构设计实操

实操: 解剖Stripe商业模式→分析牌照约束→推导架构需求

设计目标

以Stripe为蓝本，分析"支付基础设施"商业模式如何决定技术架构。

设计方案

Step 1: Stripe Business Model Canvas

┌────────────────────────────────────────────────────────┐
│ Key Partners:           │ Value Proposition:            │
│ - 银行(资金托管)         │ "让互联网商业的支付像写几行    │
│ - 卡组织(Visa/MC)       │  代码一样简单"                │
│ - 合规供应商(KYC/AML)   │                              │
│ - 云厂商(AWS)           │ - 7行代码接入支付             │
│                         │ - 135+货币支持                │
│ Key Activities:         │ - 99.999%可用性              │
│ - API开发与维护          │ - 全球合规覆盖               │
│ - 合规管理(40+国家)     │                              │
│ - 风控(欺诈检测)        │ Customer Relationships:       │
│ - 开发者社区            │ - 自助(文档+Dashboard)        │
│                         │ - 技术支持                    │
│ Key Resources:          │ - 开发者社区                  │
│ - 工程团队              │                              │
│ - 40+国家牌照          │ Channels:                     │
│ - 开发者品牌            │ - 官网/文档                   │
│ - 支付网络              │ - GitHub/开源                 │
│                         │ - 开发者大会                  │
├─────────────────────────┼──────────────────────────────┤
│ Cost Structure:         │ Revenue Streams:              │
│ - 工程人力(60%?)       │ - 交易手续费: 2.9%+$0.30     │
│ - 合规成本(牌照维护)    │ - 附加服务: Radar(欺诈检测)   │
│ - 云基础设施            │          Connect(平台分润)     │
│ - 银行通道费用          │          Atlas(公司注册)       │
│                         │          Treasury(银行服务)     │
├─────────────────────────┴──────────────────────────────┤
│ Licenses & Compliance:                                  │
│ - 40+国家支付牌照(MSB/EMI/PSP)                        │
│ - PCI-DSS Level 1(最高等级)                            │
│ - 各国数据本地化要求(GDPR/巴西LGPD等)                  │
├─────────────────────────────────────────────────────────┤
│ Risk Management:                                        │
│ - 交易欺诈风险(Stripe Radar)                           │
│ - 商户违规风险(KYB审核)                                │
│ - 外汇风险(多币种结算)                                  │
│ - 合规风险(40+监管域)                                  │
└─────────────────────────────────────────────────────────┘

Step 2: 从商业模式推导架构需求

商业模式特征 → 架构需求:

1. "API-First" 价值主张
   → 架构需求:
   - API Gateway(统一入口、限流、认证)
   - API版本管理(不能break现有客户)
   - SDK(7种语言)
   - Webhook(异步通知)
   - 沙箱环境(测试环境)

2. "40+国家"
   → 架构需求:
   - 多国支付通道适配(每国不同的银行/卡组织接口)
   - 合规规则引擎(每国不同的KYC/AML要求)
   - 多币种计算引擎
   - 数据本地化(某些国家数据不能出境)
   - 多区域部署

3. "99.999%可用性"
   → 架构需求:
   - 多活部署(至少3个Region)
   - 无状态服务+分布式状态管理
   - 优雅降级(核心支付>非核心功能)
   - 混沌工程(持续验证高可用)

4. "PCI-DSS Level 1"
   → 架构需求:
   - 独立的卡数据处理安全域(CDE)
   - Tokenization(卡号→Token)
   - 加密传输和存储
   - 严格的访问控制和审计日志
   - 年度安全审计

5. "平台模式(Stripe Connect)"
   → 架构需求:
   - 多层级账户体系(平台→子商户)
   - 资金分账(平台分润→商户结算)
   - 合规传递(平台的KYB→子商户的KYB)
   - 多角色Dashboard

Step 3: 架构概览(基于商业模式推导)

Stripe推导架构:

客户(开发者)
    │
    ▼
┌──────────────┐
│ API Gateway  │ ← SDK/Dashboard/Webhook
│ (多区域)     │
└──────┬───────┘
       │
┌──────┴───────────────────────────────┐
│           核心服务层                   │
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐│
│ │支付  │ │商户  │ │风控  │ │合规  ││
│ │引擎  │ │管理  │ │引擎  │ │引擎  ││
│ │      │ │(KYB) │ │(Radar)│ │(AML) ││
│ └──────┘ └──────┘ └──────┘ └──────┘│
│ ┌──────┐ ┌──────┐ ┌──────┐         │
│ │计费  │ │分账  │ │多币种│         │
│ │引擎  │ │引擎  │ │引擎  │         │
│ └──────┘ └──────┘ └──────┘         │
└──────────────────┬───────────────────┘
                   │
┌──────────────────┴───────────────────┐
│           通道适配层                   │
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐│
│ │Visa  │ │银行  │ │本地  │ │SWIFT ││
│ │/MC   │ │直连  │ │支付  │ │      ││
│ └──────┘ └──────┘ └──────┘ └──────┘│
└──────────────────────────────────────┘
                   │
           ┌───────┴───────┐
           │  安全域(CDE)   │ ← PCI-DSS隔离
           │  卡号存储/Token│
           └───────────────┘

ADR

ADR-006: 支付平台商业模式决定的架构约束

状态: 分析完成
日期: 2026-04-04

背景:
分析Stripe类支付平台商业模式对技术架构的约束。

关键架构约束(由商业模式决定):

1. API-First → 所有功能必须通过API暴露，不能有"只有Dashboard能做"的功能
2. 多国合规 → 合规逻辑必须配置化(不能硬编码某个国家的规则)
3. PCI-DSS → 卡数据必须物理隔离在安全域中
4. 平台模式 → 必须支持多层级账户和资金分账
5. 高可用 → 核心支付链路不依赖任何单点

架构原则:
- 合规即代码(Compliance as Code)
- 安全域隔离(Security Zone Isolation)
- 通道可插拔(Channel Adapter Pattern)
- 状态机驱动(支付状态机管理生命周期)

权衡取舍

---

AI增强实践

本日AI提效方法

1. 商业模式分析: AI快速分析目标公司的财报、产品页面，生成BMC初稿
2. 牌照约束查询: AI查询特定国家的金融牌照要求和架构约束
3. 竞品模式对比: AI并行分析多个竞品的商业模式差异

AI辅助的具体Prompt示例

Prompt 1: 商业模式分析

请帮我分析Nubank的商业模式，使用金融增强版BMC(11模块)。

要求:
1. 标准9个BMC模块
2. 增加"牌照与合规"模块(Nubank在巴西持有哪些牌照？受什么监管？)
3. 增加"风险管理"模块(Nubank承担什么风险？如何管理？)

特别关注:
- Nubank的收入结构(利差 vs 手续费 vs 其他)
- 巴西央行PIX系统对Nubank的影响
- Nubank相比Itaú等传统银行的成本优势来源
- 牌照获取路径对产品上线顺序的影响

请基于公开信息(财报、产品页面、新闻报道)进行分析。

Prompt 2: 牌照-架构映射

我正在设计一个面向东南亚市场的数字支付平台。
目标市场: 印尼、泰国、菲律宾、越南

请帮我分析:
1. 每个国家做电子钱包需要什么牌照？
2. 每种牌照对系统架构有什么具体要求？
   (如: 数据本地化、备付金管理、报送接口等)
3. 各国牌照的申请难度和时间
4. 如果暂时拿不到牌照，有哪些合规替代方案？
5. 各国之间的监管差异对统一技术平台的挑战

请给出具体的、可操作的信息。

AI生成 vs 人工判断的边界

---

与Web3/DeFi的关联

深度思考: DeFi的"牌照等价物"是什么？

传统金融的牌照 → 保证了:
1. 最低资本金(安全垫)
2. 合规运营(消费者保护)
3. 信息披露(透明度)
4. 审计要求(可信度)

DeFi的"牌照等价物":
1. 智能合约审计 ≈ 合规运营认证
2. TVL(锁仓量) ≈ 资本金(但不完全等价)
3. 开源代码 ≈ 信息披露
4. Bug Bounty ≈ 持续安全审查
5. 治理代币 ≈ 牌照持有(某种意义上)

但缺少的:
- 消费者保护(用户资金丢失无法追索)
- 系统性风险管理(没有"央行"兜底)
- 反洗钱合规(Permissionless的代价)

---

今日思考

思考1: 为什么"金融科技公司"和"科技金融公司"的架构完全不同？

核心区别在于谁持有牌照：

• 金融科技公司(FinTech): 自己持牌，用技术做金融 → 架构必须满足监管要求
• 科技金融公司(TechFin): 不持牌，给金融机构提供技术 → 架构关注多租户、API标准化

蚂蚁从TechFin被要求转型为FinTech(金控)，其架构也随之发生了根本性变化——从"轻资产平台"变为"持牌金融机构"。

思考2: 嵌入式金融(Embedded Finance)对架构的影响是什么？

嵌入式金融是将金融能力(支付、贷款、保险)嵌入到非金融场景中(电商、SaaS、出行)。这对架构的影响是：

1. 金融能力必须API化、模块化、可嵌入
2. 需要支持白标(White Label) — 用户看到的是宿主品牌不是金融品牌
3. 合规传递 — 即使嵌入到第三方场景，合规责任仍在金融机构

这是Stripe Treasury、Stripe Connect成功的核心——让任何公司都能"嵌入"支付和金融服务。

思考3: Web3会如何改变金融商业模式？

Web3对金融商业模式的三个根本性影响：

1. 去牌照化: Permissionless让任何人都能"开银行"(DeFi协议)，但也带来了监管真空
2. 去中介化: 协议取代平台，费用从公司利润变为协议参数(社区投票决定)
3. 可组合性: DeFi协议像乐高一样可以组合，创造了传统金融不可能的产品(如Flash Loan)

但这不意味着传统金融会被取代——更可能的是融合: 持牌机构使用区块链技术，DeFi协议逐步合规化。

---

面试题准备

Q1: 金融牌照如何影响产品架构？

30秒版本: 金融牌照从三个层面约束架构：一是业务边界(牌照决定能做什么不能做什么)；二是合规要求(AML/KYC/数据本地化等必须在架构中实现)；三是风险管理(资本充足率、备付金管理等需要专门的系统支撑)。如果没有牌照，架构设计必须确保"不碰资金"(助贷模式)或"不接触客户数据"(纯技术输出)。

2分钟版本:

金融牌照对架构的影响分四个层面：

第一层是系统边界。不同牌照决定了系统能处理什么业务。有支付牌照→可以做资金清算；有银行牌照→可以做存贷款；有证券牌照→可以做交易。系统架构的边界必须与牌照边界一致。例如Stripe只有支付牌照，所以Stripe Treasury的资金实际由银行托管，Stripe的系统只处理技术层面。

第二层是合规功能。每种牌照都有强制性的合规要求。支付牌照→必须有AML系统和备付金管理；银行牌照→必须有资本充足率计算和监管报送；证券牌照→必须有适当性管理和信息隔离(Chinese Wall)。这些不是"可选功能"，是系统上线前必须具备的。

第三层是数据治理。多牌照金融集团(如蚂蚁)面临一个特殊的架构挑战：不同牌照实体的数据不能随意共享。支付数据不能直接给借贷用，除非有客户授权。这要求架构层面做数据隔离和授权管理。

第四层是部署架构。某些监管要求数据本地化(如中国的数据不能出境)，这直接影响云部署策略。有些要求同城双活和异地灾备，这影响高可用架构设计。

我的经验是：架构师在做方案之前，第一件事应该是和合规团队对齐牌照约束。很多架构方案技术上完美，但因为违反牌照约束而无法落地。

追问准备:

• 追问: 如果公司在申请牌照过程中，架构应该怎么设计？ → 架构预留合规能力(如AML接口)，但先以"不碰资金"的模式上线，拿到牌照后切换
• 追问: 多国牌照对技术架构的最大挑战是什么？ → 合规规则的配置化——不能为每个国家硬编码规则，必须用规则引擎支持动态配置

Q2: 如何分析一个金融科技公司的商业模式？

30秒版本: 我用"金融增强版BMC"(11个模块)来分析：标准9个模块加上"牌照与合规"和"风险管理"。重点关注四个问题：它靠什么赚钱(收入模式)？它有什么牌照(业务边界)？它的网络效应是什么(增长飞轮)？它承担什么风险(商业模式可持续性)？

2分钟版本:

(展开四个关键问题的分析框架，结合Stripe/蚂蚁/Nubank的实际案例)

追问准备:

• 追问: 你最看好什么类型的金融科技商业模式？ → 嵌入式金融(Embedded Finance)——因为它让金融能力变成了"基础设施"，市场空间远大于直接面客
• 追问: DeFi算金融科技吗？ → 广义上算，但商业模式根本不同——DeFi是协议而非公司，收入归社区而非股东

---

学习资源

---

明日预告

Day 7: Week1综合实战 — 综合运用本周所有工具(TOGAF、能力建模、价值流、流程架构、Wardley Map、商业模式)做一次完整的"从战略到架构"推导。选择一个真实金融/零售业务场景，从Wardley Map→能力建模→价值流→流程→系统架构需求，完成端到端的架构分析。输出Week1个人方法论工具箱和能力自评。