2. 基础知识

在进入授信决策引擎的API设计与策略服务实现之前，必须先建立对授信业务的共同语言。很多技术方案之所以在落地时反复返工，并不是因为代码写得不好，而是因为工程师对“额度”“敞口”“授信”“用信”等概念的理解与业务方不一致。本章从业务视角梳理授信领域的核心概念、术语体系、参与角色与典型场景，为后续的规则建模、接口设计和策略编排打下语义基础。

一、核心原理：授信的本质是风险定价与额度约束

授信（Credit Granting）是指金融机构基于对客户的信用评估，给予其在未来一段时间内、在一定条件下获得融资或信用便利的承诺。它的本质包含两个层面：一是风险判断，即“该不该给”；二是额度与条件约束，即“给多少、怎么给、什么条件下收回”。

从系统视角看，授信决策引擎要回答的核心问题可以归纳为一条决策链：

• 准入判断：客户是否满足基本资格，是否存在禁入规则命中。
• 额度核定：基于收入、资产、负债、征信、行为数据计算建议额度。
• 定价与期限：确定利率、费率、还款方式与授信有效期。
• 用信控制：在授信额度内，控制单笔支用、循环支用与冻结解冻。
• 贷后管理：监控风险变化，触发降额、冻结或提前收回。

这条决策链在系统中通常被抽象为“策略集 + 规则 + 评分卡 + 决策流”，而API接口则是这条链对外暴露的契约。理解业务概念，才能设计出语义清晰、可扩展的接口。

二、常见术语体系：从授信到用信的关键概念

授信业务术语繁多，且不同机构口径略有差异。下表整理了课程后续会反复使用的核心术语，建议先建立统一认知。

三、参与角色与应用场景

授信业务不是单一系统能完成的，它涉及多个角色协同。理解角色职责，有助于划分API的调用方与权限边界。

• 客户：发起授信申请、用信申请、还款操作，是最终用户。
• 客户经理/渠道：负责客户拓展与资料收集，通过渠道系统调用授信API。
• 风控策略人员：设计规则、评分卡与决策流，配置策略版本。
• 审批人员：对高风险或超阈值案件进行人工复核。
• 资金/账务系统：负责放款、还款、额度占用与释放。
• 决策引擎：执行策略，输出授信结论、额度、定价与原因码。
• 贷后监控系统：持续监控风险信号，触发降额、冻结等动作。

典型应用场景包括：

1. 新客授信申请：客户提交资料，引擎执行准入规则、征信查询、评分卡与额度模型，输出授信结果。
2. 额度调整：基于贷后行为或主动申请，重新评估额度，可能提额、降额或维持。
3. 用信支用：在可用额度内发起支用，引擎校验额度、期限、用途与风险状态。
4. 循环支用与还款：还款后恢复额度，支持多次循环支用。
5. 风险冻结与解冻：命中风险规则时冻结额度，风险解除后解冻。

四、案例与复盘：一个典型的授信决策请求

下面以一个简化的授信申请请求为例，展示业务概念如何映射到接口参数。该请求由渠道系统发起，决策引擎返回授信结论。

POST /api/v1/credit/decision
{
  "requestId": "REQ202405200001",
  "scene": "NEW_CREDIT_APPLY",
  "customer": {
    "customerId": "C10086",
    "idType": "ID_CARD",
    "idNo": "310***********1234",
    "name": "张三",
    "age": 32
  },
  "applyInfo": {
    "productCode": "CASH_LOAN_001",
    "applyAmount": 50000,
    "applyTerm": 12,
    "purpose": "CONSUME"
  },
  "auth": {
    "creditQueryAgreed": true,
    "agreementNo": "AGR20240520001"
  }
}

引擎返回结果通常包含结论、额度、定价与原因码：

{
  "requestId": "REQ202405200001",
  "decision": "PASS",
  "creditLimit": 30000,
  "availableLimit": 30000,
  "pricing": {
    "annualRate": 0.108,
    "term": 12
  },
  "reasonCodes": ["SCORE_GOOD", "INCOME_STABLE"],
  "strategyVersion": "STRATEGY_202405_V3"
}

复盘这个案例，有几个常见误区值得注意：

• 误区一：把授信额度等同于放款金额。授信额度是上限，实际用信可能小于额度，系统需分别管理。
• 误区二：忽略额度占用与释放的并发问题。多笔用信同时发起时，必须保证可用额度扣减的原子性。
• 误区三：原因码设计过于随意。原因码是策略可解释性与监管合规的关键，应统一编码并支持多语言映射。
• 误区四：策略版本未透出。响应中应包含策略版本，便于问题追溯与灰度对比。