1. 课程导入

欢迎进入《信贷核心系统产品参数与合同建模实战》。在银行、消费金融、小贷与互联网金融平台中，信贷核心系统承担着产品定义、额度授信、放款计息、还款计划、逾期处置与账务核算等关键职责。很多从业者会写需求、会画流程，却难以把“业务规则”稳定地翻译成“系统参数与合同结构”。本课程要解决的，正是这一层从业务语言到系统语言的建模能力。

一、学习目标：从“会描述业务”到“能落地建模”

本课程不是产品经理的业务科普，也不是纯技术开发课，而是面向信贷产品、需求、测试、运营、风控与研发协同的“建模实战课”。学完后，你应当具备四项可验证的能力：

• 参数化表达能力：能把利率、期限、还款方式、费用、宽限期、罚息等业务规则，拆解为可配置、可版本化的产品参数。
• 合同结构化能力：能设计借款合同、额度合同、担保合同及其关联关系，明确主从合同、要素快照与变更留痕。
• 规则映射能力：能把产品参数与合同条款映射到试算、放款、还款、计息、核销等核心交易链路。
• 复盘与排障能力：面对“试算与放款不一致”“提前还款金额对不上”等问题，能定位是参数、合同还是账务层的问题。

二、核心概念：产品参数、合同模型与要素快照

信贷核心系统的本质，是“以合同为载体，以参数为规则，以交易为驱动”的计算系统。理解三个核心概念，是后续所有章节的基础。

产品参数是产品层面的规则集合，例如年化利率、计息方式（按日/按月）、还款方式（等额本息、等额本金、先息后本）、费用项、宽限期天数、罚息利率上浮比例等。参数决定“这类产品怎么算”。

合同模型是客户层面的法律与账务载体，记录借款金额、期限、利率、还款计划、担保信息、放款与还款账户等。合同决定“这笔业务怎么执行”。

要素快照是合同生效时对产品参数与客户信息的固化。产品参数后续调整，不应影响已生效合同，除非走合同变更流程。这是信贷系统稳定性的关键设计。

概念	作用层级	典型内容	变更影响
产品参数	产品/方案层	利率、期限、还款方式、费用、罚息	影响新签合同，通常不追溯存量
合同模型	客户/借据层	金额、期限、还款计划、担保、账户	影响单笔业务执行与账务
要素快照	合同生效时点	参数版本、客户信息、签署信息	保证历史可追溯、可审计

三、整体框架：从产品配置到合同执行的五层结构

为了便于理解，我们把信贷核心系统的建模工作划分为五层：产品层、参数层、合同层、交易层与账务层。产品层定义业务形态；参数层把规则数字化；合同层承载法律与客户约定；交易层执行放款、还款、计息等动作；账务层完成分录、核销与对账。五层之间通过“参数引用—合同快照—交易驱动—账务落账”形成闭环。

这张结构图建议你在学习后续章节时反复回看：任何一次业务需求变更，都要先判断它落在哪一层，再决定是改参数、改合同模板，还是改交易与账务规则。

四、实战价值：为什么参数与合同建模决定系统成败

在真实项目中，参数与合同建模的质量，直接决定三件事：上线速度、资金准确性、审计合规性。参数设计得清晰，新产品上线可能只需配置而非开发；合同模型设计得合理，提前还款、展期、利率调整才能算得准；要素快照与变更留痕做得扎实，面对监管检查与客户投诉才能说得清。

五、常见误区与复盘视角

初学者最容易陷入以下误区，建议在课程开始时就建立警惕：

1. 把参数当常量写死：利率、费用一旦硬编码，后续产品调整就要改代码，回归成本极高。
2. 合同与参数不分层：产品参数调整后直接影响存量合同，导致历史账务被“重算”。
3. 忽略要素快照：合同生效时未固化参数版本，出现纠纷时无法还原当时规则。
4. 只关注正常还款：提前还款、逾期、展期、减免等异常场景才是建模的真正难点。

下面用一段简化的参数配置片段，帮助你建立“参数即数据”的直观感受。真实系统中，这类配置通常以产品参数表或配置中心的形式存在。

product_code: CASH_LOAN_001
product_name: 现金分期产品
rate:
  annual_rate: 0.18
  day_count_basis: ACTUAL_365
repayment:
  method: EQUAL_INSTALLMENT
  periods: 12
  due_day: 每月15日
fee:
  service_fee_rate: 0.02
  charge_mode: UPFRONT
grace:
  grace_days: 3
penalty:
  penalty_rate: 0.05
  penalty_base: OVERDUE_PRINCIPAL
snapshot:
  enabled: true
  version: V2024.01