宏观策略与微观规则
在风控体系统里, 我们用宏观策略确定整体目标 , 用微观规则实现其目标, 最终我们是通过决策引擎来完成的部署跟主业务系统交互。
大学期间，我们有两门主修的课程，宏观经济学与微观经济学。
宏观经济学的研究对象则是整个经济，研究整个经济的运行方式与规律，从总量上分析经济问题。它是总量分析，即对能够反映整个经济运行情况的经济变量的决定、变动及其相互关系进行分析。
微观经济学的研究方法是个量分析，即研究经济变量的单项数值如何决定。比如研究单个经济单位，如家庭、厂商等，这种单个单位的最优化行为奠定了微观经济学的基础。
学完这一整套下来，虽然还是未能助我成为经济学大师，也未能帮我在股市上所向披靡，但却让我看待世界万物都有了宏观与微观的看法。以至于我今天要 介绍2个主题，宏观策略与微观规则。对，各位，风控的职业病又犯了。这也秉承着事件万物皆风控的理念
宏观策略
宏观策略，指的是我们以最终需要控制风险的方向为导向，它拟定出来的是一个大的方向，比如我们在制定相关的反欺诈方面，会制定出来的方向是怎么判断客户的欺诈属性，怎么判断客户使用的设备具有欺诈属性，怎么判断跟客户有联系的人具有欺诈属性。于是基于这样的思考，就衍生了一系列相关的宏观策略，比如复杂网络、多头借贷设备风险等。
具体一些，我们便统一以事件型的来表示这样的宏观策略，如：贷款事件、多头事件、流量控制事件等。
举个例子，各位就比较容易理解了。具体贷款风险事件，指的是针对贷款行为所产生的一系列相关事件和风险行为。为了方便理解，这里再继续可以将贷款风险分为多头风险行为、失信风险事件、历史复杂关系网络事件和历史安装应用风险事件等。
多头风险事件，指客户在多个平台借款的，疑似客户有多个借贷的行为，循环套现，以贷养贷，这样的客户一旦资金链断裂，无法再在新的平台借到钱，并会违约，风险极高；
失信风险事件指客户因为历史问题，被法院强制执行的行为或者命中各类消费黑名单等；
历史复杂关系网络，这个是指与客户相关联的手机或者身份证号多于1个，这样的有可能是团伙作案的嫌疑，我们也将其归为重点关注对象里；
历史安装应用风险事件，指客户相关的终端设备里，疑似安装了各类相对贷款敏感类APP，如贷款跟赌博类，这样的客户也必是我们重点关注的风险。历史安装应用风险事件，我们稍后也会重点展开描述。
所以我们在制定宏观策略的时候，需要清楚：
1.关于宏观策略，这里需要能养成的是对整个风险体系、行业和产品熟知程度，需要我们有一定的职业素养。所以好的风险官，在把控全局的风险时，往往看的面很广，也能为今后的各种趋势做出自己的专业判断。
2.在拟定宏观策略时候，需要了解内业内相似的架构和政策性条文。对当前的宏观条文与政策文件的研读也必不可少，同时也需要兼顾了解舆论相关的风险等。
微观规则
关于前面提到的，关于宏观事件的把控需要考验的是全面的风险观。而对于具体的执行面，我们就需要了解整个产品的流程，与客户相关的所有的风险信息等。比如在产品流程上，我们需要了解整个流程中，一共有几个操作页面，每个页面是否能抓起到与之相关的数据等。
下面我们用注册环节说明，以抓起到客户的手机里的历史安装应用数据为例具体说明。
历史安装应用，这一个策略我们在制定规则时，可拟定以下12条规则，具体如下：
用户手机号对应设备历史1个月安装借贷类APP个数过多
用户手机号对应设备历史3个月安装借贷类APP个数过多
用户手机号对应设备历史6个月安装借贷类APP个数过多
用户手机号对应设备历史1个月安装赌博类APP个数过多
用户手机号对应设备历史3个月安装赌博类APP个数过多
用户手机号对应设备历史6个月安装赌博类APP个数过多
用户身份证号对应设备历史1个月安装赌博类APP个数过多
用户身份证号对应设备历史3个月安装赌博类APP个数过多
用户身份证号对应设备历史6个月安装赌博类APP个数过多
用户身份证号对应设备历史1个月安装借贷类APP个数过多
用户身份证号对应设备历史3个月安装借贷类APP个数过多
用户身份证号对应设备历史6个月安装借贷类APP个数过多
以上规则的拟定有两方面的出发点，一个是客户三要素里的手机另一个是身份证，我们基于客户的手机跟身份证，梳理出与之相关的历史安装应用。
在安装应用里，我们梳理了客户手机端里应用的赌博类跟贷款类的APP，因为这两类APP的安装数量关系到客户的多头借款行为跟还款意愿与还款能力。
那在具体设定规则时，我们就可以设定用户手机号对应设备历史1个月安装借贷类APP个数大于10个，则提醒预警。如果客户在注册环节，我们截屏发现客户的手机里安装的app数量借款类APP大于系统设定的阈值了，这个客户不管是与之对应的手机号或者身份证都会统一被提示预警。
当然在设定具体的规则时候，我们需要清楚以下两点：
1.我们需要了解公司产品的特点，和其他产品的不同之处，明确具体的风险点
2.如果这个规则是自家开发的，对标下业内使用相似规则的方法；如果这个规则是第三方开发的，可以根据第三方接口，看下是否有相似的文档，并且要求其提供定制化开发的需求。
最后，为了帮助各位理解，我们梳理了以下架构图:
~end~