2. 核心概念：风险评分、风险因子、评分卡模型与API的关系
在构建商户风险评分API之前，必须理解四个核心概念之间的逻辑链条：风险因子是原始输入，评分卡模型是计算引擎，风险评分是输出结果，而API是这一切的对外服务接口。它们之间的关系可以用一句话概括：API接收风险因子，驱动评分卡模型，产出风险评分。
2.1 风险因子：评分模型的输入原料
风险因子是影响商户信用风险水平的可量化指标，通常来源于商户注册信息、交易行为、外部征信数据等。每个因子对应API请求中的一个字段。
| 因子类别 | 典型因子 | 数据来源 | API字段示例 |
|---|---|---|---|
| 基础信息 | 经营时长、注册资本、行业类别 | 商户注册资料 | business_age, registered_capital |
| 交易行为 | 日均交易额、退款率、大额交易占比 | 交易流水 | avg_daily_amount, refund_rate |
| 外部征信 | 法人征信评分、企业涉诉次数 | 第三方数据源 | credit_score, litigation_count |
| 设备环境 | IP风险等级、设备指纹异常标记 | 风控SDK | ip_risk_level, device_anomaly |
设计要点：API接口定义时，每个风险因子必须明确数据类型、取值范围、缺失值处理策略。缺失值不应直接传空字符串，而应使用约定值（如
-999）或由API自动填充默认值。
2.2 风险评分：模型输出的量化结果
风险评分是一个数值，通常映射到商户的违约概率或欺诈概率。评分越高，代表风险越低（正向评分）或风险越高（反向评分）。API响应中必须明确评分含义。
- 正向评分（如300~850）：分数越高，风险越低，类似个人信用评分。
- 反向评分（如0~100）：分数越高，风险越高，常用于欺诈检测场景。
- 评分等级：将连续分数映射为离散等级（如A/B/C/D），便于业务决策。
// API响应示例：风险评分
{
"score": 725,
"score_type": "positive",
"grade": "B",
"probability_default": 0.023
}
2.3 评分卡模型：从因子到评分的计算引擎
评分卡模型是金融风控领域最经典的建模方法之一，具有可解释性强、计算效率高的特点。它将每个风险因子分段赋分，最终累加得到总分。
评分卡模型的核心公式：
总评分 = 基准分 + Σ(因子_i 的得分)
其中，因子_i 的得分 = 权重_i × 分段得分_i
评分卡 vs 机器学习模型：评分卡模型在API场景中的优势在于：① 计算逻辑透明，便于监管审计；② 单次推理耗时通常在1ms以内；③ 因子权重可人工调整，无需重新训练。对于复杂欺诈模式，可叠加机器学习模型作为补充。
2.4 四者关系：API是连接业务与模型的桥梁
下图展示了风险因子、评分卡模型、风险评分与API之间的完整数据流关系：
2.5 关系总结：分层解耦与职责划分
从API架构视角看，四个概念应遵循分层解耦原则，每一层只关注自己的职责：
| 层次 | 职责 | 变更影响范围 | API设计关注点 |
|---|---|---|---|
| 风险因子层 | 定义输入字段、数据格式、校验规则 | 新增因子需API版本升级 | 字段命名规范、必填/可选、默认值 |
| 评分卡模型层 | 执行评分计算逻辑、规则匹配 | 模型更新不影响API接口 | 模型版本号、热加载机制 |
| 风险评分层 | 输出评分、等级、决策建议 | 评分映射表可配置化 | 响应结构稳定、兼容扩展字段 |
| API服务层 | 鉴权、限流、日志、路由 | 基础设施变更不影响业务 | 幂等性、超时策略、错误码 |
常见误区：不要将评分卡模型的内部参数（如分段阈值、权重）暴露在API请求中。API只应接收原始风险因子，模型参数属于服务端配置，由风控团队统一管理。暴露模型参数会导致安全风险与版本混乱。
2.6 实际案例：一次完整的API评分调用
假设某支付平台接入商户风险评分API，以下是调用过程的因子-模型-评分对应关系：
// 请求：传入风险因子
POST /v1/merchant/risk-score
{
"merchant_id": "M2024001",
"business_age_months": 18,
"avg_daily_amount": 25000.00,
"refund_rate": 0.035,
"legal_person_credit": 680,
"industry_code": "5411"
}
// 评分卡模型内部计算（伪代码）
base_score = 600
age_score = segment_score(business_age_months, [0,6,12,24], [20,40,50,60])
amount_score = segment_score(avg_daily_amount, [0,10000,50000,100000], [30,50,40,30])
refund_score = segment_score(refund_rate, [0,0.02,0.05,0.10], [50,30,10,-10])
credit_score = segment_score(legal_person_credit, [0,600,700,800], [10,30,50,60])
total_score = base_score + age_score + amount_score + refund_score + credit_score
// 响应：返回风险评分
{
"code": 0,
"message": "success",
"data": {
"score": 730,
"grade": "B",
"probability_default": 0.018,
"risk_level": "low",
"suggestion": "approve",
"model_version": "v2.3.1"
}
}
通过这个案例可以清晰看到：API请求携带的是原始风险因子，服务端通过评分卡模型计算出风险评分，最终通过API响应返回给调用方。四个概念环环相扣，缺一不可。