风险与监管 — 需求背后的「为什么」

一句话总结

银行用别人的钱做生意，所以在自有资本、贷款审查、反洗钱、电子金融、消费者保护等方面受到严格监管，而这些监管有相当一部分会转化为 IT 需求。

为什么监管会变成 IT 需求

银行系统的需求说明书里满是看似与功能无关的条目：“交易日志保存 5 年”“访问记录单独存储”“禁止在界面上显示 STR 报告事实”“记录是否履行了说明义务”。这些全部来自监管。银行用存款这种别人的钱放贷，一旦倒闭，存款人和整个支付结算系统都会陷入危险。所以国家要求银行积累资本、留存流程、进行报告。IT 人员需要了解监管骨架的原因，就在于需求的“为什么”在那里。

资本与风险——BIS 比率与巴塞尔

银行吸收损失的能力来自自有资本。国际标准（巴塞尔委员会）要求自有资本与风险加权资产之比。每笔贷款的风险不同，同样是 100 亿韩元，国债和信用贷款的风险权重也不同，其加权合计就是风险加权资产。巴塞尔 III 的最低总资本比率为 8%，再加上缓冲资本，实际标准大约在 10.5% 左右；普通股一级资本（CET1）这类优质资本另有单独的最低要求。落到 IT 上，就是“必须能给所有贷款加上风险权重并每天汇总”。

贷款审查——5C

长期以来用于判断是否放贷的框架是 5C。

5C	考察内容
Character	还款意愿。信用记录、逾期记录。
Capacity	还款能力。收入、现金流、现有负债（DSR 之类的指标由此而来）。
Capital	自有资本。借款人投入了多少自己的钱。
Collateral	担保。还不上时可以收回的东西。
Conditions	条件。利率、经济形势、行业环境。

审查系统的数据项大体可以归入这五类。即使信用评分模型变得更加精细，框架也是一样的。

反洗钱——AML/KYC

银行必须识别客户（KYC）、监控交易，如有可疑就要报告。在韩国，规定这一义务的法律是《关于特定金融交易信息的报告及利用等的法律》（特定金融信息法），接收报告的机构是金融情报分析院（FIU）。

义务	内容
CDD/EDD	客户尽职调查。确认身份和实际所有人，对高风险客户进行强化尽职调查。
CTR	大额现金交易报告。一天内达到一定金额（目前为 1,000 万韩元）以上的现金存取，本身就要报告。
STR	可疑交易报告。无论金额大小，怀疑洗钱就要报告。其中包含判断。
保密	不得把已报告的事实告知客户。

IT 需求很明确：能运行交易监控规则的数据、客户风险等级和尽调日期、报告记录的隔离，以及让报告事实不会通过客户界面、通知、咨询记录泄露出去的设计。

电子金融与消费者保护

《电子金融交易法》涉及非面对面交易的安全。核心是访问介质（证书、OTP 等）的管理、交易记录的生成与保存、事故时的责任分担，以及确保安全性的义务。细则由《电子金融监督规定》规定，其中网络隔离、信息安全人员与预算比例之类的条款在最近几年正在放宽和重组，所以当下哪些有效，必须查阅当时的规定。《金融消费者保护法》涉及销售流程。适合性与适当性原则、说明义务、禁止不公平营业行为、禁止不当劝诱、广告监管这六项原则是其骨架，落到 IT 上就是“要把已作说明的事实和客户已确认的事实作为记录保存下来”。

内部控制与信息安全

金融公司治理相关法规要求设立内部控制标准，近来还引入了以文件形式规定每位高管责任范围的责任结构图。信息安全方面，访问控制、权限分离、日志保存、漏洞检查都由监督规定提出要求；个人信息则同时适用《个人信息保护法》和《信用信息法》。对 IT 人员来说，这意味着“要留下谁在何时看了什么，要分开开发人员和运维人员的权限，并且能把这些证据提交给审计”。

监管要求在系统中留下的痕迹

监管文件很长，但落到系统上时，会变成几种反复出现的要求。了解这些形态，即使来了新的监管，也知道该问什么。

不删除记录。 在 AML 调查、纠纷和审计中，会被问到“当时是什么值”。不断更新的表无法回答这个问题，所以重要的东西要作为历史累积，并由此计算当前值。

要求计算可复现。 资本比率、拨备这类数字，会被要求“给我看看是怎么得出来的”。只保存结果，几个月后就无法复现。要把输入、基准日、规定版本、代码版本与结果一起保存。

可疑交易由人判定，并记录判定。 自动拦截会挡住正常交易，自动放行又会漏掉报告义务。系统的作用是缩小候选范围摆到人面前，并记录其决定。

客户识别不是一次性的，而是周期性的。 复核周期因风险等级而异，而等级又随交易行为变化。所以 KYC 不是设计成开户界面，而是设计成持续运行的批处理。

报告有期限。 迟交或格式错误本身就是违规。报告批处理的失败必须像服务故障一样迅速被发现，同时还要有重新提交的途径。

分离权限。 创建交易的人和能修改其记录的人是同一个人，这本身就是审计发现的问题。如果还留着开发人员直接连接生产数据库的途径，通常就会在这里被查出来。

开发人员要问的问题有三个。 这个值的基准日是什么时候？是按哪个规定版本计算的？重新计算能得到同样的值吗？

实际工作中真正重要的事

第一，监管要求是有原因的。 问“为什么要把这份日志保存 5 年”，是有答案的；知道了答案，也就确定了要保存到什么程度。

第二，数字和条文会变。 比率、限额、保存期限会随着修订而变动。不要在代码里写成常量，而要放在策略表中，并一并写明依据的规定。

第三，STR 要按事实撰写。 规则引擎的输出是判断的依据，而不是结论；报告中要写入交易编号、金额、日期和规则。而且这些事实不能泄露给客户。

在下一个实验中，你将亲自实现五条检测规则、计算预警分数，并只依据事实撰写报告草稿。