3. 人工调整的常见场景
监管报送的人工调整并不是“想改就改”，而是由明确的触发原因驱动、经过审批授权、并留下完整证据链的受控动作。理解常见触发场景，是设计调整流程、判断审批层级、确定留痕颗粒度的前提。本节围绕四类高频触发原因展开：数据差错、口径差异、系统取数异常、业务实质调整，并给出对应的留痕要点与判断方法。
一、核心原理：调整的本质是“原因分类 + 责任归属”
任何一笔人工调整，都必须回答两个问题：为什么改（触发原因）和谁有权改（审批层级）。触发原因决定了证据类型，审批层级决定了留痕深度。四类场景在“可预防性”和“可追溯性”上差异明显：数据差错和系统取数异常偏向技术性、可修复；口径差异偏向规则性、需统一解释；业务实质调整偏向判断性、需业务确认。若把四类场景混为一谈，就会出现“技术错误走了业务审批”或“业务判断只留了操作日志”的错配。
二、四类场景的识别方法与留痕要点
识别场景的关键是“先定位差异来源，再匹配证据类型”。以下清单可作为日常判断依据：
| 触发场景 | 典型表现 | 核心证据 | 审批层级 | 常见误区 |
|---|---|---|---|---|
| 数据差错 | 金额、日期、机构代码录入错误 | 原始凭证、更正前后对照 | 经办 + 复核 | 只改数不留原始值 |
| 口径差异 | 同一指标两套统计范围 | 口径说明、监管问答、会议纪要 | 业务 + 合规 | 口头确认无书面依据 |
| 系统取数异常 | 接口超时、字段截断、逻辑缺陷 | 系统日志、故障工单、补数记录 | 科技 + 报送 | 手工补数不留工单号 |
| 业务实质调整 | 资产分类重判、风险等级调整 | 业务说明、审批单、会议决议 | 业务负责人 | 以“技术调整”名义规避审批 |
三、典型案例：一笔同业投资的风险分类调整
某银行在报送G31表时，发现一笔同业投资原按“正常”分类，但业务部门在季度重检中认为交易对手出现舆情风险，应调整为“关注”。这属于典型的业务实质调整，而非数据差错。正确做法是：业务部门出具风险分类调整说明，附舆情报告与内部评级变化记录，经业务负责人和风险负责人双签后，由报送岗在系统中执行调整，并保留调整前后分类、调整依据文号、审批人及时间戳。若仅由报送人员根据口头通知直接改数，则一旦监管问询，无法证明调整的合理性与授权来源。
高风险信号：当调整原因被描述为“系统问题”但无法提供日志或工单，或调整金额恰好使指标跨过监管阈值时，应提高审批层级并单独记录说明。这类调整最容易在检查中被认定为“人为干预报送结果”。
四、误区复盘与流程固化
常见误区有三类：其一，原因错配——把口径差异当作数据差错处理，导致证据链缺少口径依据；其二，留痕断点——只记录调整后值，丢失调整前值和触发原因；其三，审批越权——技术性调整走了业务审批，或业务判断仅由经办人自行处理。复盘时应逐笔核对“原因—证据—审批”三者是否匹配。
固化建议：在报送系统中将四类触发原因设为必选下拉项，不同选项自动带出对应的证据附件要求和审批路由。例如选择“系统取数异常”时，强制填写工单号；选择“业务实质调整”时，强制上传审批单。这样可以把场景识别从“靠人记忆”变为“靠流程约束”。
调整留痕最小字段示例：
adjust_id 调整流水号
report_code 报表编号
item_name 指标名称
value_before 调整前值
value_after 调整后值
trigger_type 触发原因（数据差错/口径差异/系统异常/业务实质）
evidence_ref 证据引用（凭证号/工单号/审批单号）
approver 审批人
approve_time 审批时间
operator 操作人
operate_time 操作时间