Arch Day 37: 开放银行（Open Banking）

日期: 2026-05-06 (Day 37) 阶段: 第二阶段 - 金融域深度 标签: #开放银行 #PSD2 #BaaS #API网关 #FAPI #嵌入式金融

---

核心概念

一句话定义

开放银行（Open Banking）是一种监管驱动的架构范式变革——银行通过标准化API将账户数据和支付能力安全地开放给经授权的第三方，使金融服务从银行的"封闭花园"走向"开放生态"，催生了BaaS（Banking-as-a-Service）和嵌入式金融（Embedded Finance）等全新商业模式。

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

1. 开放银行正在重新定义银行的技术架构边界：银行不再是唯一的用户入口，API平台成为新的核心基础设施
2. BaaS是金融科技最热门的赛道之一：Stripe Treasury、Marqeta、Synapse等BaaS平台估值数百亿美元
3. API安全在金融场景有极其特殊的要求：FAPI（Financial-grade API）标准远比一般API安全复杂
4. 开放银行是CeFi走向DeFi的"过渡架构"：银行API开放 → BaaS → 嵌入式金融 → 链上金融，是一条清晰的演进路径
5. 中国的"互联互通"政策（支付/征信开放）本质上就是中国版Open Banking

常见误区与反模式

---

知识点详解

1. PSD2/Open Banking标准：监管驱动的架构变革

全球开放银行监管地图：

PSD2核心要求：

graph TB
    subgraph "PSD2 两大核心义务"
        A1["AIS - 账户信息服务<br/>Account Information Service<br/>────────<br/>银行必须允许<br/>授权第三方(AISP)<br/>读取客户账户数据"]

        A2["PIS - 支付发起服务<br/>Payment Initiation Service<br/>────────<br/>银行必须允许<br/>授权第三方(PISP)<br/>代表客户发起支付"]
    end

    subgraph "安全要求"
        S1["SCA - 强客户认证<br/>Strong Customer Authentication<br/>────────<br/>必须使用2个以上因素:<br/>知道的(密码)<br/>拥有的(手机)<br/>固有的(指纹)"]

        S2["动态链接<br/>Dynamic Linking<br/>────────<br/>认证与特定<br/>交易金额/收款方绑定"]
    end

    subgraph "第三方角色"
        R1["AISP<br/>账户信息服务商<br/>如: 记账APP"]
        R2["PISP<br/>支付发起服务商<br/>如: 电商平台"]
        R3["ASPSP<br/>提供账户的<br/>支付服务商(银行)"]
    end

    A1 --> R1
    A2 --> R2
    R1 & R2 --> R3
    S1 & S2 --> R3

2. Open Banking API标准

三大API标准对比：

UK Open Banking API结构示例：

// 账户信息 API
interface AccountsAPI {
  // GET /accounts
  listAccounts(): Account[];

  // GET /accounts/{accountId}
  getAccount(accountId: string): Account;

  // GET /accounts/{accountId}/balances
  getBalances(accountId: string): Balance[];

  // GET /accounts/{accountId}/transactions
  getTransactions(
    accountId: string,
    fromDate?: Date,
    toDate?: Date
  ): Transaction[];
}

// 支付发起 API
interface PaymentInitiationAPI {
  // POST /domestic-payments
  createDomesticPayment(request: DomesticPaymentRequest): PaymentResponse;

  // GET /domestic-payments/{paymentId}
  getPaymentStatus(paymentId: string): PaymentStatus;
}

// 授权 API (Consent)
interface ConsentAPI {
  // POST /account-access-consents
  createConsent(request: ConsentRequest): ConsentResponse;

  // GET /account-access-consents/{consentId}
  getConsent(consentId: string): ConsentStatus;

  // DELETE /account-access-consents/{consentId}
  revokeConsent(consentId: string): void;
}

// 数据模型
interface Account {
  accountId: string;
  currency: string;
  accountType: 'Personal' | 'Business';
  accountSubType: 'CurrentAccount' | 'SavingsAccount' | 'CreditCard';
  description: string;
  nickname?: string;
  account: {
    schemeName: 'UK.OBIE.SortCodeAccountNumber';
    identification: string;  // 排序码+账号
    name: string;
  };
}

interface ConsentRequest {
  permissions: Permission[];  // ReadAccountsBasic, ReadBalances, ReadTransactionsDetail, etc.
  expirationDateTime: Date;   // 授权有效期
  transactionFromDateTime?: Date;
  transactionToDateTime?: Date;
}

type Permission =
  | 'ReadAccountsBasic'
  | 'ReadAccountsDetail'
  | 'ReadBalances'
  | 'ReadTransactionsBasic'
  | 'ReadTransactionsCredits'
  | 'ReadTransactionsDebits'
  | 'ReadTransactionsDetail';

3. BaaS（Banking-as-a-Service）商业模式和架构

graph TB
    subgraph "BaaS 架构层级"
        L1["嵌入式金融应用<br/>──────────<br/>电商平台 / SaaS软件<br/>/ 出行平台 / 社交APP"]

        L2["BaaS平台 / API聚合层<br/>──────────<br/>Stripe Treasury / Unit<br/>/ Marqeta / 国内: 新网银行API"]

        L3["持牌银行 / 金融基础设施<br/>──────────<br/>实际的银行牌照持有者<br/>提供账户/支付/贷款能力"]

        L4["监管 / 清算基础设施<br/>──────────<br/>央行 / CNAPS / VISA/MC"]
    end

    L1 -->|"API调用"| L2
    L2 -->|"API调用"| L3
    L3 -->|"清算/报送"| L4

BaaS生态中的角色和价值链：

BaaS vs 传统银行 vs 开放银行：

4. API Gateway在开放银行中的角色

graph TB
    subgraph "外部请求"
        TPP1[AISP<br/>记账APP]
        TPP2[PISP<br/>电商平台]
        TPP3[开发者<br/>沙盒测试]
    end

    subgraph "API Gateway 核心能力"
        GW[API Gateway]

        GW --> A["认证 Authentication<br/>──────────<br/>mTLS (双向证书)<br/>+ OAuth2 Access Token<br/>+ FAPI合规"]

        GW --> B["授权 Authorization<br/>──────────<br/>Consent验证<br/>Scope检查<br/>数据最小化"]

        GW --> C["限流 Rate Limiting<br/>──────────<br/>按TPP粒度限流<br/>按API粒度限流<br/>突发流量保护"]

        GW --> D["路由 Routing<br/>──────────<br/>API版本路由<br/>A/B测试<br/>灰度发布"]

        GW --> E["计费 Metering<br/>──────────<br/>API调用量计费<br/>交易手续费<br/>月度账单"]

        GW --> F["审计 Audit<br/>──────────<br/>全量请求日志<br/>数据访问记录<br/>合规报告"]

        GW --> G["版本管理<br/>──────────<br/>API版本共存<br/>废弃版本迁移通知<br/>Breaking Change防护"]

        GW --> H["沙盒 Sandbox<br/>──────────<br/>测试环境隔离<br/>模拟数据<br/>开发者自助"]
    end

    subgraph "内部服务"
        S1[账户服务]
        S2[支付服务]
        S3[授信服务]
    end

    TPP1 & TPP2 & TPP3 --> GW
    GW --> S1 & S2 & S3

金融级API Gateway vs 普通API Gateway：

5. 第三方授权（OAuth2/FAPI）在金融场景的特殊要求

标准OAuth2 vs FAPI安全对比：

graph TB
    subgraph "标准 OAuth2 流程"
        O1[1. 用户点击'连接银行']
        O2[2. 重定向到银行授权页]
        O3[3. 用户登录+授权]
        O4[4. 回调携带授权码]
        O5[5. 换取Access Token]
        O1 --> O2 --> O3 --> O4 --> O5
    end

    subgraph "FAPI 增强安全"
        F1["PAR (Pushed Authorization Request)<br/>推送式授权请求"]
        F2["JARM (JWT Secured Authorization Response)<br/>JWT加密授权响应"]
        F3["PKCE (Proof Key for Code Exchange)<br/>授权码交换证明"]
        F4["mTLS Client Certificate<br/>双向TLS证书绑定"]
        F5["DPoP (Demonstration of Proof-of-Possession)<br/>持有证明"]
    end

    O1 -.-> F1
    O4 -.-> F2 & F3
    O5 -.-> F4 & F5

FAPI（Financial-grade API）的核心要求：

// FAPI认证流程实现要点
interface FAPIAuthFlow {
  // Step 1: PAR - 推送授权请求
  pushAuthorizationRequest(params: {
    clientId: string;
    scope: string[];              // 'accounts', 'payments'
    consentId: string;
    redirectUri: string;
    state: string;
    nonce: string;
    codeChallenge: string;        // PKCE S256
    clientAssertionType: 'urn:ietf:params:oauth:client-assertion-type:jwt-bearer';
    clientAssertion: string;       // 签名JWT
  }): Promise<{ requestUri: string; expiresIn: number }>;

  // Step 2: 重定向到银行（用request_uri而非完整参数）
  // GET /authorize?request_uri=urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2&client_id=xxx

  // Step 3: 用户在银行端完成SCA认证和授权

  // Step 4: 回调 - 收到JARM（JWT格式的授权响应）
  handleCallback(jarm: string): Promise<{
    code: string;
    state: string;
  }>;

  // Step 5: 换Token（mTLS + PKCE验证）
  exchangeToken(params: {
    code: string;
    codeVerifier: string;          // PKCE验证
    redirectUri: string;
    clientCertificate: Buffer;     // mTLS
  }): Promise<{
    accessToken: string;
    refreshToken: string;
    expiresIn: number;
    scope: string;
  }>;
}

6. Embedded Finance（嵌入式金融）架构模式

graph TB
    subgraph "场景方 (用户入口)"
        SC1["电商平台<br/>──────<br/>嵌入: 先买后付(BNPL)<br/>商户收款<br/>商户贷款"]
        SC2["SaaS平台<br/>──────<br/>嵌入: 企业账户<br/>发薪服务<br/>费用管理"]
        SC3["出行平台<br/>──────<br/>嵌入: 保险<br/>分期付款<br/>司机预付卡"]
        SC4["社交平台<br/>──────<br/>嵌入: P2P转账<br/>红包<br/>小额信贷"]
    end

    subgraph "BaaS编排层"
        BAAS["BaaS平台<br/>──────<br/>API编排<br/>合规引擎<br/>KYC/AML<br/>风控规则"]
    end

    subgraph "金融能力提供"
        B1["银行A<br/>存款账户"]
        B2["银行B<br/>贷款"]
        B3["保险公司<br/>保险"]
        B4["卡组织<br/>卡片发行"]
    end

    SC1 & SC2 & SC3 & SC4 --> BAAS
    BAAS --> B1 & B2 & B3 & B4

嵌入式金融的架构模式：

---

对比分析

开放银行 vs DeFi的"开放性"

---

架构设计实操

实操：设计"开放银行API平台"架构

设计目标：为一家中型银行设计开放银行API平台，支持PSD2合规的AIS/PIS服务，包含API Gateway、开发者门户、沙盒环境。

整体架构：

graph TB
    subgraph "外部参与方"
        TPP["第三方提供商(TPP)<br/>AISP / PISP"]
        DEV["开发者"]
    end

    subgraph "开放银行平台"
        subgraph "接入层"
            PORTAL["开发者门户<br/>[React + Next.js]<br/>注册/文档/SDK"]
            SANDBOX["沙盒环境<br/>[Docker + Mock]<br/>测试数据/模拟流程"]
        end

        subgraph "API Gateway层"
            GW["API Gateway<br/>[Kong / AWS API GW]<br/>mTLS/FAPI/限流/计费"]
            CONSENT["授权管理服务<br/>[Java + PostgreSQL]<br/>Consent CRUD/验证"]
            IAM["身份认证服务<br/>[Keycloak]<br/>OAuth2/OIDC/FAPI"]
        end

        subgraph "API服务层"
            AIS["账户信息API<br/>[Java/Spring]<br/>余额/交易查询"]
            PIS["支付发起API<br/>[Java/Spring]<br/>转账/支付创建"]
            CBPII["余额确认API<br/>[Java/Spring]<br/>资金充足确认"]
        end

        subgraph "合规与监控"
            AUDIT["审计日志服务<br/>[ELK + 加密存储]<br/>全量请求记录"]
            MONITOR["监控告警<br/>[Prometheus+Grafana]<br/>SLA/异常检测"]
            REPORT["监管报送<br/>[批处理]<br/>TPP活动/事件报告"]
        end
    end

    subgraph "核心银行"
        CBS["核心银行系统<br/>账户/支付/记账"]
    end

    DEV --> PORTAL & SANDBOX
    TPP --> GW
    GW --> IAM & CONSENT
    GW --> AIS & PIS & CBPII
    AIS & PIS & CBPII --> CBS
    GW --> AUDIT & MONITOR
    AUDIT --> REPORT

ADR: 授权模式选择

# ADR-037: 开放银行授权模式选择

## 状态：已接受

## 背景
PSD2要求用户对TPP访问其银行数据进行明确授权。有三种授权模式：
1. Redirect（重定向）：用户跳转到银行APP/网站完成授权
2. Decoupled（解耦）：银行通过推送通知让用户在银行APP中授权
3. Embedded（嵌入）：用户在TPP界面输入银行凭证（安全风险高）

## 决策
主模式采用Redirect，辅以Decoupled作为备选：
- Redirect：适用于Web和移动端，安全性最高
- Decoupled：适用于无浏览器的场景（IoT、语音助手）
- 不支持Embedded模式（安全风险不可接受）

## 理由
1. Redirect模式下用户凭证永远不经过TPP，安全性最高
2. UK Open Banking和Berlin Group都推荐Redirect
3. Decoupled模式可以覆盖特殊场景（如PSD2豁免的RTS场景）

## 权衡
- Redirect的UX略差（需要跳转），可通过App-to-App优化
- Decoupled需要银行APP推送能力，覆盖率依赖APP安装率

开发者门户功能设计：

开发者门户功能架构：
├── 注册与认证
│   ├── TPP注册（提供eIDAS证书/牌照号）
│   ├── 证书上传与验证
│   └── 应用创建（获取Client ID/Secret）
│
├── API文档
│   ├── OpenAPI 3.0 规范文档
│   ├── 交互式API Explorer（Try It）
│   ├── 代码示例（Python/Java/Node.js）
│   └── SDK下载
│
├── 沙盒环境
│   ├── 测试账户创建
│   ├── 模拟数据生成
│   ├── 完整授权流程模拟
│   └── 测试支付执行（不涉及真实资金）
│
├── 应用管理
│   ├── API Key管理
│   ├── 回调URL配置
│   ├── 用量统计Dashboard
│   └── 账单和计费
│
├── 支持
│   ├── 工单系统
│   ├── FAQ
│   ├── 变更通知（API版本更新）
│   └── 状态页面（API可用性）
│
└── 合规
    ├── TPP合规状态检查
    ├── 证书续期提醒
    └── 数据处理协议(DPA)签署

沙盒环境架构：

graph TB
    subgraph "沙盒环境（与生产隔离）"
        SB_GW["沙盒API Gateway<br/>同生产配置<br/>但连接模拟服务"]

        SB_AUTH["模拟授权服务<br/>无需真实SCA<br/>预设测试用户"]

        SB_MOCK["模拟银行服务<br/>预设账户/交易数据<br/>可控的响应延迟<br/>错误注入能力"]

        SB_DATA["测试数据生成器<br/>符合格式的模拟数据<br/>多场景覆盖"]
    end

    TPP_DEV["开发者应用<br/>(开发/测试)"]

    TPP_DEV --> SB_GW --> SB_AUTH --> SB_MOCK
    SB_DATA --> SB_MOCK

---

AI增强实践

1. AI辅助API设计审查

Prompt示例：

作为开放银行API设计专家，请审查以下API端点设计是否符合UK Open Banking v3.1标准：

GET /accounts/{accountId}/transactions
Headers:
  Authorization: Bearer {access_token}
  x-fapi-financial-id: {OB目录中的financial-id}
Query Parameters:
  fromBookingDateTime: 2024-01-01T00:00:00Z
  toBookingDateTime: 2024-03-31T23:59:59Z
  page: 1
  pageSize: 100

请审查：
1. 端点路径是否符合OB命名规范
2. Header参数是否完整
3. 分页方式是否符合标准(offset vs cursor)
4. 日期过滤字段命名是否正确
5. 响应体的必选/可选字段是否完整
6. 错误响应格式是否符合规范

2. AI辅助安全威胁建模

Prompt示例：

请对以下开放银行授权流程进行STRIDE威胁建模：

1. 用户在TPP APP中发起"连接银行"
2. TPP向银行POST /account-access-consents
3. 用户被重定向到银行授权页面
4. 用户在银行完成SCA认证
5. 银行将授权码通过回调返回TPP
6. TPP用授权码换取Access Token
7. TPP用Token调用账户API

对每一步：
- 识别可能的威胁(STRIDE)
- 评估风险等级
- 给出缓解措施
- 说明FAPI标准如何应对

3. 人机边界

---

与Web3/DeFi的关联

深度洞察：

开放银行和DeFi在"开放性"上殊途同归，但路径完全不同：

• 开放银行：从封闭走向开放（监管推动银行打开API），本质是受控的、有许可的开放
• DeFi：天生开放（智能合约代码公开，任何人可调用），本质是无许可的、彻底的开放

两者的融合点在嵌入式金融——未来的场景是：用户在电商平台购物时，可以选择用银行账户支付（通过Open Banking API）或用加密钱包支付（通过DeFi协议），甚至用BNPL分期（通过链上信用协议）。这种"多轨并行"的支付架构，需要一个能同时对接CeFi API和DeFi协议的中间层——这可能就是下一代BaaS平台的形态。

---

今日思考

1. Open Banking的Consent模型（用户授权→有效期→可撤销）与DeFi的Approval模型（ERC20 approve→无限额度→需手动revoke）相比，哪个对用户更安全？如何在DeFi中实现类似Open Banking的精细化Consent？

2. BaaS模式让非银行机构也能"卖银行服务"，但合规责任链变得更复杂（银行→BaaS→嵌入方）。如果某个环节出了合规问题，责任如何划分？这在链上金融（如DAO运营的BaaS）中会更复杂还是更简单？

3. 开放银行的API Gateway承担了大量安全和合规职能。在DeFi中，这些职能由谁承担？是否需要一个"链上API Gateway"的概念（如智能合约防火墙/Access Control Layer）？

---

面试题准备

Q1: 开放银行如何平衡开放性和安全性？

30秒版本： 通过"四层防护"实现平衡：TPP准入管控（牌照/注册）+ 用户授权（Consent）+ 技术安全（FAPI/mTLS）+ 持续监控（API审计/异常检测）。核心原则是"数据最小化"和"用户控制"。

2分钟版本：

开放银行的安全架构是一个"纵深防御"体系：

第一层：准入控制。不是任何人都能接入银行API。TPP需要在监管机构注册（如UK FCA），获取eIDAS证书，通过银行的技术和安全评估。这确保接入方的身份可信。

第二层：用户授权（Consent）。即使TPP通过了准入，也只能在用户明确授权后访问数据。Consent有三个关键属性：

• 范围限定（只能访问用户授权的账户和数据类型）
• 时间限定（有有效期，最长90天需重新授权）
• 可撤销（用户可随时在银行端撤销）

第三层：技术安全（FAPI）。每个API调用都经过mTLS双向认证、Token绑定、请求签名验证。即使Token被盗，没有对应的证书也无法使用。

第四层：持续监控。全量API调用日志、异常行为检测（如短时间大量查询不同用户数据）、定期安全审计、自动化合规报告。

追问准备：

• 追问：如果TPP被黑客攻击，用户数据怎么保护？ → 最小化原则：TPP只能获取授权范围的数据，且有缓存限制（不应持久存储原始数据）。银行可以根据异常行为（如大量查询）主动撤销TPP的访问权限
• 追问：DeFi相比开放银行在安全性上有何优劣？ → DeFi更透明（代码公开可审计），但风险模型不同：DeFi的风险在智能合约漏洞和私钥管理，Open Banking的风险在API安全和数据泄露

Q2: BaaS架构的核心挑战是什么？

30秒版本： BaaS的核心挑战是合规责任链管理和多层SLA保障。当银行能力通过BaaS平台提供给嵌入方使用时，合规责任在三方之间变得模糊，同时任一层的故障都可能影响最终用户体验。

2分钟版本：

BaaS有三大核心挑战：

第一，合规责任链（Regulatory Responsibility Chain）。传统模式下银行直接面对用户，合规责任清晰。BaaS模式下：

• 银行负责牌照和核心合规（AML/KYC/存款保险）
• BaaS平台负责技术合规（数据安全/API安全）
• 嵌入方负责用户界面合规（信息披露/消费者保护）

2023年Synapse（美国BaaS平台）倒闭事件暴露了这个问题——用户以为钱在银行，但实际资金流经了多个中间层，出问题时谁负责不清楚。

第二，SLA层叠（SLA Stacking）。最终用户体验依赖整个链路的稳定性。如果银行可用性99.99%，BaaS平台99.9%，嵌入方99.9%，整体可用性可能降到99.7%。每个环节都需要有独立的降级策略。

第三，多租户隔离。BaaS平台需要同时服务多个嵌入方，每个嵌入方可能有不同的产品配置、费率、限额。这要求平台有强大的多租户架构——数据隔离、配置隔离、限流隔离。

追问准备：

• 追问：DeFi的可组合性是否就是"去中心化的BaaS"？ → 是一种类比。DeFi协议的可组合性（如Yearn聚合Aave/Compound的存款）类似于BaaS聚合多家银行的能力。但DeFi的优势是无需商业协议和API集成，劣势是缺乏合规框架和SLA保障
• 追问：如何评估一个BaaS平台的架构质量？ → 三个维度：1)API设计质量（标准化程度/文档完善度/SDK质量）；2)运维能力（SLA/故障响应时间/监控覆盖度）；3)合规能力（牌照覆盖/KYC流程/审计报告）

---

学习资源

1. UK Open Banking Official Website (openbanking.org.uk) — 标准规范和实施指南
2. Berlin Group NextGenPSD2 — 欧盟PSD2 API标准
3. FAPI (Financial-grade API) Working Group — 金融级API安全标准
4. 《Platform Strategy for Banking》 — 银行平台化战略
5. Stripe Treasury / Unit Documentation — BaaS平台的技术文档
6. Synapse倒闭事件分析 — BaaS风险的经典案例

---

明日预告

Day 38: 支付清算体系 — 从银行内部的记账走向银行间的资金流动。我们将深入CNAPS（大小额支付系统）、SWIFT、CIPS、网联/银联清算网络、实时支付（Faster Payments）等支付基础设施的架构设计，理解"钱是怎么从一家银行到另一家银行"的全过程。