风控每日一问:合规管理、内部控制和全面风险管理有什么区别?

合规管理、内部控制和全面风险管理有什么区别?

业内回答:

  • 从风险管控的角度来说,我认为从低到高是合规管理-内部控制-全面风险管理。。

  • 首先,合规管理是最基础的层面。合规管理的本质并不聚焦于风险管理,它只是机械的避免违反内外部法律制度规范,从结果上看能够起到一定程度上控制操作风险的作用,但是这个作用有多大、够不够,并不是合规管理所关注的,自然也不是它能够解决的。

  • 其次,以coso框架为代表的内部控制,是合规管理的终极版,也可以说是操作风险管理的终极版。内部控制不但要求合规,还要考察这个“规”是不是完善,“规”有没有配备相应的执行点,执行“规”的过程是不是有效。如果说合规管理更注重结果、只要结果合规就OK,那么内部控制就更重视过程,并在此基础上发展出整套完善的工具和方法。

  • 最后,全面风险管理是风险管控的最高形式。在全面风险管理中,风险一般被分为市场风险、信用风险、操作风险、声誉风险、战略风险。刚才说了,内部控制是管理操作风险的终极手段,但是它对其他风险并没有效果。内控再严密,也无法衡量资本市场波动会给公司带来多大风险(市场风险),无法衡量交易对手赖账不给钱有多大风险(信用风险),更无法衡量公司战略方向错误、出了事被人骂的风险。当然,全面风险管理的精髓,还不只是考虑了这5类风险——毕竟这些风险都不是新鲜玩意。传统上,市场风险归交易部门管,信用风险归信贷部门管,操作风险归合规部门管,剩下俩风险管理层拍脑袋管。这种方式非常自然:谁干的活谁管风险嘛。但是问题在于,干活的是不会真正关注风险的。交易失败无非没有奖金,交易成功就有大笔分红,谁会跟钱过不去呢?所以,全面风险管理认为,必须把管理风险的职能提升到高级管理层这一级,必须有一个首席风险官和独立于交易部门的风险管理部门,来客观的衡量这些风险。而且从技术上讲,各个风险之间有分散作用,也必须由一个统一的部门来管理,才能真正考虑到这种分散作用。

个人观点

  • 朴素的语言,精确描述了三种的区别
  • 其实全面风险管理ERM不是应该去和内部控制做比较,而是应该和以往独立的风险管理相比较
  • 内控更注重过程,没有错,内控是以合规作为导向的,内控是一系列的工具方法流程来保证合规的结果。
  • 合规管理一般涉及到文件审核,业务许可等方面,是与现行法规的机械比较
  • 3
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
背景 当前互联网企业存在很多业务风险,有些风险(比如薅羊毛)虽然没有sql注入漏洞利用来的直接,但是一直被羊毛党、刷单党光顾的企业长期生存下来的几率会很低! 账号:垃圾注册、撞库、盗号等 交易:盗刷、恶意占用资源、篡改交易金额等 活动:薅羊毛 短信:短信轰炸 项目介绍 实时业务风控系统是分析风险事件,根据场景动态调整规则,实现自动精准预警风险的系统。 本项目只提供实时风控系统框架基础和代码模板。 需要解决的问题 哪些是风险事件,注册、登录、交易、活动等事件,需要业务埋点配合提供实时数据接入 什么样的事件是有风险的,风险分析需要用到统计学,对异常用户的历史数据做统计分析,找出异于正常用户的特征 实时性,风险事件的分析必须毫秒级响应,有些场景下需要尽快拦截,能够给用户止损挽回损失 低误报,这需要人工风控经验,对各种场景风险阈值和评分的设置,需要长期不断的调整,所以灵活的规则引擎是很重要的 支持对历史数据的回溯,能够发现以前的风险,或许能够找到一些特征供参考 项目关键字 轻量级,可扩展,实时的Java业务风控系统 基于Spring boot构建,配置文件能少则少 使用drools规则引擎管理风控规则,原则上可以动态配置规则 使用redis、mongodb做风控计算和事件储存,历史事件支持水平扩展 原理 统计学 次数统计,比如1分钟内某账号的登录次数,可以用来分析盗号等 频数统计,比如1小时内某ip上出现的账号,可以用来分析黄牛党等 最大统计,比如用户交易金额比历史交易都大,可能有风险 最近统计,比如最近一次交易才过数秒,可能机器下单 行为习惯,比如用户常用登录地址,用户经常登录时间段,可以用来分析盗号等 抽象:某时间段,在条件维度(可以是多个维度复合)下,利用统计方法统计结果维度的值。充分发挥你的想象吧! 实时计算 要将任意维度的历史数据(可能半年或更久)实时统计出结果,需要将数据提前安装特殊结果准备好(由于事件的维度数量不固定的,选取统计的维度也是随意的,所以不是在关系数据库中建几个索引就能搞定的),需要利用空间换时间,来降低时间复杂度。 redis redis中数据结构sortedset,是个有序的集合,集合中只会出现最新的唯一的值。利用sortedset的天然优势,做频数统计非常有利。 比如1小时内某ip上出现的账号数量统计: 保存维度 ZADD key score member(时间复杂度:O(M*log(N)), N 是有序集的基数, M 为成功添加的新成员的数量),key=ip,score=时间(比如20160807121314),member=账号。存储时略耗性能。 结构如下: 1.1.1.1 |--账号1 20160807121314 |--账号2 20160807121315 |--账号n 20160807121316 2.2.2.2 |--账号3 20160807121314 |--账号4 20160807121315 |--账号m 20160807121316 计算频数 ZCOUNT key min max(时间复杂度:O(1)),key=ip,min=起始时间,max=截止时间。计算的性能消耗极少,优势明显 redis lua 把保存维度,计算频数,过期维度数据等操作,使用lua脚本结合在一起,可以减少网络IO,提高性能 mongodb mongodb本身的聚合函数统计维度,支持很多比如:max,min,sum,avg,first,last,标准差,采样标准差,复杂的统计方法可以在基础聚合函数上建立,比如行为习惯: getDB().getCollection(collectionName).aggregate( Arrays.asList( match(match) --匹配条件维度 , group("$" + field, Accumulators.sum("_count", 1)) --求值维度的次数 , match(new Document("_count", new Document("$gte", minCount))) --过滤,超过minCount才统计 , sort(new Document("_count", -1)) --对次数进行倒叙排列 ) ); 建议在mongodb聚合的维度上建立索引,这样可以使用内存计算,速度较快。 redis性能优于mo

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值