风险控制的背景

在商业交易和复杂管理过程中，风险是无处不在的。我们常说的 风险控制，就是指风险管理者采取各种措施和方法，消灭或减少风险发生可能性和风险所造成损失的过程。这在传统的企业管理、金融借贷、资金审计等领域中尤为重要，并已在实际操作中发展出了一套相对完整的理论和方法。

随着互联网本地在线服务（O2O）的快速发展，越来越多的交易正在从传统的线下传统渠道迁移到在线、实时的平台上，互联网平台为了培育市场，也在运营和推广中投入了大量资金。但事情的另一面，这也给互联网“黑色产业”提供了滋生的土壤。有别于传统风控，互联网在线业务风控面临的风险形式多样、变化快，可以利用的信息冗杂。因此在线业务风险控制成为了风险控制中一个独特的分支，需要一套与之适应的方法论和控制系统。

目前美团拥有数亿存量用户，实体商家超过百万，在国内本地服务领域中处于领先地位，成为了重要的在线交易平台和商家引流渠道，业务运行中面对的风险尤为明显。其中以用户作弊和商家刷单、账号安全、资金安全最为突出，本文所阐述的风控系统也主要针对这些风险而设计。下面将分别阐述这几类风险。

用户作弊和商家刷单

作弊指以欺骗或违反业务规则的手段获得利益。作弊的形式有很多种，其中不变的是必然有利益作为作弊动机。可能的获利方包括用户账户、商家、中间人等，并可能发生这些获利方的串通行为。作弊可以分为：

• 用户作弊：用户发起的以欺骗或违反业务规则的手段获得平台优惠补贴、用户权益等利益。在美团，这种作弊以伪装成新用户尤为明显，例如“黄牛”会利用“刷机”、“众包”等方式得到优惠权益，再通过网络平台或直接在电影院、餐厅、酒店门口现场兜售获得利润。
• 商家刷单：商家或其委托方以获取销量、积分、评价权益、套取优惠补贴、帮助套现等不正当利益为目的，违反商户平台协议发起或参与的非正常交易行为。在利益的驱使下，甚至有虚假的商户专门从事刷单行为。

目前完整且专业的作弊产业链已经形成，这些团伙包含了生产作弊工具、刷单和销赃的完整链条，行动迅速且参与者广泛。

账户安全

大部分用户会使用一样的信息注册多个互联网服务，而这些服务的安全防御参差不齐，使得专业的盗号团伙有越来越多渠道窃取到诸如邮箱、手机号、登录密码、支付密码、住址、身份证号等关键信息。盗号者通过邮箱、手机号等维度把它们关联起来，就可以得到十分详尽的用户资料。美团用户群与其他互联网服务有广泛交集，用户账户中可能包含现金余额、绑定支付方式和已购买的团购券等，盗号者使用窃取的资料用来登录、找回密码、换绑手机、换绑邮箱、支付购买，会带来严重的安全威胁。与帐号安全相关的典型攻击形式有：

• 暴力撞库：对特定帐号使用遍历验证信息的方式试出密码。
• 洗号：第三方网站的用户资料泄露后，在本平台尝试登录以筛选出可用账号。
• 木马：植入木马程序到用户电脑或手机客户端，用来截获用户的短信验证码或密码信息。
• 社会工程学：简称社工，通过伪造和诈骗的方法从用户本人或者第三方获得用户的隐私信息。例如诈骗者谎称是某服务客服人员，联系用户称可以帮助其做服务升级，但需要用户提供短信验证码、身份证号等关键信息，而实际上诈骗者利用这些信息在其他平台完成帐号的手机换绑、重置等操作，进而盗取账户造成用户实际损失。

资金安全

在线支付已经十分普及，但因为用户体验需要，大多数在线支付的验证设置并不严格，譬如最常使用的“验证绑定手机短信验证码”方式并不十分安全，“拥有短信验证码”和“是支付帐号持有者”并不等同，这就给“黑产团伙”带来了可乘之机。与针对“账户”的攻击手段相似，盗用者可以通过各种渠道窃取到支付所需的验证信息，进而在线消费，对用户而言带来的损失更加严重。美团为了保证消费者利益，防范非用户本人的消费就显得尤为重要。与作弊和盗用账号相比，盗用支付所带来的回报更高，作案更便捷，因此盗用者通常具备更高的专业性，并体现出明显的团伙分工作案趋势：

• 信息窃取：针对支付帐号、身份证号、姓名、住址等直接与消费相关，或可用来做“社会工程学”攻击的信息，常见的方法有直接从本人骗取，或从第三方机票代理、在线购买网站泄露获得。
• 木马植入：植入木马程序到用户手机，截取用户短信、电话，为“验证手机验证码”做准备。
• 在线消费：设法绕过平台的防控规则，购买高回报、易销赃的商品或服务，例如高价游乐园门票、手机充值卡、加油卡等。
• 销赃：将非法所得在线上或线下快速兜售。

风控的特点和任务

这里所说的风险控制，特指针对美团在线业务，采用各种措施和手段减少风险事件发生的可能性、降低可能造成的损失的过程。

风控的特点

在开展风控工作前，首先要认识到这项工作的几个特点：

• 服务于业务：业务先于风控建立，风控因业务的存在而存在。因此风控要帮助业务看清问题并提供方案，适应业务的场景需求、发展需求。在系统的建设中，要保证低侵入性，尊重用户体验。
• 对抗和平衡：风控是永恒存在的，因为利益一直存在。风控的好坏不在于某一点的防御质量，而在于防御体系的最薄弱环节。因此，风控的目的不在于消灭风险，而在于敏捷、持续地控制风险，处理成本和收益的动态平衡。
• 数据是核心：风控的一切依赖于数据，要尽可能收集、积累、分析所有与风险相关的数据。数据为一切风控处理、决策提供依据。

风控的任务

具体而言，风险发生在业务动作中，积累在业务结果中。因此风控即要从业务动作和业务结果中，进行 预警、 识别、 分析、 干预。完备的风控体系是立体的，在不同的环节有不同的任务。

事前：提升防御能力，减少短板

• 风险教育：在快速发展的业务中，风险控制的核心在于人，要将风险意识和基本概念传递到业务的各个阶段，明确告知风控可以提供的服务。
• 参与业务：参与到业务的产品流程中，了解高风险业务、活动的规则，预判风险并给予合适力度的干预。
• 数据准备：打通数据收集流程，制定预警规则、模型策略等。
• 主动防护：关注业界风险动态，发生行业安全事件后，或重大活动、产品改动上线前，制定有针对性的规则，甚至采取锁定高危账户、发送预警消息等措施。

事中：提升攻击成本，降低损失

对于在线实时业务而言，风控对线上运行的系统的防御主要体现在不同的实时决策中：

• 疑似风险行为：实时预警，告知风控、业务方负责人。
• 低风险行为：限制操作行为或增加验证步骤，平衡用户体验和可能造成的损失。
• 高风险行为：直接拒绝，或增加额外惩罚，例如冻结帐号。

事后：快速响应，灵活管控

风控所处的环境和对手都在不断变化中，因此风控系统本身也要接受反馈不断进化：

• 处理风控客诉、案件核查、赔付等。
• 对批量数据做聚合监控，捕捉实时处理时无法监控的案件。
• 监控风控效果，优化规则和策略。

风控系统

风险控制的方法论固然丰富，而实施的难点更在于如何将抽象的理论变为实际可用的系统。这个系统要解决的问题有：

• 如何适配和兼容多业务线，把风控的处理决策反馈到业务系统？
• 如何对系统的体系做逻辑拆分，让各模块“各司其职”而又满足各不同场景需求？
• 如何准确监控风险现状，快速配置和调整策略，让风控可运营化？

风控的系统结构如下图，下面即从系统接入、平台组件、数据运营三方面介绍其中的一些设计要点。

风控系统——系统接入

与业务方对接是风控系统要做的第一步， 风控事件服务（代号： Tatooine，《星球大战》中天行者家族的故乡行星）就是风控与外部服务对接的实时服务接口。

风控事件服务

我们将用户通过业务系统发出的动作，称之为“ 事件”，例如登录、注册、下单、支付等。对接就是为了收集这些“事件”的信息，并把决策反馈到业务系统。可以进一步把事件抽象如下：

美团有多条业务线，各业务都可能有独特的Web前端、Android客户端、iOS客户端、业务后台、促销配置后台等，并且可能使用一些内部统一服务，如支付平台、用户中心、短信平台等。因此Tatooine不可避免与多个系统对接，所带来的沟通成本很高。因此Tatooine需要：

• 重点关注与风险行为有关的事件，例如注册、登录、下单、支付、验券等，而非全盘接收用户发出的所有动作。
• 信息传递抽象化，减少对业务系统侵入
  • 不论是哪种事件，都用上述抽象的形式传递、理解和存储。
  • 风控接口被设计成同步事件（即需要获得风险决策）、异步事件（不需要决策，仅告知事件）两种类型。其中同步事件的返回，是一系列相互独立、而又有强弱之分的“决策”，可以被业务系统理解执行。
  • 以“事件”形式对接业务系统后，业务系统仅需要关注发送“事件”和获得风控决策，无需再关注这次调用中所使用的具体风控服务内容——这些对应关系聚合在Tatooine内部，可以灵活调整。从风控角度看，一次事件调用中有可能包含一种或多种风控处理，例如在用户支付时，Tatooine会同时判断用户是否在“作弊”或者“盗用消费”。
• 优先与统一服务平台（如用户中心、短信平台）而不是与各个业务系统分别对接。这样做的好处有：
  • 减少风控对接的系统数量，当新业务对接了统一服务平台后，风控无需再对接这些新业务的相应事件。
  • 归一化输入和输出，风控所需的输入由统一服务平台透传给风控，风控的输出决策融合到统一服务平台的响应报文中。因此对业务方而言，仅感知到对接了统一服务平台，不需要针对风控结果做特殊处理。

风控事件服务在系统中的位置如下：

在设计和实现Tatooine时，有如下一些注意点。

• 风控服务路由：通过识别当前事件和传入参数，映射到按需定制的若干个风控服务“场景”——每一个场景对应着特定的一组规则集合。值得注意的是，不同风控服务映射到“场景”的方法各不一样，例如反作弊主要取决于促销活动（新客、老客活动使用不同的规则集），资金帐户安全主要取决于事件（换绑手机、更改密码对应不同的规则集），而反刷单主要取决于业务和品类（不同品类规则集不同）。
• 规则决策：在得到若干个场景ID后，Tatooine会连同上下文参数一起交由规则平台并行处理。规则决策间相互独立而又有强弱之分，可分为允许操作、验证信息、限制操作、禁止几类。

风控事件和活动对接平台

随着业务快速发展，对接新事件和维护已对接的事件活动对风控团队已经成了不小的负担，需要用系统平台来提高工作效率。之前对接和维护流程是这样的：

• 新业务、事件对接
  • 业务方与风控沟通产品形态，确定策略、交互方式和传递参数
  • 双方系统基于所约定的交互和参数开发联调
  • 观察并调整策略、交互、参数
• 业务活动生命周期
  • 业务方通过邮件发送新活动相关信息
  • 风控PM审核，与业务方沟通制定策略
  • 风控配置活动规则，分配活动场景ID给业务方使用
  • 业务方使用场景ID调用风控
  • 观察并调整策略、交互、参数
  • 活动调整或下线前通知风控，风控对策略、监控做调整

可以看到风控团队要理解所有的业务及其活动场景，参与制定策略、确认交互和参数，这样的过程会因为达到团队人力瓶颈而变得低效。而且业务形态快速更迭，缺少业务方的参与，难以保证应用了最合适的风控策略。

风控事件和活动对接平台从两个方向来解决这个问题：

• 降低使用门槛，转交部分决策权给业务方：将风控策略打包成可以被业务方理解的通用规则集合，例如：识别自然人规则集、新客活动规则集、老客活动规则集。让业务方参与到风控过程中，负责把合适的风控策略应用到自身场景，风控团队则可以专注于策略集的设定和优化。
• 自助化平台：把旧流程中需要人工参与的部分尽可能用自助平台完成。
  • 事件和参数管理：把事件和参数信息配置在数据库中，在对接新业务时无需新上线代码，这样可以灵活修改参数、配置检查规则、自动生成接口文档等。
  • 活动生命周期管理：活动申请、活动审核、场景ID分配、活动策略配置、信息更新、下线等环节都在平台上操作，或者由程序自动完成，让风控与业务系统联动。过程如下图所示。

风控建立对接平台的目的，是希望让业务方可以自助操作，同时风控也能在关键环节给予足够的关注并施加影响，最终合力降低风险。

风控系统——平台组件

接入风控系统后，风控内部如何识别风险呢？以下即介绍风控系统内部所使用的 规则平台和 累计服务（验证中心将在另篇介绍）。

规则平台

风控系统的关键在于迅速、灵活地应对形式在随时变化的攻击，因此需要一套高效好用的规则平台，对风控规则做精细化的运营和监控。 规则平台（代号： Zeus，古希腊神话中统领宇宙的至高无上的天神）完成规则执行引擎、规则配置和管理、规则监控三个任务。

• 规则执行引擎
  • 分为两个层次：1）不包含任何具体业务逻辑的规则执行引擎，仅做表达式解析和执行。2）包含业务逻辑的支持组件和扩展支持，例如封装对基础服务、黑名单、累计服务的访问逻辑，以“扩展因子”的形式提供。
• 配置和管理
  • 规则支持“标记”、“在线”、“离线”状态，方便测试和调整。
  • “标签系统”应用到规则及其相关“场景”、“因子”、“参数”上，可以做高效的分类和配置操作。
• 运行监控
  • 场景决策和规则命中效果监控。
  • 因子利用率、有效性监控等。

具体而言，一次规则平台的调用执行过程如下图所示。

这里的一些概念需要解释一下。

• 场景：对外部调用者而言，通过“场景”来关联到所配置的规则集，例如“下单场景”对应着模拟器识别规则集合。
• 规则：提供有意义决策的最小单元。
  • 执行结果是命中或者不命中——命中后采用什么决策与规则本身无关。
  • 规则的逻辑由逻辑表达式构成，表达式由且仅由规则因子组装而成。
• 规则因子：组成规则的可复用的逻辑单元，一个因子可以被不同的规则使用。因子的类型有表达式型、累计型、扩展型等。
• 依赖参数：因子中所需的用于计算的“参数”，这些参数是预先定义的，可能来自于调用者传入的某个参数，也可能是特定的获取参数的逻辑。
• 决策：命中规则后返回的动作。

这里场景与规则、规则与决策、规则与因子、因子与参数都通过配置或者表达式关联起来，就做到了松耦合。风控是一项多种角色配合的精细工作，这样松耦合的好处十分明显，可以让不同的角色各司其职，关注不同的部分。

累计服务

风控过程中常常需要针对特定的时间区间识别异常行为， 累计服务（代号： Scorpio，天蝎星座）就是为了识别这些风险因素而建立，其目的是提供简单、稳定且高效的接口，用来 获取特定时间范围内事件的次数、总和和种类数量。Scorpio存储的信息有 累计的主体、 累计的数量总数和种类、 发生时间点。这些存储信息并不复杂，Scorpio在拥有这些信息后，还需要包装成贴近使用场景和需求的“功能”，这里列举一部分：

• 事后发送累计：配置新的累计跨度为x天的累计项时，往往希望可回溯累计前x-1天的信息，这样这个累计可以快速生效被使用。所以累计服务除了提供累计到当前时间，还需要提供回溯添加历史累计的接口。
• 返回历史累计项：当累计计数达到特定数值，命中业务规则后，业务规则可能要求回溯处理最初的累计消息，做“冻结账户”、“加入黑名单”等处理。这就要求累计服务存储必要的原始累计信息，可供查询。
• 查询精度：查询的精度要求会根据所选取时间范围不同而不同，例如最近发生的事件，累计查询时间精度要求较高，相反较为久远的事件查询精度要求不高。因此可以根据距当前时间的距离做不同粒度的存储压缩，达到存储空间和需求的平衡。
• 业务隔离：累计服务不仅支持多个累计项，还需要支持不同的业务组。不同的业务组对于存储的空间、可靠性甚至访问速度需求都可能有所不同，例如基于账户操作的累计可靠性要求严格，而数量不大，而针对优惠促销的累计要求不高，但数量巨大。因此Scorpio对不同业务组分配独立的存储空间以适配需求。

Scorpio因风控需求而产生，不难看出这些需求有很强的普适性。Scorpio作为独立服务，同样可以被使用在广告、搜索、推荐等其他系统中。

风控系统——数据和运营

我们的服务在快速变化，很自然所面对的风险也在快速变化。风控系统需要成为立体的、可运维、可进化的体系，因此一套完整的数据、运营系统不可或缺。

风控运营平台

运营系统分为 运营工作流和对应的 支持系统两个部分。

客户投诉是风控了解策略效果的最重要指标之一。不仅于此，针对风险场景，风控还要主动关注异常数据，实现“预警”监控。这些反馈都会进入运营工作流做处理。

在运营工作流中，尽管各风控产品具体流程不同，但都可以划分为初步排查、核查审理、赔付三个步骤，对应着以下三个系统。

除了处理案件本身，运营平台的意义更在于处理后将结果反馈到线上系统中，实现风控线上和线下的运行闭环。

风控数据

在线风控服务和离线运营过程都离不开数据。因风控业务的需要，风控服务对接了公司所有业务的几乎所有关键场景，在这个过程中收集和积累了大量高价值的数据。这些数据初期用来满足风控的实时规则、监控、事后挖掘运营等需求，经过风控“规整”后，其价值就不仅限于满足风控使用，还可以从中挖掘出更细致的用户、商户、项目画像，更宏观的业务、行业发展趋势等重要信息。 风控数据平台（代号： Prophet，预言家、先知）即负责这些数据的采集、存储、访问、运算等过程，将它们用于风控内部和外部的在线使用、运营、分析等环节。

这里所说的“数据”，可以划分为几类：

• 事件快照：包括事件和调用时风控的决策信息，收集的来源主要是Tatooine。这是原始而完整的信息，用于生成聚合数据，也是支持运营查询的主要数据源。
• 聚合事实：相比于原始的事件记录，更多使用场景更关心聚合的结果，例如某用户、某商家的历史购买次数。经过聚合整理后的数据，是进一步数据挖掘的基础。
• 衍生信息：指基于事件快照和聚合事实衍生出的理解信息，例如用户的作弊风险、黑白灰名单等。这些衍生信息可以适配到各个特定场景中使用。
• 基础数据：除了直接传递到风控的数据外，风控处理过程少不了需要业务甚至是外部的辅助信息，例如：
  • 业务相关：用户、订单、活动信息等。
  • 公认的事实数据：行政区域划分、运营商信息、手机型号信息等。
  • 外部辅助信息：外部提供的手机黑名单，甚至有外部风控服务提供辅助的风控决策。

以上数据优先使用关系型数据库存储，事件快照和聚合事实因为数据量较大，考虑到存储容量、查询灵活性的平衡，采用混合存储的方案：

• 针对全量数据的查询，使用Hive。
• 对常规的实时数据查询，使用HBase对常用查询字段做二级索引，可以应对大部分查询需求。
• 针对近短期数据的统计或特殊查询，利用MySQL的灵活性做group by或其他SQL查询。

除了数据的分类存储外，如何访问以上风控内部、外部数据也是风控各个项目反复遇到的问题。为了提高访问的便捷性和质量，Prophet还充当各个项目的对以上数据的访问中间件，提供在线访问接口和SDK集成两种方式。正因为集中管理数据读写，Prophet提供了缓存、性能和访问量监控、对异常接口收缩降级等实用的功能。

目前Prophet已经应用到了多个风控内外部场景，在衍生信息更完善后，这些数据可以挖掘出更大价值。

结语

在可预见的未来，美团的业务仍然会高速发展，业务场景会更加多样。毫无疑问风险仍会不断变化，风控系统的自适应性、可扩展性显得尤为重要，这也是风控系统的核心设计思路所在。

参考文献

• Samet O. Introduction to Online Payments Risk Management. O'Reilly, 2013.
• 李俊奎. 支付宝：敢付敢赔背后的互联网实时风控技术.
• 朱一立个人博客