美国模型风险监管体系介绍_模型验证重要性

python信用评分卡建模(附代码,博主录制)

美国模型风险监管体系介绍以及同盾的建议

 First things first. 为避免有些读者一上来就把标题理解偏了。我先澄清一下我们这里要讲的是模型风险,不是风险模型。为了更好地管控风险,金融机构开发和使用了各种模型,这些模型叫做风险模型。然而,模型本身也能带来风险,这个风险就叫做模型风险。所以,模型风险可以被认为是操作风险的一种。

在进一步描述模型风险之前,我们必须先理清楚什么是模型。按照美联储的定义,模型是“应用统计、经济、金融或数学理论、技术和假设将输入数据处理为定量估计的量化方法、系统或途径”。这个定义是相当广泛的,几乎涵盖了金融机构日常所使用的各种称之为“模型”或“策略”的东西,也决定了模型风险监管该有的广泛程度。

那么,模型的风险来自哪里?美国的监管认为主要来自于两个方面:一是模型自身的错误,包括模型设计、开发、以及IT实施时发生的错误(如统计理论应用的错误、目标变量设定的错误、样本选择的错误、变量挑选和衍生的错误、算法的错误、在信息系统中执行与开发时不一致等等)。二是模型被不适当地使用。比如说把为原有产品设计的模型直接套用在新产品上,或者是在市场环境或消费者行为习惯已经发生重大变化的情况下继续使用原有模型,等等。

为了引起读者的重视,请允许笔者用三个例子来说明模型风险的严重性。

例1:1998年长期资本管理(LTCM)的崩溃。由于采用了高杠杆的交易策略,公司计算机模型中的一个小错误被放大了几个数量级。尽管长期资本管理公司因拥有两位的诺贝尔经济学奖获得者而闻名于世,也逃不过因为模型在特定市场环境下失败而倒闭的命运。

例2:2012年,摩根大通(JP Morgan chase)因一个包含公式和操作错误的VAR模型而遭受了巨大的交易损失。这个被首席执行官杰米•戴蒙(Jaime Dimon)成为的“茶壶里的暴风雨”(tempest in a teapot)的事件,给摩根大通造成了62亿美元的损失。

例3: 大名鼎鼎的2007年的美国次贷危机。为什么说这也跟模型风险有关系呢?2002年至2007年期间,抵押贷款承销标准明显恶化。然而,这些贷款捆绑成MBS和CDO一直都具有高评级,投资者在很多情况下盲目依赖评级机构的评级结果,一直到2006年下半年房地产泡沫破裂,2007年和2008年初,相当一部分AAA CDO和MBS债券才最终被降级为垃圾债券。引用美国金融危机调查委员会的原话:“(评级机构的信用评级受到了)flawed computer models, the pressure from financial firms that paid for the ratings, the relentless drive for market share, the lack of resources to do the job despite record profits, and the absence of meaningful public oversight(的影响)”。

一、美国模型风险监管体系介绍

认识到模型风险的重大影响,美国监管部门从2000年开始就发布了一系列有关模型风险管理的文件,逐步形成了一套完整且严谨的模型风险监管体系。这套体系围绕的指导原则是 “有效挑战(effective challenge)”。这个有效挑战由动力、胜任力和影响力三大要素构成。动力是指挑战者必须在组织上相对独立于模型的开发者并且有正向的激励去进行挑战。胜任力是指挑战者本身必须具备相关的专业知识和技能。影响力是指挑战者必须具备有一定的权威和在组织内的地位,以及来自更高管理层的承诺和支持,以保障被挑战方对其意见有足够的重视。

(一)美国模型风险监管体系框架

按照上述的指导原则,美国的模型风险监管体系的框架如下图所示:

概括起来就是一个“3+1”的框架:银行内部必须有三条防线,最后再加上一条外部的防线,那就是政府监管部门本身。

银行内部的三条防线在组织和功能上相互独立,各司其职,但他们所遵循的管理政策都由银行的董事会及高管层亲自审批和检讨的。一般而言,银行内部制定的模型风险管理政策都跟政府监管部门要求一致或者更严一些,不然的话会有很大的麻烦。

银行内部的第一条防线由模型的开发者、管理维护者、以及使用者构成。他们依照政策进行模型的开发、上线、使用、监控和维护,并且要配合模型验证部门的独立验证工作,每项工作的每一步都有详细的准则。

第二防线里有两个部门,一个是模型验证部门,负责对银行所有模型进行独立验证;另一个是模型风险监管部门(银行内部),负责草拟和执行本行的模型风险管理政策。分开成两个部门的一个重要原因是不让模型验证部门拥有自行修改模型验证准则的权利。

假如第一和第二防线对模型风险管理执行不当怎么办?还有第三条防线,那就是内部的审计。他们会定期不定期地审查和评估模型风险管理是否完整、严谨、有效。

最后一关就是政府的监管了,美联储和美国货币监理署等政府监管机构会依照政府监管政策的标准(而不是银行自己制定的标准),对某些银行某些业务线某些具体产品的模型风险管理进行审查。一旦发现不合规的地方就会勒令限期做出整改,如不能在规定限期里按要求完成整改,则银行会面临巨额罚款、高管减薪、不得分红、不得从事某些重要业务比如并购等等,后果非常严重。笔者在美国的十七年时间里,就“有幸” 三次以模型负责人的身份接受了美国监管部门的抽查,并且都让监管部门满意通过了。

(二)美国监管部门对模型风险管理的具体要求

介绍完了美国的模型风险监管的体系框架之后,接下来展开介绍以下六个环节中模型风险监管的具体要求。这六个环节分别是模型清单、模型开发、模型实施与使用、模型验证、模型监控、以及文档要求。以下的每一句话,不管是反复强调还是一笔带过,其内容都毫无例外地被美国的监管机构认真执行着。

1.   模型清单(Model Inventory)

管理模型风险就像管理其他事物一样,首先要从清单开始。如果一家银行连自己具体有哪些模型正在使用,正在开发,或已经停用都没有掌握清楚的话,那就根本谈不上任何有效的管理。因此,美国监管部门规定,银行的各条业务线都必须有自己的模型清单,并且全行范围必须有一份总清单。不管是银行自己开发的模型/评分还是外部提供的模型/评分都必须包含在模型清单里。模型清单里必须包含以下内容:

  • 模型的状态(使用、开发、还是停用?)

  • 模型的目的以及模型设计的目标产品、预期和实际的使用场景、以及任何对使用的限制。

  • 输入数据或组件的类型及其来源

  • 模型输出及其预期用途

  • 模型是否运行正常?最后一次更新是什么时候?任何政策例外?

  • 模型开发和模型验证的责任人

  • 已完成的和计划当中的验证日期

  • 模型的有效期

模型的清单必须保证真实性(如实反映情况)、时效性(及时更新)、及一致性(业务线与全行、三条防线手里的模型清单里的信息都必须保持一致)。

2.   模型开发(Model Development)。

有效的开发过程始于对模型目的的明确表述,以确保模型开发不会与预期用途偏离。模型的设计、相应的理论和逻辑也应该有研究文献和行业实践的普遍支持,并在文档中进行阐述。模型开发者还要进一步详细说明具体的模型方法和处理组件,包括算法,并关注其优点和局限性,做到概念上合理,数学和统计上正确。另外,与其它理论和方法进行比较也是有效建模过程的基本组成部分。

用于开发模型的数据和其他信息至关重要,模型开发者应严格评估数据质量和相关性,能够证明这些数据和信息适合模型,并且与采用的理论和方法一致。如果使用替代数据,必须进行仔细识别、证明并记录。如果数据和信息不代表银行的资产或其它特征,或者出于某种假设调整了数据和信息,则应进行跟踪分析,让使用者时刻注意到潜在的风险。这点对于外部(来自供应商或外部方的)数据和信息尤其重要,特别是与新产品、新客群或新活动相关的数据和信息。

模型开发的另一个重要组成部分是测试,即评估模型总体和各组件功能,确保模型表现符合预期。具体要求包括:对模型准确性、鲁棒性、稳定性的测试;评估潜在的局限性,在一定的输入值区间里的模型表现;评估模型假设对模型的影响、找出模型表现欠佳或不可靠的情形;测试各种市场条件下的实际情况(包括超出正常预期范围的情况),测试模型的有效性边界(极值测试);评估该模型对其它模型的影响。上述的测试(包括目的、设计、执行、结果)都必须被记录。具体的测试方法和标准可因具体模型类型而异,但是要避免孤立地依赖一个方法和标准做出结论。

3.   模型实施与使用(Model Implementation and Model Use)

模型通常要嵌入到庞大的信息系统中,这些信息系统管理从不同来源进入到模型中的数据流,并对模型结果进行聚合和输出。模型计算必须与信息系统的能力和要求相协调。健全的模型风险管理依赖于对支持系统的大量投资,以确保数据和报告的完整性。

模型的实施必须有一套严谨的校验规范,以保证上线的模型与开发的模型完全一致:结果(包括中间结果)一致、底层数据一致、计算逻辑一致。

模型的使用为测试模型是否有效运行,并随着时间推移(如条件和模型应用的变化)评估其性能提供了进一步的机会。那些对拥有性能良好、反映经济和商业现实的模型有着浓厚的兴趣的内部利益群体(比如模型的使用者)可以通过了解模型的使用情况来提出有效的反馈。受模型结果影响的业务经理可以质疑模型背后的方法或假设,特别是当他们受到模型结果的重大影响且不同意模型结果时。如果这些的问题是有建设性的,可以促使模型开发人员解释并证明模型的假设和设计是合理的。不仅如此,模型使用者还可以在开发过程中向模型开发者提供有价值的业务洞察力。

当然,模型使用者提出的挑战往往不全面,因为他们侧重于对衡量自己业务绩效或薪酬有最直接影响的模型问题,而忽略模型的其它问题,并且不太可能挑战给他们带来好处的结果。因此,模型使用者具体意见背后的性质和动机应该被仔细评估。另外,银行还应征求独立于使用模型的业务部门的其它部门的建设性建议和批评。

用于业务决策的报表在模型风险管理中起着至关重要的作用。这些报告应清楚易懂,并考虑到决策者和建模者往往来自不同的背景,可能以不同的方式解释内容。用不同的输入值和假设值所产生的报告可以为决策者提供模型准确性、鲁棒性和稳定性的重要启示,以及关于模型局限性的信息。

4.   模型验证(Model Validation)

模型的验证必须由专业且独立的模型验证团队来执行。验证者必须有动力、有胜任力和影响力。

模型验证的范围必须包括模型的所有组件,即输入、处理、报告组件。

模型验证的对象包括内部开发的模型和供应商/顾问开发的模型。

模型验证的严格性和复杂性应与下述情况相配称:模型的使用量、模型的复杂性和重要性、银行业务的规模和复杂性。

模型的验证有三类:初始验证(initial validation)、持续验证(on-going validation)、和定期复查(model review)。

初始验证是在首次使用模型之前进行的验证。如果验证发现模型有重大缺陷,则在解决问题之前,不应允许或仅应在非常严格的限制条件下才允许使用模型。如果缺陷太严重,无法在模型的框架内解决,则应拒绝该模型。如果由于缺乏数据或其他限制而无法在模型使用前进行必要的验证活动,则应将该事实记录在案,并将报告传达给使用者、高级管理层和其他相关方。在这种情况下,模型结果的不确定性应该通过其他补偿性的控制来减轻(典型的例子如冷启动模型)。

持续验证是在模型投入使用后持续进行的验证,以跟踪已知的模型问题并识别任何新的问题。持续验证是对模型使用的重要检查,有助于确保市场、产品、风险敞口、活动、客户或业务实践的变化不会造成新的模型问题。比如说,如果信用风险模型没有及时纳入审批政策的变更,那么在模型性能恶化变得明显之前,模型的使用者和业务部门可能就已经做出了成本高昂的、有缺陷的业务决策。

银行应至少每年进行一次定期复查(必要的时候可以更加频繁),以确定模型是否正常工作且现有的验证活动是否足够。这项工作可以是简单地确认以前的验证工作、建议对以前的验证活动进行更新、或者要求额外的验证活动。

有效的验证框架应包括三个核心要素:概念健全性评估、持续监控(将在后面用独立章节描述)、结果分析。

 概念健全性评估包括评估模型设计和构造的质量。它要审查相关文件与实践证据,确保在模型设计和建造中使用的方法、判断、及变量的选择是有充分信息的、经过仔细考虑的、并且与已发表的研究和成功的行业实践相一致。验证者对总体理论结构、关键假设、数据和具体的数学计算等等方面应进行批判性分析,具体包括:1)评估开发文档的质量和覆盖面,2)必要时进行额外的分析和测试,3)与其他理论和方法的比较,4)评估关键假设和变量选择并分析其对模型输出的影响,特别关注任何潜在的局限性,5)依据模型的类型评估用于建立模型的数据的相关性,以确保其合理地代表银行的资产或市场状况(尤其是当银行使用外部数据或将原有模型用于新产品或活动)。

在适用的情况下,银行应在模型开发和验证中采用敏感性分析,以检查输入和参数值的微小变化对模型输出的影响,确保它们在预期范围内。由输入的微小变化带来输出的意外大变化可能表明模型不稳定。同时改变多个输入可以帮助发现意外的交互作用,特别是在交互作用复杂且不直观的情况下。

银行可以通过模型压力测试检查在各种输入和参数值(包括极值)下的模型的性能,以验证模型的鲁棒性。这种测试通过识别可接受的输入范围以及可能使模型变得不稳定或不准确的情况,帮助确定模型性能的边界。

管理层应该有一个清晰的计划来使用敏感性分析和其他量化测试的结果。如果测试表明模型在某些情况下可能不准确或不稳定,管理层应考虑修改某些模型属性,减少对模型输出的依赖,限制模型的使用,或开发新的方法。

模型验证的第三个核心要素是结果分析,即模型输出与相应的实际结果的比较。比较的精确性取决于模型的目标,可以包括评价估算或预测的准确性、评价排序能力、或其它适当的测试。如果结果分析发现了模型表现不佳的证据,银行应采取行动解决这些问题。结果分析通常依赖于统计测试或其他量化指标,但还可以包括专家判断,以检查结果背后的直觉是否有道理。当模型本身依赖于专家判断时,量化的结果分析有助于评估判断的质量。结果分析应持续进行,以测试模型是否继续按照设计目标和业务用途运行。

在结果分析中可以使用各种量化和非量化的测试分析技术。技术的选择应该基于模型的方法、复杂性、数据可用性、以及潜在的对银行风险的大小。结果分析应该包括一系列的测试,因为任何单独的测试都会有弱点。例如,一些测试适合在相对基础上检查模型对观测值进行排序或分段的能力,而另一些测试在检查绝对预测精度方面更好。测试者应针对每种情况设计测试,因为并非所有测试在每种情况下都有效或可行,应注意为特定模型选择适当类型的结果分析。

模型会因为考虑新的数据或技术,或由于性能下降进行定期调整。平行结果分析是对这种模型调整的一个重要测试。在这种分析下,原始模型和调整后模型的预测都要与实际的结果相比较。如果调整后的模型没有优于原始模型,那么开发人员、用户和评审人员应该意识到,在用调整后的模型替换原始模型之前,可能需要进行额外的更改,甚至是大规模的重新设计。

回测(back-testing)是结果分析的一种形式;具体来说,它涉及在模型开发中未使用的样本时间段内,在与模型的预测范围或表现窗口相匹配的观察频率下,将实际结果与模型预测进行比较。比较通常使用模型预测的预期范围或统计置信区间进行。当结果超出这些区间时,银行应分析差异,并调查有显著意义的原因。分析的目的是确定差异是否源于模型中重要因素的遗漏,是否源于模型其他方面的错误(如相互作用项、线性假设等),是否纯粹是随机的(因此是可接受的模型表现)。用保留样本(时间内样本但不用于训练模型)对模型的样本内拟合和模型性能的分析不能用来替代回测。

即使是高质量的精心设计的回测也会带来问题,因为它不是一个总是能产生明确结果的简单机械过程。回测的目的是测试模型,而不是单个预测值。回溯测试可能需要在一个时间点不同条件下或多个时间段对大量的预测进行分析。统计测试是必不可少的,但是在选择适当的测试和解释结果方面都可能带来挑战。银行应支持并记录测试的选择和结果的解释。

具有长期预测范围的模型应进行回测,但考虑到积累必要数据所需的时间,应通过较短时间内的评估补充该测试,比如由“早期预警”指标组成的结果分析。这些指标旨在衡量模型引入后早期的表现及随着时间推移的表现趋势。这些结果分析工具并不能替代回溯测试,而是非常重要的补充。在足够的时间轴里,回测仍应进行,。

模型结构或技术的重大变化,以及模型的重新开发,在实施之前,都应接受恰当范围和严格程度的验证。有时由于各种原因,比如缺乏数据或价格可见性,银行使用关键模型验证工具(如回测或敏感性分析)的能力可能有限。在这些情况下,在考虑模型使用的适当性时,应更加注意模型的局限性,在使用模型进行决策时,应将这些局限性充分告知高级管理层。

供应商和其他第三方产品(包括数据、参数值和完整模型)的广泛使用给模型验证和其他模型风险管理活动带来了独特的挑战,因为建模专家是外部的,而且某些组件被认为是专有的知识产权。尽管如此,供应商产品应按照适用于内部模型的相同原则纳入到银行更广泛的模型风险管理框架中,虽然流程可能会有所修改。

作为第一步,银行应确保有适当的流程来选择供应商模型。银行应要求供应商:1)提供开发文档,说明其构成、设计和预期用途,以确定模型是否适合银行的产品、敞口和风险;2)提供适当的测试结果,显示其产品按预期工作;3)应明确指出模型的局限性和假设,以及产品的使用可能存在问题的地方;4)进行持续的绩效监控和结果分析,向客户披露;5)随着时间的推移做出适当的修改和更新。

银行必须对供应商产品在本行的使用进行验证。外部模型可能不会向银行披露全部的计算机代码和实施细节,因此银行可能不得不更多地依赖敏感性分析和基准比较。供应商模型通常设计为提供一定范围的功能,因此可能需要由银行根据其特定情况进行定制。作为验证的一部分,银行的定制选择应记录在案并证明合理。如果供应商提供输入数据或假设,或使用它们来构建模型,则应调查它们与银行情况的相关性。银行应获取模型开发数据的有关信息,并评估该数据在多大程度上代表了银行的情况。银行还应利用自身的结果,对供应商模型绩效进行持续监测和结果分析。

系统的验证程序有助于银行了解供应商产品及其能力、适用性和局限性。这些详细的知识对于银行运营的基本控制是必要的。如果卖方或银行因任何原因终止合同,或卖方不再营业,使得供应商模型不再可用或不再被支持时,银行必须有应急计划。

5.   模型监控(model monitoring)

当模型首次在生产系统中实施以供实际业务使用时,模型监控工作就必须开始。监控必须随着时间的推移定期进行,其频率应与模型的性质、新数据或建模方法的可用性,以及所涉及风险的程度相匹配。通过持续监测确认该模型得到了正确的实施,且表现符合预期。持续监控对于评估是否需要根据产品、风险敞口、活动、客户或市场状况的变化对模型进行调整、重新开发或更换,以及验证超出模型原始范围的任何扩展是否有效至关重要。在开发阶段发现的模型的任何局限都应在持续监控中被定期评估。

银行必须设计一个持续测试和评估模型性能的程序以及对发现的任何问题的应对流程。该程序应包括过程检验(process verification)和基准比较(benchmarking)。

过程检验检查所有模型组件是否按设计运行,包括内部和外部数据输入是否继续准确、完整、符合模型目的和设计以及达到可用的最高质量。实施模型的计算机代码应遵守严格的质量和变更控制程序,以确保代码正确无误,而且只有经批准才可对其进行更改。所有更改必须被记录以供审核。系统集成是一个挑战,值得特别注意,因为模型处理组件经常从各种数据源中提取数据,处理大量数据,然后输入多个数据存储库和报告系统。用户开发的应用程序(如用于生成量化估计的电子表格或临时的数据库应用程序)特别容易产生模型风险。随着时间的推移,信息的内容或组成发生变化,系统可能需要更新以反映数据或其使用的任何变化。模型输出报告应作为验证的一部分进行审查,以验证它们是准确、完整和信息性的,并且包含模型性能和局限性的适当指标。

在模型开发中采用的许多测试都应包括在持续监控中定期进行,以便在可获得时纳入更多信息。新的实践证据或理论研究可能表明需要修改甚至取代原有的方法。应定期分析内部和外部信息源的完整性和适用性,包括第三方供应商提供的信息。

敏感度分析和其他鲁棒性和稳定性检查也应定期重复。它们在持续的监视过程中和在模型开发过程中一样有用。如果模型只适用于特定范围的输入值、市场条件或其他因素,则应对模型进行监控,以发现接近或超过这些约束的情况。

持续监控应包括对越控(overrides)进行分析并记录。在使用任何模型时,都会出现模型输出结果基于模型使用者的专家判断被忽略、更改或被反转的情况,这就叫越控。越控一定程度表明了模型在某些方面没有按预期表现或存在局限。银行应评估越控原因,并跟踪和分析越控效果。如果越控率很高,或者越控过程持续改进了模型性能,则通常表明被越控的模型需要被修改或重新开发。

基准比较是将给定模型的输入和输出与来自其他内部或外部数据或模型进行比较。它可以被纳入模型开发和持续监控中。对于信用风险模型,基准的例子包括来自供应商或行业联盟的模型和来自征信局的数据。证券和衍生品的定价模型通常可以与那些更准确或更全面,但太耗时,无法每天运行的模型进行比较。无论来自哪里,基准模型都应该是严谨的,基准数据应该是准确和完整的,以确保合理的比较。

模型输出和基准之间的差异应引起对其来源和程度的调查,并依据比较的方式,检查这些差异是否在预期或适当的范围内。分析结果可能提示对模型进行修改。然而,有差异并不一定表明模型是错误的。基准本身是一种替代性预测,差异可能是由于使用的数据或方法不同所致。如果模型与基准匹配良好,固然是对模型有利的证据,但也应谨慎解读,以免银行盲目乐观。

6.   文档要求

如果没有足够的文档记录,模型风险评估和管理将是无效的。文档的要求在上文多处被提到,在这个章节里做进一步的归纳补充。

模型开发和验证的文档应该足够详细,以便不熟悉模型的各方能够理解模型的操作方式、局限性和关键假设。文档提供了操作的连续性,使合规透明,并有助于跟踪建议、回应和例外情况。模型开发人员、模型使用者、银行的控制和合规部门以及主管们都必须得到有效的文档。银行可以受益于信息和知识管理系统以及电子文档的进步,以改进在模型风险管理过程中产生的各种记录和报告的条理性、及时性和可访问性。

文档化需要花时间和精力,熟悉该模型的模型开发人员和使用者可能并不重视它的价值。因此,银行应提供措施以激励制作有效和完整的模型文档。模型开发人员应该在模型开发期间负责详细的文档记录,并随着模型和应用程序环境的变化,对文档记录进行补充最新。此外,银行应确保模型风险管理的其他参与者也记录其工作,包括持续监控、过程检验、基准比较和结果分析。此外,业务线或其他决策者要对选择模型及其后续验证的依据进行记录。如果银行使用来自供应商或其他第三方的模型,银行应确保获得描述模型方法的适当文档,以便对模型进行恰当的验证。

验证报告应阐明所审查的模型的各方面情况,突出一系列财务和经济条件下的潜在缺陷,并确定是否有必要进行调整或采取其他补偿性的控制措施。有效的验证报告包括清晰的执行摘要、模型目的声明以及模型和验证结果的概要,包括主要局限和关键假设。

7.  模型与策略的分界

       模型与策略在输入与输出、方法与途径等等方面有着难以区分的相似性。美联储对模型的定义,引发了各金融机构与监管部门关于如何区分模型和策略的激烈争论。如果严格按照字面上的定义,很多通常被银行认为是策略的东西将会被界定为模型,从而纳入到上述严格的模型监管框架内。这无疑对于各家银行是一个沉重的监管负担。因为一家大型银行所有产品线日常所用的模型有数百个,如果算上各种策略的话会有数千个。笔者曾有幸代表以前任职的一家美国银行参与了与监管机构在这个话题上的讨论,并成功达成了一定的共识。在实践当中,欧美的金融机构往往自觉或不自觉从以下方面对模型和策略进行区分

      用另一句话来概括就是:模型是策略的工具;策略往往包含了模型,是模型的延伸。

二、同盾的建议

对比美国,当前中国各金融机构模型风险管理意识薄弱,大部分基础建设几乎为零。虽然有些大型银行和金融机构已经在模型开发、模型验证、或模型监控上建立了一些自己的规范,但是远远没有形成完整和严谨的体系。在没有足够的外部监管压力的情况下,仅仅依靠机构的自觉性是无法建立起整个金融行业完整有效的模型风险管理体系的。这是一个不容忽视的系统性风险。

因此,我们提出以下建议(依步骤):

1、组建中国金融业模型风险监管体系建设顾问团,聘请中外专家协助人民银行、银保监会等监管机构起草相关监管文件。

2、在顾问团的协助下,在人民银行、银保监会等监管机构内部组建相应的监管处室,建立政府监管框架。

3、通过监管文件的发布,对各金融机构提出模型风险管理结构要求(如三条防线)

4、监督各金融机构建立内部的模型风险管理结构。

5、通过监管文件的发布,确立模型清单、开发、实施、使用、验证、监控、文档等方面的基本准则。

6、指定试点金融机构按上述基本准则自行制定且试行机构内部具体的模型风险管理政策。

7、一段时间后,对试点机构的模型风险管理政策进行评估、比较、和汇总提炼。

8、将前面制定的基本准则更加具体化成完整详细的模型风险监管政策并发布。

9、责令各金融机构以及供应商在规定时间内遵行政府的模型风险监管政策并上交执行报告供审查。不同性质和不同规模的金融机构可以有不同的遵行时间表,分批进行。

10、派出检查小组对金融机构和供应商进行全面或抽样,定期或不定期的模型风险管理检查。

各金融机构在响应监管,建立和执行模型风险管理制度时,可能会面临相关的人才、知识和经验不足的困难。监管机构可以准入有资质的咨询公司为各金融机构提供这方面的咨询服务。

 2019年10月30日

参考文献:《SR Letter 11-7:Supervisory Guidance on Model Risk Management》,美联储和美国货币监理署联合发布,2011年4月4日

python风控建模实战lendingClub(博主录制,catboost,lightgbm建模,2K超清分辨率)

https://study.163.com/course/courseMain.htm?courseId=1005988013&share=2&shareId=400000000398149

 微信扫二维码,免费学习更多python资源

猜你喜欢

转载自www.cnblogs.com/webRobot/p/11785533.html