警惕!银行风控模型或将“摇身一变”,成为风险缔造者( 五 )


? 模型接口的规范 。 在笔者的实践中 , 银行大量联合贷款的流量数据都是来自场景方 , 其数据质量远远不如银行本身的金融数据 , 所以需要严格明确接口规范 。
10.系统管理模块
本模块包含管理规则的配置功能和系统日志管理功能等本身系统管理工具 , 尤其强调的是平台与数据源的数据传输能力与敏捷性 。
(三)模型管理平台的逻辑架构
模型管理平台建设的主要目的:一是 , 发挥数据、算法的最大效能 , 赋能业务发展;二是 , 以工厂流水线的方式加工数据、特征、模型 , 减少重复工作 , 提高工作效率 , 并降低模型风险 。
模型管理平台的逻辑架构如下:首先 , 数据工厂统一汇总银行的大数据资源 , 规范数据来源、数据口径、数据标准和存储架构 , 并实现内外部数据有效整合;其次 , 特征工厂从数据层进行特征萃取 , 并形成稳定的特征层;再次 , 模型工厂从特征层进行模型的开发工作;最后 , 由模型服务平台向全行提供“模型服务” 。
警惕!银行风控模型或将“摇身一变”,成为风险缔造者
本文插图
数据是数字科技时代的生产资料 , 将银行内部和外部数据进行有效整合 , 将实现数据驱动 , 极大程度赋能银行业务 。 算法与数据结合 , 将充分激发数据的效能 , 共同构筑数字科技时代的新型生产力 。 笔者认为其技术难点在于:数据的有效整合、算法的通用性解耦、算法与数据(参数)的合理封装 , 在此不做过多赘述 。
构筑模型风险管理体系
(一)模型风险管理的组织架构
无论是美联储的《模型风险管理监督指南(SR11-7)》 , 还是中国银保监会正式发布《商业银行互联网贷款管理暂行办法》 , 对于风险管理体系的组织架构要求 , 基本都是“三道防线”的架构 , 三道防线在组织上相互独立 , 职责上各司其职 , 并且同时向银行的董事会或者高级管理层负责 。
? 第一道防线:模型的开发和使用部门 , 职责为:模型的开发、实施、使用 , 并配合模型的验证和监控 。
? 第二道防线:模型的验证部门 , 职责为:对模型进行独立验证 。
? 第三道防线:内部审计部门 , 职责为:审查和评估模型风险管理是否完整、严谨、有效 。
这三道防线的作用是显而易见的 , 但是 , 笔者建议加大第二道防线中模型验证部门的“挑战激励” , 将“成功挑战”纳入模型验证人员的KPI激励中 。 在实际工作中 , “挑战思维”在银行似乎有些另类 , 以挑战为目的模型验证在银行的传统文化中慢慢的回归于“合规思维” , 因此笔者建议 , 将“成功挑战”纳入模型验证人员的KPI激励中 。
另外 , 笔者预言 , 金融科技将实现模型风险“端到端”的管理 , 并有效整合第一道防线与第二道防线的职责 。 随着金融科技的发展 , 在信贷审批领域已经实现了端到端的风险管理 , 这种新的风险管理模式实际上是跨越第一道和第二道防线 。 与此相似 , 对模型风险进行端到端的管理也将会得到认可和普及 , 模型管理平台的搭建将有效的、自动化的、流程化的整合第一道防线与第二道防线的职责 。
(二)模型风险管理的政策体系
政策体系不仅要自上而下的包含组织架构、部门职责 , 更应该细化到具体的报告模版 。 政策体系的建立 , 应该是银行的强项 , 所以 , 笔者根据自己的工作经验 , 提出三点建议:
1.设计良好的风险传导机制 , 将模型风险有效整合进银行的风险偏好 , 纳入银行全面风险管理体系 。
2.模型技术部门需从以技术为主的职能定位过渡到模型风险管理的管理定位 。
3.需要建立一套模型风险管理团队与高级管理层合适的沟通方式 , 以便与高级管理人员交流技术话题 。
警惕!银行风控模型或将“摇身一变”,成为风险缔造者