Arch Day 35: 贷款业务架构

日期: 2026-05-04 (Day 35) 阶段: 第二阶段 - 金融域深度 标签: #贷款 #授信 #还款计划 #逾期管理 #贷后 #FTP

---

核心概念

一句话定义

贷款业务是银行最核心的资产业务，也是架构复杂度最高的业务域——它覆盖从客户准入、信用评估、额度授信、合同签订、放款发放、还款管理、逾期催收到最终核销的完整生命周期，每个环节都有独特的业务规则和系统架构需求。

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

1. 贷款系统是银行IT投入最大的领域：一个大型银行的信贷系统通常涉及20+子系统、数百个微服务
2. 贷款的生命周期管理是状态机设计的极致挑战：从申请到核销可能跨越30年（房贷），期间状态转换极其复杂
3. 逾期管理和不良处置直接影响银行生死存亡：不良率是银行最核心的风险指标
4. DeFi借贷（Aave/Compound）用算法替代了传统贷款的人工审批：但只实现了"超额抵押"这一种模式，信用贷款仍是DeFi的"圣杯"

常见误区与反模式

---

知识点详解

1. 贷款全生命周期

graph LR
    subgraph "贷前 Pre-Lending"
        A1[客户准入<br/>白名单/黑名单]
        A2[信用评估<br/>征信查询/评分]
        A3[额度审批<br/>授信额度确定]
        A4[合同签订<br/>电子签约]
    end

    subgraph "贷中 Lending"
        B1[支用申请<br/>借据生成]
        B2[放款审核<br/>风控复核]
        B3[放款执行<br/>资金发放]
        B4[还款管理<br/>正常还款]
    end

    subgraph "贷后 Post-Lending"
        C1[贷后监控<br/>风险预警]
        C2[逾期管理<br/>催收/罚息]
        C3[不良处置<br/>核销/转让]
        C4[贷款结清<br/>解除担保]
    end

    A1 --> A2 --> A3 --> A4 --> B1 --> B2 --> B3 --> B4
    B4 --> C1
    C1 --> C2 --> C3
    B4 --> C4

各阶段的系统能力需求：

2. 授信模型（Credit Facility）：额度→产品→借据三级结构

graph TB
    subgraph "客户综合授信"
        CF["综合授信额度<br/>¥500,000<br/>───────<br/>已用: ¥300,000<br/>可用: ¥200,000<br/>有效期: 2024-2027"]
    end

    subgraph "产品额度"
        PL1["消费贷额度<br/>¥300,000<br/>───────<br/>循环额度<br/>已用: ¥200,000"]
        PL2["信用卡额度<br/>¥100,000<br/>───────<br/>循环额度<br/>已用: ¥50,000"]
        PL3["经营贷额度<br/>¥200,000<br/>───────<br/>非循环额度<br/>已用: ¥50,000"]
    end

    subgraph "借据(Loan Receipt)"
        LR1["借据A: ¥100,000<br/>消费贷-12期<br/>2024-01发放"]
        LR2["借据B: ¥100,000<br/>消费贷-6期<br/>2024-03发放"]
        LR3["借据C: ¥50,000<br/>信用卡分期<br/>2024-02"]
        LR4["借据D: ¥50,000<br/>经营周转贷<br/>2024-04"]
    end

    CF --> PL1 & PL2 & PL3
    PL1 --> LR1 & LR2
    PL2 --> LR3
    PL3 --> LR4

    style CF fill:#e1f5fe
    style PL1 fill:#fff3e0
    style PL2 fill:#fff3e0
    style PL3 fill:#fff3e0

额度管理的核心逻辑：

interface CreditFacility {
  facilityId: string;
  customerId: string;
  totalLimit: bigint;           // 总授信额度
  usedLimit: bigint;            // 已用额度
  frozenLimit: bigint;          // 冻结额度（审批中的申请）
  availableLimit: bigint;       // 可用额度 = total - used - frozen
  effectiveDate: Date;
  expiryDate: Date;
  revolving: boolean;           // 是否循环（还款后额度恢复）
  status: FacilityStatus;
}

// 额度占用/释放操作
class CreditFacilityService {
  /**
   * 占用额度（放款时调用）
   */
  occupy(facilityId: string, amount: bigint): void {
    const facility = this.getFacility(facilityId);
    this.assertActive(facility);
    this.assertNotExpired(facility);

    if (amount > facility.availableLimit) {
      throw new InsufficientCreditLimitError(facility.availableLimit, amount);
    }

    facility.usedLimit += amount;
    facility.availableLimit -= amount;
    this.save(facility);
    this.publishEvent(new CreditOccupiedEvent(facilityId, amount));
  }

  /**
   * 释放额度（循环额度还款时调用）
   */
  release(facilityId: string, amount: bigint): void {
    const facility = this.getFacility(facilityId);
    if (!facility.revolving) {
      // 非循环额度不释放
      return;
    }

    facility.usedLimit -= amount;
    facility.availableLimit += amount;
    this.save(facility);
    this.publishEvent(new CreditReleasedEvent(facilityId, amount));
  }

  /**
   * 冻结额度（申请审批中）
   */
  freeze(facilityId: string, amount: bigint): void {
    const facility = this.getFacility(facilityId);
    if (amount > facility.availableLimit) {
      throw new InsufficientCreditLimitError(facility.availableLimit, amount);
    }

    facility.frozenLimit += amount;
    facility.availableLimit -= amount;
    this.save(facility);
  }

  /**
   * 解冻额度（申请被拒绝时）
   */
  unfreeze(facilityId: string, amount: bigint): void {
    const facility = this.getFacility(facilityId);
    facility.frozenLimit -= amount;
    facility.availableLimit += amount;
    this.save(facility);
  }
}

3. 还款计划生成引擎

四种主要还款方式：

等额本息（Equal Installment / Annuity）

每月还款额 = [P × r × (1+r)^n] / [(1+r)^n - 1]

其中:
P = 贷款本金
r = 月利率 = 年利率 / 12
n = 总期数（月数）

interface RepaymentScheduleEntry {
  period: number;           // 期数
  dueDate: Date;           // 应还日期
  principalAmount: bigint; // 应还本金（分）
  interestAmount: bigint;  // 应还利息（分）
  totalAmount: bigint;     // 应还总额
  remainingPrincipal: bigint; // 剩余本金
}

/**
 * 等额本息还款计划生成
 */
function generateEqualInstallment(
  principal: bigint,        // 贷款本金（分）
  annualRate: number,       // 年利率
  totalPeriods: number,     // 总期数
  startDate: Date           // 首期还款日
): RepaymentScheduleEntry[] {
  const monthlyRate = annualRate / 12;
  const principalFloat = Number(principal);

  // 每月还款额（元，浮点计算后转整数）
  const factor = Math.pow(1 + monthlyRate, totalPeriods);
  const monthlyPayment = principalFloat * monthlyRate * factor / (factor - 1);

  const schedule: RepaymentScheduleEntry[] = [];
  let remainingPrincipal = principal;
  let totalPrincipalPaid = 0n;

  for (let i = 1; i <= totalPeriods; i++) {
    const interest = BigInt(Math.round(Number(remainingPrincipal) * monthlyRate));

    // 最后一期：本金 = 剩余本金（避免累积误差）
    let principalPayment: bigint;
    if (i === totalPeriods) {
      principalPayment = remainingPrincipal;
    } else {
      principalPayment = BigInt(Math.round(monthlyPayment)) - interest;
    }

    const total = principalPayment + interest;
    remainingPrincipal -= principalPayment;
    totalPrincipalPaid += principalPayment;

    schedule.push({
      period: i,
      dueDate: addMonths(startDate, i),
      principalAmount: principalPayment,
      interestAmount: interest,
      totalAmount: total,
      remainingPrincipal,
    });
  }

  return schedule;
}

/**
 * 等额本金还款计划生成
 */
function generateEqualPrincipal(
  principal: bigint,
  annualRate: number,
  totalPeriods: number,
  startDate: Date
): RepaymentScheduleEntry[] {
  const monthlyRate = annualRate / 12;
  const monthlyPrincipal = principal / BigInt(totalPeriods);
  const schedule: RepaymentScheduleEntry[] = [];
  let remainingPrincipal = principal;

  for (let i = 1; i <= totalPeriods; i++) {
    const interest = BigInt(Math.round(Number(remainingPrincipal) * monthlyRate));

    // 最后一期调整尾差
    const principalPayment = i === totalPeriods
      ? remainingPrincipal
      : monthlyPrincipal;

    remainingPrincipal -= principalPayment;

    schedule.push({
      period: i,
      dueDate: addMonths(startDate, i),
      principalAmount: principalPayment,
      interestAmount: interest,
      totalAmount: principalPayment + interest,
      remainingPrincipal,
    });
  }

  return schedule;
}

function addMonths(date: Date, months: number): Date {
  const result = new Date(date);
  result.setMonth(result.getMonth() + months);
  return result;
}

四种还款方式对比：

4. 逾期管理架构

stateDiagram-v2
    [*] --> 正常: 按时还款

    正常 --> 宽限期: 超过还款日
    宽限期 --> 正常: 宽限期内还款
    宽限期 --> 逾期: 超过宽限期仍未还

    逾期 --> 逾期1_30: 逾期1-30天
    逾期1_30 --> 逾期31_60: 持续逾期
    逾期31_60 --> 逾期61_90: 持续逾期
    逾期61_90 --> 不良: 逾期>90天

    逾期1_30 --> 正常: 补齐欠款
    逾期31_60 --> 正常: 补齐欠款
    逾期61_90 --> 正常: 补齐欠款

    不良 --> 关注: 协商还款/展期
    不良 --> 可疑: 持续恶化
    可疑 --> 损失: 无法收回

    损失 --> 核销: 审批核销
    核销 --> [*]

    关注 --> 正常: 恢复正常还款

逾期的五级分类（银行业监管要求）：

逾期处理的系统架构：

interface OverdueManagement {
  // 逾期检测（日终批处理）
  detectOverdue(): OverdueAccount[];

  // 罚息计算
  calculatePenaltyInterest(
    overdueAmount: bigint,
    overdueDays: number,
    penaltyRate: number
  ): bigint;

  // 催收分案
  assignCollection(
    overdueAccounts: OverdueAccount[],
    strategy: CollectionStrategy
  ): CollectionCase[];

  // 五级分类
  classifyRisk(account: LoanAccount): RiskCategory;
}

// 催收分案策略
interface CollectionStrategy {
  // 按逾期天数分级
  tiers: CollectionTier[];
}

interface CollectionTier {
  minOverdueDays: number;
  maxOverdueDays: number;
  method: 'SMS' | 'IVR' | 'MANUAL_CALL' | 'LEGAL' | 'OUTSOURCE';
  priority: number;
}

// 示例策略
const defaultStrategy: CollectionStrategy = {
  tiers: [
    { minOverdueDays: 1,   maxOverdueDays: 7,   method: 'SMS',          priority: 3 },
    { minOverdueDays: 8,   maxOverdueDays: 30,  method: 'IVR',          priority: 2 },
    { minOverdueDays: 31,  maxOverdueDays: 90,  method: 'MANUAL_CALL',  priority: 1 },
    { minOverdueDays: 91,  maxOverdueDays: 180, method: 'LEGAL',        priority: 0 },
    { minOverdueDays: 181, maxOverdueDays: 9999, method: 'OUTSOURCE',   priority: 0 },
  ]
};

5. 贷款定价模型（FTP/风险定价）

FTP（Fund Transfer Pricing，内部资金转移定价）：

贷款利率 = FTP基准 + 风险溢价 + 运营成本 + 资本成本 + 利润目标

其中：
- FTP基准：银行内部资金成本（从资金部"购买"资金的价格）
- 风险溢价：根据客户信用等级确定的风险补偿
- 运营成本：审批、放款、催收等运营成本分摊
- 资本成本：资本充足率要求下的资本占用成本
- 利润目标：银行期望的利润率

graph LR
    subgraph "资金端(负债)"
        D1[活期存款 0.2%]
        D2[定期存款 1.65%]
        D3[同业拆借 2.0%]
    end

    subgraph "FTP中台"
        FTP[资金池<br/>加权平均成本<br/>≈ 1.5%]
    end

    subgraph "资产端(贷款)"
        L1[房贷 = FTP+1% = 2.5%]
        L2[消费贷 = FTP+4% = 5.5%]
        L3[经营贷 = FTP+3% = 4.5%]
    end

    D1 & D2 & D3 -->|存入| FTP
    FTP -->|借出| L1 & L2 & L3

6. 贷后管理系统

graph TB
    subgraph "贷后监控"
        M1[还款行为监控<br/>逾期、提前还款]
        M2[担保物监控<br/>房产价值、质押品]
        M3[客户经营监控<br/>企业经营数据]
        M4[外部数据监控<br/>征信变化、涉诉]
    end

    subgraph "风险预警"
        W1[预警模型<br/>AI/规则引擎]
        W2[预警分级<br/>红/橙/黄/蓝]
        W3[预警分发<br/>客户经理/风控]
    end

    subgraph "处置措施"
        P1[提前收回]
        P2[追加担保]
        P3[贷款展期]
        P4[贷款重组]
        P5[资产转让]
    end

    M1 & M2 & M3 & M4 --> W1 --> W2 --> W3
    W3 --> P1 & P2 & P3 & P4 & P5

---

对比分析

传统贷款 vs DeFi借贷

---

架构设计实操

实操：设计"消费贷"全流程架构

设计目标：为一家数字银行设计消费贷产品的完整系统架构，支持全线上办理、秒级审批、自动放款。

BPMN业务流程：

graph TB
    START((开始)) --> A1[客户申请<br/>填写信息/人脸识别]
    A1 --> A2{准入检查}
    A2 -->|通过| A3[征信查询<br/>+内部数据]
    A2 -->|拒绝| REJ1[拒绝]
    A3 --> A4[AI信用评分]
    A4 --> A5{评分结果}
    A5 -->|高分自动批| A6[自动审批<br/>确定额度/利率]
    A5 -->|中分人工审| A7[人工审批]
    A5 -->|低分拒绝| REJ2[拒绝]
    A7 --> A8{审批结果}
    A8 -->|通过| A6
    A8 -->|拒绝| REJ3[拒绝]
    A6 --> B1[电子签约]
    B1 --> B2[客户支用<br/>选择金额/期数]
    B2 --> B3{放款审核<br/>反欺诈复核}
    B3 -->|通过| B4[放款执行<br/>记账+转账]
    B3 -->|拒绝| REJ4[拒绝]
    B4 --> C1[正常还款<br/>每月代扣]
    C1 --> C2{还款状态}
    C2 -->|正常| C3[继续还款]
    C2 -->|逾期| C4[逾期处理]
    C2 -->|结清| C5[贷款结清]
    C4 --> C6[催收]
    C3 --> C2
    C5 --> END((结束))

DDD领域模型：

classDiagram
    class CreditApplication {
        <<Aggregate Root>>
        +applicationId: string
        +customerId: string
        +requestAmount: Money
        +status: ApplicationStatus
        +creditScore: number
        +submit()
        +approve(limit, rate)
        +reject(reason)
    }

    class CreditFacility {
        <<Aggregate Root>>
        +facilityId: string
        +customerId: string
        +totalLimit: Money
        +usedLimit: Money
        +occupy(amount)
        +release(amount)
    }

    class LoanContract {
        <<Aggregate Root>>
        +contractId: string
        +facilityId: string
        +productCode: string
        +status: ContractStatus
        +sign()
        +activate()
    }

    class LoanReceipt {
        <<Aggregate Root>>
        +receiptId: string
        +contractId: string
        +principal: Money
        +outstandingPrincipal: Money
        +interestRate: number
        +repaymentSchedule: Schedule[]
        +disburse()
        +repay(amount)
        +overdue()
    }

    class RepaymentSchedule {
        <<Entity>>
        +period: number
        +dueDate: Date
        +principalDue: Money
        +interestDue: Money
        +status: ScheduleStatus
    }

    CreditApplication ..> CreditFacility : creates
    CreditFacility --> LoanContract : 1..*
    LoanContract --> LoanReceipt : 1..*
    LoanReceipt --> RepaymentSchedule : 1..*

借据（Loan Receipt）状态机：

stateDiagram-v2
    [*] --> 待放款: 支用申请通过
    待放款 --> 还款中: 放款成功
    待放款 --> 已取消: 客户取消/放款失败

    还款中 --> 逾期: 超过还款日未还
    逾期 --> 还款中: 补齐欠款
    逾期 --> 展期: 协商展期
    展期 --> 还款中: 新计划生效
    逾期 --> 不良: 逾期>90天

    还款中 --> 提前结清: 客户提前全额还款
    还款中 --> 正常结清: 最后一期还完

    不良 --> 核销: 审批核销
    不良 --> 还款中: 协商还款恢复

    提前结清 --> [*]
    正常结清 --> [*]
    核销 --> [*]
    已取消 --> [*]

关键序列图——放款流程：

sequenceDiagram
    participant C as 客户
    participant APP as 消费贷服务
    participant CREDIT as 授信服务
    participant RISK as 风控引擎
    participant ACCT as 记账引擎
    participant PAY as 支付服务

    C->>APP: 1. 提交支用申请(金额/期数)
    APP->>CREDIT: 2. 检查可用额度
    CREDIT-->>APP: 3. 额度充足

    APP->>CREDIT: 4. 冻结额度
    APP->>RISK: 5. 放款前反欺诈检查
    RISK-->>APP: 6. 风控通过

    APP->>APP: 7. 生成还款计划
    APP->>ACCT: 8. 记账: 借-发放贷款, 贷-客户账户
    ACCT-->>APP: 9. 记账成功

    APP->>PAY: 10. 执行放款(转账到客户账户)
    PAY-->>APP: 11. 放款成功

    APP->>CREDIT: 12. 确认占用额度(解冻→占用)
    APP-->>C: 13. 放款完成通知

---

AI增强实践

1. AI驱动的信用评分

场景：用AI模型替代传统规则卡实现自动审批

# 简化的AI信用评分特征工程
features = {
    # 传统特征
    'age': 35,
    'income_monthly': 15000,
    'employment_years': 5,
    'existing_loans': 2,
    'credit_card_utilization': 0.3,
    'delinquency_count_2y': 0,

    # 替代数据特征（AI增强）
    'phone_usage_stability': 0.95,      # 手机号使用稳定性
    'social_network_diversity': 0.7,    # 社交网络多样性
    'consumption_pattern_score': 0.8,   # 消费行为评分
    'location_stability': 0.9,          # 地理位置稳定性
}

Prompt示例（审批决策辅助）：

你是银行信贷审批专家。请分析以下贷款申请：

申请人信息：
- 年龄：28岁，单身
- 月收入：¥12,000
- 工作年限：3年，互联网公司
- 现有负债：房贷月供¥3,500，信用卡欠款¥8,000
- 征信记录：无逾期
- 申请金额：¥80,000，12期

请从以下维度分析：
1. 还款能力评估（月收入/月还款 比率）
2. 负债比率分析
3. 风险点识别
4. 建议额度和利率
5. 审批建议（通过/降额/拒绝）

2. AI辅助还款计划优化

Prompt示例：

客户有以下贷款：
1. 房贷：余额¥120万，利率3.45%，剩余25年
2. 消费贷A：余额¥5万，利率8%，剩余6期
3. 信用卡：余额¥2万，利率18%，最低还款

客户每月可支配还款额：¥12,000

请设计最优还款策略：
1. 雪崩法（优先还高利率）vs 雪球法（优先还小额）
2. 是否建议提前还房贷
3. 总利息节省估算

3. 人机边界

---

与Web3/DeFi的关联

深度洞察：DeFi借贷的"自动清算"机制消除了传统贷款中最痛苦的环节——催收和不良处置。但代价是只能做超额抵押贷款（资本效率低）。链上信用系统（如Spectral、Cred Protocol）正在尝试建立DeFi世界的"征信系统"，如果成功，将开启DeFi信用贷款的大门——这将是万亿美元级别的市场机会。

---

今日思考

1. DeFi的"自动清算"消除了催收成本，但引入了"清算风险"（如2022年LUNA崩盘导致的连环清算）。如果你要设计一个CeFi-DeFi混合借贷产品，如何结合传统催收和自动清算的优势？

2. 还款计划引擎看似简单（就是数学公式），但"提前还款重算"是一个极其复杂的场景（涉及已还利息退还、违约金、剩余期重新分摊等）。如果把还款计划放到智能合约上执行，有什么架构优势和挑战？

3. "授信"在DeFi中被"抵押率"替代，不需要人工评估。但这也意味着DeFi无法服务无资产人群（最需要贷款的恰恰是没有抵押物的人）。链上信用贷款（Under-collateralized Lending）如何设计才能既保持去中心化又控制风险？

---

面试题准备

Q1: 如何设计灵活的还款计划引擎？

30秒版本： 还款计划引擎的核心是"策略模式"——不同还款方式（等额本息/等额本金/先息后本）实现同一个接口，由产品参数决定使用哪种策略。关键是处理好"变更场景"：提前还款、利率调整、逾期罚息，每种场景都需要重新生成剩余期的计划。

2分钟版本：

灵活的还款计划引擎需要三层设计：

第一层：计算策略层。每种还款方式是一个独立的Strategy实现。新增还款方式只需要新增Strategy，不影响已有逻辑。

第二层：变更处理层。还款计划不是一次生成永不变的——提前还款、部分提前还款、利率调整、展期都会触发"重新生成"。核心是保存每次变更的"快照"，记录变更原因和前后对比。

第三层：执行监控层。每期到期时，系统自动对比"应还"和"实还"，触发正常/逾期/提前还款等不同后续流程。

关键设计决策：还款计划是"预生成"还是"实时计算"？

• 预生成：提前把所有期的计划都算好存库。优点是查询快，缺点是变更时需要重新生成
• 实时计算：只存规则参数，每次查询时实时计算。优点是永远最新，缺点是计算量大
• 推荐：混合方案——预生成+变更时重新生成+缓存

追问准备：

• 追问：提前还款如何处理已收利息？ → 按两种模式：1)按实际天数重新计息，多收的利息退还；2)按合同约定收取违约金。具体取决于监管政策和合同条款
• 追问：大量贷款同时到期（月末），还款批扣如何保证性能？ → 分批扣款（按账户哈希分片）、预生成扣款指令（T-1准备）、失败重试机制（T+1二次扣款）

Q2: 逾期处理的架构挑战是什么？

30秒版本： 逾期处理的核心挑战是状态管理的复杂性和多系统协调。一笔逾期贷款涉及账务系统（罚息计提）、催收系统（分案派单）、风控系统（五级分类）、监管报送（不良率统计）等多个系统的协同，每个系统对逾期的定义和时间窗口还可能不同。

2分钟版本：

逾期处理有三大架构挑战：

第一，逾期检测的时效性。传统日切批处理中，逾期检测是日终Job。但实际场景中，客户可能在宽限期最后一刻还款——需要精确到时间点的判断。如果检测太早（还在宽限期）会误判；太晚会延迟罚息计算。

第二，罚息计算的复杂性。罚息不只是"逾期金额×罚息率×天数"。需要考虑：宽限期内是否免罚息？罚息是否复利？本金逾期和利息逾期是否同一罚息率？部分还款后如何重新计算？不同产品的罚息规则可能完全不同。

第三，多系统一致性。逾期状态变更需要通知：

• 账务系统：计提罚息、更新五级分类
• 催收系统：创建催收案件、分案
• 征信系统：报送逾期记录
• 风控系统：更新客户风险标签
• 额度系统：冻结/降低授信额度

这些操作涉及多个系统，需要用事件驱动（Event-Driven）方式解耦，但也要保证最终一致性。

追问准备：

• 追问：客户投诉"已还款但仍被报征信逾期"怎么办？ → 这是典型的多系统状态不一致问题。需要：1)核查还款到账时间和征信报送时间；2)如确实已还，触发征信更正流程；3)根因分析——通常是批处理时序问题或系统间消息丢失
• 追问：逾期减免（部分减免罚息）如何设计？ → 减免需要审批流程+记账处理。记账上是"借:应收罚息（资产减少），贷:营业外支出或坏账准备"。系统需要记录减免原因、审批人、金额，供审计追溯

---

学习资源

1. 《信贷的逻辑与常识》刘新海 — 深入理解信贷业务本质
2. 巴塞尔协议III相关文件 — 信贷风险管理的监管框架
3. Aave V3 Technical Paper — DeFi借贷架构的最佳实践
4. 《消费金融真经》 — 消费信贷的产品和风控实务
5. Maple Finance / Goldfinch Documentation — DeFi信用贷款的前沿尝试

---

明日预告

Day 36: 信用卡系统架构 — 信用卡是银行零售业务的"利润之王"，也是系统复杂度最高的业务之一。我们将深入四方模型、毫秒级交易授权、账单计算逻辑、分期业务架构、积分系统和实时反欺诈的架构设计。