Arch Day 34: 存款业务架构

日期: 2026-05-03 (Day 34) 阶段: 第二阶段 - 金融域深度 标签: #存款 #计息引擎 #利率管理 #产品工厂 #存款保险

---

核心概念

一句话定义

存款业务是银行最核心的负债业务——银行通过吸收存款获得资金来源，再通过贷款和投资获取收益。存款系统的架构需要处理产品参数化配置、高精度计息、利率动态管理、以及监管合规（存款保险、利率上限）等多重约束。

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

1. 存款是银行的"血液"：存款规模和成本直接决定银行的盈利能力。存款产品的创新速度取决于架构的灵活性
2. 计息引擎是金融系统中精度要求最高的计算组件：一分钱的计算误差乘以上亿账户就是巨额损失
3. LPR改革和利率市场化对系统架构提出了全新要求：利率不再是静态配置，而是动态联动
4. DeFi的存款（流动性提供）正在用算法替代传统存款的人工定价：理解传统计息才能评估DeFi收益率的合理性

常见误区与反模式

---

知识点详解

1. 存款产品体系

graph TB
    DEP[存款产品]
    DEP --> DEMAND[活期存款]
    DEP --> TIME[定期存款]
    DEP --> NOTICE[通知存款]
    DEP --> NEGOTIATED[协定存款]
    DEP --> CD[大额存单]
    DEP --> STRUCTURED[结构性存款]

    DEMAND --> D1[个人活期]
    DEMAND --> D2[企业活期]
    DEMAND --> D3[智能存款/靠档计息]

    TIME --> T1[整存整取]
    TIME --> T2[零存整取]
    TIME --> T3[整存零取]
    TIME --> T4[存本取息]

    NOTICE --> N1[1天通知存款]
    NOTICE --> N2[7天通知存款]

    STRUCTURED --> S1[保本浮动收益型]
    STRUCTURED --> S2[保本保收益型]

各类存款产品关键参数对比：

2. 计息引擎设计

积数计息法（活期存款主流方式）

原理：先算每天的"积数"（余额×天数），季末汇总后乘以日利率。

积数 = 每日余额 × 保留天数
利息 = 总积数 × 日利率

日利率 = 年利率 / 360 (中国银行业惯例用360天)

示例：

张三活期账户（年利率0.2%）

日期          操作      余额       积数（到下次变动的天数）
01/01         -       10,000      10,000 × 15 = 150,000
01/16         存5000   15,000      15,000 × 20 = 300,000
02/05         取3000   12,000      12,000 × 53 = 636,000
03/31(结息)    -        -          总积数 = 1,086,000

日利率 = 0.2% / 360 = 0.000005556
利息 = 1,086,000 × 0.000005556 = ¥6.03

(注：结息日为3月20日、6月20日、9月20日、12月20日，简化为季末)

TypeScript实现：

interface BalanceChange {
  date: Date;
  balanceAfter: bigint; // 单位：分
}

interface InterestResult {
  totalAccumulated: bigint;  // 总积数
  interest: bigint;          // 利息（分）
  rate: number;              // 年利率
  startDate: Date;
  endDate: Date;
}

/**
 * 积数计息法（活期存款）
 * @param changes 期间内的余额变动记录（按日期排序）
 * @param annualRate 年利率（如0.002表示0.2%）
 * @param startDate 计息起始日
 * @param endDate 计息截止日（结息日）
 */
function calculateByAccumulation(
  changes: BalanceChange[],
  annualRate: number,
  startDate: Date,
  endDate: Date
): InterestResult {
  let totalAccumulated = 0n;
  let currentBalance = changes[0]?.balanceAfter ?? 0n;
  let currentDate = startDate;

  for (let i = 1; i <= changes.length; i++) {
    const nextDate = i < changes.length ? changes[i].date : endDate;
    const days = daysBetween(currentDate, nextDate);
    totalAccumulated += currentBalance * BigInt(days);

    if (i < changes.length) {
      currentBalance = changes[i].balanceAfter;
      currentDate = changes[i].date;
    }
  }

  // 如果最后一次变动到结息日还有天数
  if (changes.length > 0) {
    const lastChange = changes[changes.length - 1];
    const remainDays = daysBetween(lastChange.date, endDate);
    if (remainDays > 0) {
      totalAccumulated += lastChange.balanceAfter * BigInt(remainDays);
    }
  }

  // 利息计算（保留到分，四舍五入）
  const dailyRate = annualRate / 360;
  const interestFloat = Number(totalAccumulated) * dailyRate;
  const interest = BigInt(Math.round(interestFloat));

  return {
    totalAccumulated,
    interest,
    rate: annualRate,
    startDate,
    endDate,
  };
}

function daysBetween(d1: Date, d2: Date): number {
  const msPerDay = 24 * 60 * 60 * 1000;
  return Math.floor((d2.getTime() - d1.getTime()) / msPerDay);
}

逐笔计息法（定期存款主流方式）

原理：每笔存款独立计算利息。

利息 = 本金 × 年利率 × 存期(年)

或精确到天：
利息 = 本金 × 日利率 × 天数

定期存款的四种还本付息方式：

利率分段计算（复合场景）

当利率在存期内发生变化时，需要分段计息：

interface RateSegment {
  startDate: Date;
  endDate: Date;
  annualRate: number;
}

/**
 * 分段计息（利率调整场景）
 */
function calculateWithRateSegments(
  principal: bigint,
  segments: RateSegment[]
): bigint {
  let totalInterest = 0n;

  for (const seg of segments) {
    const days = daysBetween(seg.startDate, seg.endDate);
    const dailyRate = seg.annualRate / 360;
    const segmentInterest = Number(principal) * dailyRate * days;
    totalInterest += BigInt(Math.round(segmentInterest));
  }

  return totalInterest;
}

3. 利率管理系统

graph TB
    subgraph "利率层级结构"
        PBOC["央行基准利率<br/>(2019年前)"]
        LPR["LPR利率<br/>(2019年后)<br/>每月20日发布"]
        LISTED["挂牌利率<br/>(银行公示利率)<br/>= 基准 × (1+浮动比例)"]
        EXEC["执行利率<br/>(客户实际利率)<br/>= 挂牌 ± 调整"]
    end

    PBOC --> LPR
    LPR --> LISTED
    LISTED --> EXEC

    subgraph "影响因素"
        F1[客户等级]
        F2[存款金额]
        F3[存款期限]
        F4[渠道(线上/线下)]
        F5[区域差异]
    end

    F1 & F2 & F3 & F4 & F5 --> EXEC

利率管理系统的数据模型：

// 基准利率（央行/LPR）
interface BaseRate {
  rateId: string;
  rateType: 'PBOC_BASE' | 'LPR_1Y' | 'LPR_5Y';
  effectiveDate: Date;          // 生效日期
  rate: number;                 // 利率值
  publishDate: Date;            // 发布日期
}

// 挂牌利率（银行级别）
interface ListedRate {
  rateId: string;
  productCode: string;          // 产品代码
  term: number;                 // 期限（月）
  currencyCode: string;         // 币种
  effectiveDate: Date;
  rate: number;
  floatType: 'FIXED' | 'FLOAT_UP' | 'FLOAT_DOWN';
  floatBasis: number;           // 浮动基点（bp）
  baseRateRef: string;          // 关联的基准利率
}

// 执行利率（客户级别）
interface ExecutionRate {
  rateId: string;
  contractId: string;           // 合约ID
  accountId: string;            // 账户ID
  baseRate: number;             // 签约时的基准利率
  floatBps: number;             // 浮动基点（+/-）
  effectiveRate: number;        // 实际执行利率
  effectiveDate: Date;
  adjustmentType: 'FIXED_AT_SIGN' | 'ANNUAL_ADJUST' | 'REAL_TIME';
}

利率调整策略（定期存款贷款重定价）：

4. 存款产品参数化配置（产品工厂模式）

/**
 * 存款产品模板定义
 * 这就是"产品工厂"的核心配置结构
 */
interface DepositProductTemplate {
  // === 基本信息 ===
  productCode: string;                // 产品代码
  productName: string;                // 产品名称
  productType: DepositProductType;    // 产品类型
  subjectCode: string;                // 科目代码
  currency: string[];                 // 支持的币种

  // === 金额规则 ===
  minAmount: bigint;                  // 起存金额
  maxAmount?: bigint;                 // 最高金额
  amountMultiple?: bigint;            // 金额必须是X的整数倍

  // === 期限规则 ===
  termOptions?: TermOption[];         // 可选期限
  autoRenew: boolean;                 // 是否自动转存
  renewTermDefault?: number;          // 默认转存期限

  // === 利率规则 ===
  interestMethod: 'ACCUMULATION' | 'PER_ENTRY'; // 计息方法
  interestCycle: 'DAILY' | 'MONTHLY' | 'QUARTERLY' | 'YEARLY' | 'AT_MATURITY';
  dayCountConvention: 'ACT_360' | 'ACT_365' | 'ACT_ACT' | '30_360';
  rateType: 'FIXED' | 'FLOATING';
  baseRateRef?: string;               // 挂钩的基准利率
  maxFloatUp?: number;                // 最大上浮比例
  maxFloatDown?: number;              // 最大下浮比例

  // === 提前支取规则 ===
  earlyWithdrawPolicy: EarlyWithdrawPolicy;

  // === 部分提取规则 ===
  partialWithdrawAllowed: boolean;
  minRetainAmount?: bigint;           // 部分提取后最低保留金额

  // === 计息起止规则 ===
  interestStartRule: 'SAME_DAY' | 'NEXT_DAY'; // 存入当日是否计息
  interestEndRule: 'SAME_DAY' | 'PREV_DAY';   // 支取当日是否计息

  // === 渠道规则 ===
  availableChannels: string[];        // 可办理渠道
  onlineAllowed: boolean;             // 是否支持线上办理

  // === 关联规则 ===
  depositInsuranceCovered: boolean;   // 是否纳入存款保险
  pledgeable: boolean;                // 是否可质押
}

type DepositProductType =
  | 'DEMAND'          // 活期
  | 'TIME_LUMP'       // 整存整取
  | 'TIME_ZERO_IN'    // 零存整取
  | 'TIME_ZERO_OUT'   // 整存零取
  | 'TIME_PRINCIPAL'  // 存本取息
  | 'NOTICE_1D'       // 1天通知
  | 'NOTICE_7D'       // 7天通知
  | 'NEGOTIATED'      // 协定存款
  | 'CD'              // 大额存单
  | 'STRUCTURED';     // 结构性存款

interface TermOption {
  termMonths: number;         // 期限（月）
  listedRate: number;         // 挂牌利率
  maxFloatRate?: number;      // 最高可执行利率
}

interface EarlyWithdrawPolicy {
  type: 'DEMAND_RATE' | 'TIERED_RATE' | 'PENALTY';
  demandRate?: number;         // 按活期利率计息
  tieredRules?: TieredRule[];  // 靠档计息规则
  penaltyRate?: number;        // 罚息比例
}

interface TieredRule {
  minDays: number;             // 最低持有天数
  appliedRate: number;         // 适用利率
}

产品实例化流程：

sequenceDiagram
    participant PM as 产品经理
    participant PF as 产品工厂
    participant RISK as 风控审核
    participant SYS as 核心系统

    PM->>PF: 1. 配置产品参数<br/>(基于模板)
    PF->>PF: 2. 参数校验<br/>(合规性/完备性)
    PF->>RISK: 3. 提交风控审核<br/>(利率上限/期限合规)
    RISK-->>PF: 4. 审核通过
    PF->>SYS: 5. 发布产品<br/>(状态: 待上架)
    PM->>SYS: 6. 上架产品<br/>(状态: 已上架)
    Note over SYS: 产品可用于开户

    SYS->>SYS: 7. 客户开户时<br/>实例化合约+账户

5. 存款保险制度对系统设计的影响

中国存款保险条例（2015年5月）规定：同一存款人在同一家投保机构最高偿付限额为50万元人民币。

系统需要支持的能力：

存款保险系统需求：
├── 实时计算
│   ├── 每个储户在本行的存款总额（含利息）
│   ├── 判断是否超过50万限额
│   └── 超限部分的风险提示
│
├── 数据报送
│   ├── 每日向存款保险基金报送存款数据
│   ├── 投保机构信息维护
│   └── 保费计算（存款余额×费率）
│
├── 赔付支持
│   ├── 储户身份归集（同一人在本行的所有账户）
│   ├── 应赔金额计算
│   └── 赔付账户管理
│
└── 特殊处理
    ├── 联名账户（按约定比例拆分）
    ├── 信托存款（穿透到受益人）
    └── 企业/机构存款（不受保范围的界定）

架构影响：

6. 智能存款与开放银行场景

graph LR
    subgraph "传统模式"
        C1[客户] --> B1[银行网点/APP]
        B1 --> D1[存款产品]
    end

    subgraph "开放银行模式"
        C2[客户] --> P1[互联网平台<br/>(支付宝/微信)]
        P1 -->|API| B2[银行存款API]
        B2 --> D2[存款产品]
    end

    subgraph "智能存款模式"
        C3[客户] --> AI[智能理财助手]
        AI -->|分析收支模式| OPT[最优存款组合]
        OPT -->|API| B3[多家银行]
        B3 --> D3[活期+定期+通知<br/>自动组合]
    end

"智能存款"的架构挑战：

---

对比分析

传统存款 vs DeFi存款（Lending Protocol）

---

架构设计实操

实操：设计"存款产品工厂"参数化配置方案

设计目标：为一家数字银行设计存款产品工厂，要求支持5种核心存款产品的配置化发布，产品上线周期从"周级"缩短到"天级"。

整体架构：

graph TB
    subgraph "产品管理平台"
        PC[产品配置控制台<br/>Web UI]
        VE[参数验证引擎]
        WF[审批工作流]
        PUB[发布管理]
    end

    subgraph "产品工厂核心"
        PT[产品模板库]
        PR[参数规则引擎]
        PI[产品实例化服务]
    end

    subgraph "核心银行"
        ACC[账户服务]
        INT[计息引擎]
        RATE[利率管理]
        LEDGER[记账引擎]
    end

    PC --> VE --> WF --> PUB
    PUB --> PT
    PT --> PR --> PI
    PI --> ACC & INT & RATE & LEDGER

ADR: 参数化 vs DSL vs 硬编码

# ADR-034: 存款产品配置方案选择

## 背景
需要选择存款产品的业务规则定义方式：
- 方案A: 纯参数化（JSON配置）
- 方案B: DSL（领域特定语言，类似Thought Machine）
- 方案C: 硬编码（每个产品一个Java类）

## 决策
采用"参数化+扩展点"混合方案：
- 80%的产品规则通过JSON参数配置
- 20%的复杂逻辑（如结构性存款的收益计算）通过Plugin扩展点实现
- Plugin用Groovy/JavaScript脚本编写，支持热加载

## 理由
1. 纯参数化无法覆盖结构性存款的衍生品定价逻辑
2. 完整DSL的开发成本太高，且学习曲线陡峭
3. 硬编码无法满足"天级"上线要求
4. 参数化+Plugin是业界验证过的平衡点

## 权衡
- Plugin脚本的安全性：通过沙箱执行+白名单API限制
- Plugin的测试：要求每个Plugin必须附带单元测试
- 配置复杂度：通过"产品模板继承"减少重复配置

产品模板继承示例：

// 基础存款模板（所有存款共享的参数）
const baseDepositTemplate = {
  depositInsuranceCovered: true,
  interestStartRule: 'NEXT_DAY',
  interestEndRule: 'SAME_DAY',
  availableChannels: ['MOBILE', 'ONLINE', 'COUNTER'],
};

// 活期存款模板（继承基础模板）
const demandDepositTemplate = {
  ...baseDepositTemplate,
  productType: 'DEMAND',
  interestMethod: 'ACCUMULATION',
  interestCycle: 'QUARTERLY',
  dayCountConvention: 'ACT_360',
  minAmount: 100n, // ¥1
  partialWithdrawAllowed: true,
  autoRenew: false,
};

// 1年定期存款模板
const oneYearTimeDepositTemplate = {
  ...baseDepositTemplate,
  productType: 'TIME_LUMP',
  interestMethod: 'PER_ENTRY',
  interestCycle: 'AT_MATURITY',
  dayCountConvention: 'ACT_360',
  minAmount: 5000n, // ¥50
  termOptions: [{ termMonths: 12, listedRate: 0.0165 }],
  autoRenew: true,
  earlyWithdrawPolicy: { type: 'DEMAND_RATE' },
  pledgeable: true,
};

---

AI增强实践

1. AI辅助计息规则验证

场景：新存款产品上线前，用AI验证计息规则的正确性

Prompt示例：

你是银行计息专家。请验证以下"3年期大额存单"的计息规则是否正确：

产品参数：
- 起存金额：20万元
- 期限：3年
- 年利率：2.65%
- 计息方式：逐笔计息
- 付息频率：每月付息
- 日计息基准：ACT/360
- 提前支取：按活期利率（0.2%）计息

请计算以下场景：
1. 正常持有到期，总利息是多少？
2. 持有18个月后提前支取，总利息是多少？
3. 如果期间央行降息（第2年初利率调为2.5%），对已签约客户的影响？

对每个计算，请给出详细步骤和最终金额。

2. AI辅助利率定价分析

Prompt示例：

分析以下存款利率定价的合理性：

我行当前挂牌利率：
- 活期：0.20%
- 1年定期：1.65%
- 3年定期：2.65%
- 大额存单(1年)：1.85%

同业对比（请用你知道的最新数据）：
请分析：
1. 利率倒挂风险（长短期利差是否合理）
2. 与LPR的利差分析
3. 与DeFi存款利率（如Aave USDC供给利率）的对比
4. 建议调整方向

3. 人机边界

---

与Web3/DeFi的关联

深度洞察：Aave的利率模型（利用率曲线）本质上就是一个自动化的"利率管理系统"——当资金供给充足时利率下降（吸引借款），当资金紧张时利率飙升（吸引存款）。这种算法定价消除了银行"利率委员会"的人工决策环节，但也失去了"逆周期调节"的能力（银行可以在经济下行时主动维持存款利率稳定）。

---

今日思考

1. "靠档计息"产品（智能存款）为什么被监管叫停？从系统架构角度看，靠档计息对银行的流动性管理带来了什么挑战？

2. DeFi的"每区块计息"是否优于传统的"季度结息"？如果把Aave的计息模式搬到传统银行，系统需要做哪些改造？性能瓶颈在哪里？

3. 结构性存款（挂钩衍生品的保本浮动收益）如果用智能合约实现，架构上是否更优雅？有哪些技术和监管挑战？

---

面试题准备

Q1: 计息引擎如何处理利率调整？

30秒版本： 利率调整的处理取决于合约约定的"重定价策略"。定期存款通常"签约锁定"，合约期内利率不变。浮动利率产品按约定周期（如年度、季度）重新定价。系统需要维护利率的版本历史，确保每笔计息使用的是正确时间段的利率。

2分钟版本：

计息引擎处理利率调整需要解决三个层面的问题：

第一层：利率数据管理。系统需要维护基准利率（LPR）→ 挂牌利率 → 执行利率的完整链条，每个层级都有版本和生效日期。利率变更时，新利率以"新增版本"方式存储，不覆盖历史。

第二层：合约重定价规则。不同合约有不同的重定价策略：

• "签约固定"：利率在存期内不变（定期存款的默认方式）
• "年度调整"：每年1月1日按最新LPR重新计算（旧房贷模式）
• "即时浮动"：基准利率一变就跟着变（较少见）

系统需要在每个合约上记录重定价策略，并在批处理中执行重定价。

第三层：分段计息。当利率在计息周期内变化时（如年度调整发生在季中），需要将计息周期分为两段，分别用不同利率计算，最后汇总。

追问准备：

• 追问：LPR每月变化，上亿房贷合约的年度重定价怎么做？ → 批量重定价Job，按客户分片并行处理。重定价不改变余额，只更新合约的执行利率参数。通常在年初集中处理
• 追问：如果重定价时发现利率计算错误（多算了利息），怎么办？ → 不能直接修改历史。需要生成"调整分录"，做利息差额的补扣或退还，保持审计链完整

Q2: 产品参数化配置的边界在哪里？

30秒版本： 边界在于"规则可穷举"vs"逻辑不可穷举"。当产品规则可以用有限的参数组合描述时（利率、期限、最低金额），适合参数化。当规则涉及复杂计算逻辑（如结构性存款挂钩期权定价）时，需要代码扩展点。

2分钟版本：

参数化配置的黄金法则是80/20原则。

适合参数化的（占80%产品）：

• 利率/费率等数值参数
• 期限/金额范围等约束参数
• 结息方式/付息频率等枚举选项
• 渠道/客群等开关类配置

不适合参数化的（占20%产品）：

• 结构性存款的收益计算（依赖Black-Scholes等衍生品定价模型）
• 复杂的提前支取规则（如分段靠档+惩罚性条款的组合）
• 需要调用外部服务的规则（如实时查询汇率/指数）

解决方案：参数化框架+Plugin扩展点。Plugin用沙箱化脚本实现（如Groovy/WASM），既保持灵活性，又不破坏核心系统稳定性。

反模式警告：试图100%参数化最终会创造出一个"图灵完备的配置系统"，复杂度不亚于直接写代码，但调试困难十倍。这是很多银行产品工厂项目失败的原因。

追问准备：

• 追问：参数配置如何做版本管理和灰度发布？ → 产品参数走Git版本管理+审批流。灰度发布通过"渠道+客群"维度控制：先对特定渠道的小部分客群开放，观察无异常后全量
• 追问：配置错误如何快速回滚？ → 产品参数支持"紧急下架"（一键停用），存量客户不受影响，新客户无法购买。核心是配置变更的原子性和可回滚性

---

学习资源

1. 《商业银行业务与管理》 — 存款业务的经典教材
2. 央行LPR改革文件 — 理解利率市场化对系统的影响
3. Aave V3 Documentation: Interest Rate Strategy — DeFi利率模型的优秀实践
4. Thought Machine: "Building a Product Factory" — 产品工厂设计最佳实践
5. 存款保险基金管理机构官网 — 存款保险制度的系统性要求

---

明日预告

Day 35: 贷款业务架构 — 贷款是银行最核心的资产业务，也是架构复杂度最高的业务领域。我们将深入贷款全生命周期（准入→授信→放款→还款→逾期→核销）、授信模型（额度→产品→借据）、还款计划生成引擎、逾期管理和贷后系统的架构设计。