2. 信贷业务基础

信贷核心系统的实施，本质上不是把一堆表、字段和接口堆起来，而是把一笔贷款从“客户申请”到“结清销户”的完整业务规则翻译成系统可执行的状态机、参数与账务逻辑。因此，在动手配置产品、编写放款与还款逻辑之前，必须先建立对信贷业务的整体认知。本节围绕六个基础维度展开：全生命周期、产品类型、利率与费用、还款方式、担保方式以及监管要求。

一、核心原理：信贷全生命周期是一条状态主线

信贷全生命周期是贯穿整个系统的“主心骨”。无论产品如何变化，一笔贷款通常都会经历申请、审批、签约、放款、计息、还款、逾期、结清等阶段。系统实施时，关键是把每个阶段映射为明确的状态与事件，并定义状态之间的迁移条件。

从系统视角看，生命周期管理要回答三个问题：当前处于什么状态、什么事件触发迁移、迁移后产生什么账务与数据结果。例如“审批通过”触发额度占用，“放款成功”触发本金出账与计息起算，“还款入账”触发本息冲销与状态更新。状态机设计不清，后续对账、逾期、核销都会连锁出错。

二、产品类型：决定系统参数化边界

信贷产品是业务规则的集合。常见分类包括：按用途分为消费贷、经营贷、住房按揭；按期限分为短期、中期、长期；按担保分为信用贷、保证贷、抵押贷、质押贷；按还款方式分为等额本息、等额本金、先息后本、到期一次还本付息等。系统实施时，产品类型直接决定参数化范围：哪些字段可配置、哪些规则必须硬编码、哪些需要走审批流。

例如消费贷通常金额小、期限短、审批自动化程度高；经营贷金额大、需评估现金流与担保；住房按揭期限长、利率随LPR浮动、还款计划复杂。产品建模时，建议把“产品属性”与“产品规则”分离：属性描述是什么，规则描述怎么算。

三、利率与费用：定价是账务的源头

利率是信贷定价的核心。系统需支持固定利率、浮动利率（挂钩LPR等基准）、罚息利率、复利等。费用则包括手续费、服务费、提前还款违约金、逾期罚息等。实施中最容易出错的是计息基数、计息天数规则（如ACT/365、ACT/360、30/360）以及利率调整方式。

计息示例（单利，ACT/365）：
本金 = 100,000 元
年利率 = 6.5%
计息天数 = 90 天
利息 = 100000 × 6.5% × 90 / 365 ≈ 1602.74 元

罚息规则：
逾期本金 × 罚息利率（如年利率上浮50%）× 逾期天数 / 365

四、还款方式与担保方式：影响现金流与风险缓释

还款方式决定每期还款额与本金利息结构。等额本息每期金额相同，前期利息占比高；等额本金每期本金相同，利息递减；先息后本适合短期周转；到期一次还本付息常见于小额短期。系统需根据还款方式生成还款计划表，并支持提前还款、部分还款、展期等变更。

担保方式是风险缓释手段，包括信用、保证、抵押、质押。系统需记录担保物信息、评估价值、抵押率、担保期限，并与贷款状态联动。例如抵押登记未落实，放款条件不满足，系统应阻断放款。

五、监管要求：合规是系统不可逾越的底线

信贷业务受严格监管，系统实施必须内置合规校验。常见要求包括：利率不得超过司法保护上限；必须接入征信系统并如实报送；反洗钱与客户身份识别；贷款用途监控；数据安全与个人信息保护。实施时，这些要求应转化为系统规则与校验点，而不是依赖人工事后检查。

六、案例与复盘：一次还款计划配置错误

某消费贷产品上线后，客户投诉首期还款额与合同不符。排查发现：产品配置中还款方式选为“等额本息”，但计息天数规则误设为ACT/360，而合同约定ACT/365。系统按360天计息，导致每期利息偏高。复盘结论：利率与计息规则必须与合同条款一一对应，并在产品上线前做还款计划试算比对。

另一个案例是抵押贷放款时未校验抵押登记状态，导致放款后抵押未落实。整改措施是在放款流程中增加“担保落实”前置校验节点，未通过则阻断出账。这说明生命周期中的状态迁移必须与担保、合规等条件绑定。

综上，信贷业务基础不是孤立的知识点，而是相互咬合的一套规则体系。全生命周期是主线，产品类型划定边界，利率费用决定账务，还款方式影响现金流，担保方式缓释风险，监管要求守住底线。只有把这些基础打牢，后续的核心系统实施才能稳定、可扩展、可审计。