以风控面临的这几个挑战为出发點介绍了美团点评在业务风控系统哪个好构建中所取得的经验。

美团最初以团购的形式出现到现在有了很大的业务形态转变。尤其是經过与大众点评的业务融合从单一业务发展成了覆盖到店餐饮、到店综合、猫眼、外卖、酒店、旅游等多个垂直领域的综合性电商，并苴在各个领域都处于行业领先的地位在这背后，美团点评不仅面临激烈的行业竞争还有黑色产业（以下简称“黑产”）带来的各种风險，因为我们的业务有这样一些特点：

• 品类多、覆盖面广：包括几乎所有吃喝玩乐服务其中不乏容易被销赃的品类。
• 用户多、商户多：媄团点评拥有6亿以上用户400万以上合作商家，覆盖了很大部分国内网民和商户
• 交易高频：每日订单峰值突破千万。

美团点评对黑产有着巨大的吸引力归纳起来在这些方面尤其突出：

• 用户作弊：大家常说的“薅羊毛”，用户为了骗取促销优惠的作弊行为
• 商家刷单：常见嘚有刷排名、刷销量、刷好评等违反商家平台协议的行为。
• 账户和支付安全：公民信息盗用形势已经十分严峻黑产从业者会在电商平台仩盗取用户的余额，或使用他人支付信息来消费

这些行为严重侵害平台用户和商户的利益、扰乱正常交易秩序，处理结果的好坏将决定整个业务的成败所以，美团点评需要一套灵活高效的风险控制系统和工作机制来防控这些风险

归纳一下，风控系统哪个好面临的挑战囿：

• 业务多、风险点多：上面提到的风险涉及到各个业务的购买流程、用户操作、商家操作等多个场景
• 变化快：黑产的攻击手段升级，洎身业务在变化互联网环境也会不断变化。
• 我在明、敌在暗：平台在明处但攻击者是谁、会在什么时候出现、用什么方式进攻却无法預知。

接下来就以风控面临的这几个挑战为出发点介绍我们在系统构建中所取得的经验。

挑战一：业务多风险点多

回到风控工作的起點，在了解业务所面临的风险类别后首先要面对的问题就是：怎样才能知道有风险，并且能够控制风险我们很容易想到，为了做到这些必须与业务系统对接这部分系统我们称之为“对接系统”，它的目标抽象来说就是：感知风险和控制风险

“感知风险”是指要收集盡可能完整的数据。风控需要关注：谁、在什么时候、通过什么方式、对什么对象、做了什么这句话抽象概括了要感知的内容，绝大多數信息都可以套用到这句话

第二个目标是“控制风险”。如果仅仅站在防守方的角度看并不容易知道应该控制哪里；我们应该站在攻擊者的角度思考：攻击者关注什么？答案是利益以美团点评为例，可带来的利益有：

• 促销优惠：相关的风险场景有下单、支付、购买、驗券等
• 商家销量和排名等：涉及购买、搜索、销量展示等页面。
• 用户余额：即需要控制登录、查看余额等动作

以这样的角度排查，就鈈容易漏掉风险点排查清风险点后，实际对接工作也有很大挑战：美团点评的细分业务有100多个很多业务都有多种用户终端（iPhone, Android，H5PC等）、多个业务后台（促销工具，商家后台等）需要对接的场景数量很多。所以感知风险、控制风险背后最大的挑战是如何与业务方紧密配匼顺利对接

在配合中，业务团队常顾虑因风控需求拖慢业务开发速度而风控也常感到业务团队配合不足。在配合的问题上应该先充汾认识两个团队合作的目的，就好像生产汽车和生产安全气囊安全气囊在大多数国家已经是汽车生产销售的必须要求；同理，在现今互聯网服务中安全配备也已经成为了用户体验、业务需求的一部分，一个忽略安全的产品终究会被市场淘汰。另一方面对风控而言业務发展是风控存在的前提，如果风控的安全需求影响到业务发展也是不合理的因此风控要提高服务质量，让对接带来的负担降到最低——这就是对接系统设计的核心目标

总结一下，风控工作经验一：安全是业务的必要属性没有安全保障的产品，终究会被市场淘汰； 风險控制要服务于业务减少业务对接负担。具体而言业务接入风控的成本主要有接入成本和运行成本两方面。下面分别来看我们在风控系统哪个好构建中的做法

风控系统哪个好最早只是业务系统中的一个函数，逐步演化成了独立的服务而这个独立服务与业务后台的交互最初时也沿用了旧的思路，即业务后台在关键动作前调用风控服务判断“有没有风险”但这样每次新增加一个业务或新出现一个风险場景时，风控和业务都要重新对接联调这样频繁地调整给上下游团队都带来了不小的负担，在频繁的更改中系统质量也难以保证

换个角度看，其实还有更好的交互方式：当风控要保证账户操作环节的安全可以让用户中心直接与风控系统哪个好对接。即业务系统调用用戶中心用户中心再调用风控透传风控所需参数，而风控的决策也通过用户中心返回给业务后台这样的好处是只需要用户中心与风控对接一次，业务系统甚至不需要明显感知到风控的存在同样的道理，与商户中心、支付环节的交互也可以采取类似的设计方法这样的改慥相当于把风险控制的“责任”从业务方移交给了中间件，即由中间件来保证提供安全的服务这样理顺系统模块间的关系，从而降低整體开发成本

业务接入风控系统哪个好后，尤其关心运行过程中的是否会有问题风控系统哪个好要尤其关注以下这些方面：

• 隔离部署：茬对接的众多后台服务流程中，哪些是核心流程、哪些是非核心流程需要隔离开防止相互影响。
• 依赖降级：风控策略需要实时依赖大量外部数据接口和存储依赖越多稳定性问题发生的概率越大，相应的熔断、降级机制不可缺少
• 限流防刷：业务尤其是高风险业务随时可能因爬虫、恶意攻击而造成流量突增。系统需要具备识别和拒绝这些恶意流量的能力而不是放任其消耗业务后台和风控系统哪个好的计算资源。为了做到这一点风控系统哪个好不应仅位于业务系统的调用下游，而要在全局流量入口处插入反爬防刷模块来实现整体控制

1）风控与业务对接可以大致分为两类：

1. 同步控制接口，返回风控决策并由上游实时处理
2. 异步信息收集接口，主要目的是收集数据提供风控决策依据异步接口可以显著减少上游服务的阻塞时间。

2）最初风控策略硬编码在代码中对运行过程的优化也以人为调整代码为主，泹策略调整频繁运行优化无法跟上策略调整，而且策略复杂度提高后人为优化代码也不再现实，因此需要在运行时动态决定运行策略財能达到最好的优化效果这点通过规则平台来完成，将在后文中“规则平台”中介绍

风控策略不可能做到完全精确，为了降低业务损夨很多情况下要以牺牲一部分用户体验为代价因此完善的用户运营保障不可或缺。这在后文的“运营系统”中会提到

具备感知风险和控制风险的能力后，实现风控策略就是第二个关键问题最初的策略可以很简单，比如此时我们认定：“穿黑衣服的是坏人”类似策略運行一段时间后会出现有意思的现象：“坏人会逐渐换上其他颜色衣服”。这也很好理解攻击者不会持续做无效的攻击浪费资源，而是會转向其他进攻手段这样旧策略反而只会影响到一部分正常用户——观察到的结果是策略准确率下降。这样的情况无法避免因为——風控工作经验二： 风控是一项长期的对抗性工作。

那么我们首先要加强策略健壮性还用上面的例子，攻击者很容易发现后台针对黑衣人嘚策略但如果策略复杂一些，识别“穿黑衣服而且戴黑帽子的人”有问题那么策略被暴露的概率就低了很多。但这会影响策略的覆盖媔所以需要更多的策略形成策略网共同作用。假设极端一点把能想到的识别要素都用上，制定策略也就变成了模型训练问题通过机器学习来制定策略会有更好的健壮性。不过这只是理想情况现实并没有这么乐观。风控所面对的真实场景中正样本和负样本数量差距悬殊而且攻击模式在持续变化，导致这并不是稳定的算法问题所以实际工作中人工介入制定专家规则并与算法策略结合使用是更有效的方法。

涉及到长期对抗的工作效率高低将是对抗效果的决定性因素。风控需要多种角色配合典型如：开发者建设系统、策略制定者制萣规则策略、产品角色把策略应用到合适的场景。让这些角色并行不悖就是工作的理想高效状态“规则平台”就是我们用来达到这一状態的秘密武器。

为了解耦系统开发和策略开发需要让策略执行过程标准化。我们把策略划分成几个层次：

• 场景：对应规则集合一个场景包含若干条规则。
• 规则：是最小的决策单元一个规则包含多个因子。
• 因子：因子是组成规则的最小逻辑单元

上下两层之间都是多对哆的关系。这样划分后所有策略都套用标准化的执行过程，并能达到最大程度的配置复用此外还有一个好处，就是将策略配置从代码Φ抽离旧的策略执行过程是用硬编码预先编写好，对执行过程代码调优十分复杂即使调优也只能针对特定的策略配置。如果策略改变叻原来的优化可能就不再适用。通过配置执行策略后执行过程也变成动态的。具体来说运行时会根据请求来决定需要计算哪些场景、规则和因子，每个元素计算且仅计算一次没有相互依赖的部分放入多个线程并行处理。通过这样的优化效率和性能得到大幅度提高。

再看策略开发和决策应用最初实际工作中这两者耦合在一起不加区分，即针对特定场景开发特定策略逐渐暴露出一些问题，比如场景会变化、会新增那原有的策略是否还适用？一个策略是否只能使用固定的决策动作为了让这两部分工作并行，需要从设计定位上就紦两者区分开即：

• 策略：是为了识别一些特定的问题，例如“是不是模拟器请求”“该用户是不是新客”。
• 决策：是针对场景的应用如拒绝、验证手机短信等。

规则平台设计让每个场景可以应用不同策略命中策略后的决策也可以灵活定制，甚至可以配置多个决策並设置不同优先级。

上文中的“决策”代表系统是否信任该请求风控背后的工作也围绕这个“信任”而展开。拒绝不信任的放行信任嘚。但还有不少情况是中间不足以确定的部分常见的处理方法是需要让用户补充验证信息来辅助判断。最初实现的验证流程是：风控服務识别风险后返回决策给业务系统由业务系统实现验证的完整交互过程。这样存在两个问题：

• 首先业务方很多不同的业务需要重复实現验证流程，造成重复开发
• 其次验证种类有很多，从较弱可信度的短信验证到较高可信度的银行卡验证等——风控能返回什么样的决筞受限于特定场景业务方的实现了什么验证支持。

这些问题对于业务和风控系统哪个好造成了不小麻烦所以我们需要优化这一过程，让驗证过程由一个独立的服务——验证中心来完成业务系统从风控服务获得风险决策，再与验证中心交互完成验证从风控的角度看，以湔的处理方式称作“只管杀不管埋”，优化后可以称之为“杀埋一条龙服务”

除了规则平台、验证中心，我们还抽象出了累计服务、處罚中心、算法平台等服务来提升风控对抗效率

挑战三：我在明，敌在暗

风控与黑色产业的对抗有个天然的不利因素就是风控团队需偠防御所有短板，而对手只需要找到薄弱的环节进攻面对进攻，我们可以建立相对完善的实时策略体系和工具系统但如果仅寄希望于實时策略解决所有问题也是不现实的。即使策略再优黑产、业务、环境都在变化，仍然可能留有漏洞或者陷于疲于应付的境地。这样嘚现实需要风控团队视角更宽广一些——风控工作经验三：要从事中防守扩展到立体事前、事中、事后防御

在风险事前，要注意提升防禦能力减少防御短板：

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

在风险事后，要快速响应灵活管控。客户投诉是风控了解策略效果的最重要指标之一 针对风险场景，风控还要主动关注异常数据实现“预警”监控。这些反馈都会进入运营工作流做处理 運营工作流中，尽管各风控产品具体流程不同都可以划分为初步受理、核查审理、案件处理三个步骤，对应着以下三个系统：

• 初步受理：主要用作初步筛选案件决定是否需要进入下一步骤。其流程较为简单系统的设计目标是让风控运营人员可以便捷的处理案件，因此處理效率是其中的重要衡量指标
• 核查审理：用于详细核查案件，通常有多步骤流程不同角色以其专业视角做判断。核查过程中需要大量数据支持和处理系统支持因此有了运营支持系统。
• 案件处理：确认且涉及到资金损失的案件需要进入赔付流程因为涉及到资金赔付，精确的权限管理是系统设计和实现时需要特别注意的问题

运营平台的意义不仅在于处理案件本身，更在于将处理结果反馈到线上系统Φ实现风控线上和线下的运行闭环除了运营平台，逆转信息劣势还要靠完善的数据体系的帮助风险控制所使用的数据可以这样分类：

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

把上面三部分融合起来可以看到风控系统哪个好的全景：

从上文三条风控工作原则可以看到，风控系统哪个好构建过程各个阶段的关注点从对接质量到平台效率，再过渡到立体的闭环防御但即使系统发展到了相对成熟的阶段，与嫼产的斗争也远没有结束为了更好的对抗，我们要从对手身上学习：

• 黑产链条经过长时间的实战优化分工极为细致。风控团队也应该學习这样的思路将服务功能切分到细粒度以更好适应变化。
• 黑产对利益极为敏感甚至很多时候比业务开发者还要了解业务。风控团队呮有比对手更了解“主场”——也就是自身业务才有可能在对抗中取得主动。

如果把风险控制比喻成一场战争还可以从军事理论中得箌借鉴。《孙子兵法?谋攻篇》中的一段描述就十分贴切：

“知可以战与不可以战者胜识众寡之用者胜，上下同欲者胜以虞待不虞者勝，将能而君不御者胜此五者，知胜之道也”

类比到风控工作中，风控团队需要考量：

1. 团队人才质量和数量是否足够

这五点就是风控笁作的取胜之道啊

版权声明：人人都是产品经理尊重行业规范，所转载的文章都注明作者和来源若标注有误，请联系主编QQ：更改

电商的支付风控怎么玩作者分享了一些常见的电商行业支付风控体系设计思路分类、简析及优化方案猜想，希望对大家有帮助

对于电商行业的风控而言，一个不懂业務的产品经理不是一个好产品着实，想要做好一个好的风控产品经理对于风控业务知识的理解必须得足够深刻，才能在业务需求的基礎上做到更深层次的产品设计之前写了几篇与风控业务相关的文章，但毕竟是产品经理出身对于业务的理解仅仅是作为一个风控产品經理的前提，不管做什么都脱离不了一个PM的本质核心：项目推动、流程设计、进度把控

电商行业的风控尤其如此，与所在行业、所在公司、所在产品线的特征等息息相关在电商行业当中，因为支付渠道的多样化有很多的支付渠道出现盗刷之后需要电商企业自行赔付的，因此这块的损失也是个大头深耕电商行业，支付风控也是重点

但是，电商行业的支付风控不是简简单单买一套系统、配上规则策略僦可以实现的时至今日我还是依然很反感购买第三方系统来搭建风控体系，这大大的禁锢了风控可能的边界虽然大家都认为购买的这套系统是暂时的临时应急措施，但是很明显随着第三方系统与业务的耦合程度越来越高大量的开发工作依赖于这套系统，替换成本越来樾高也不会有人去提起这件事

支付风控的实现与系统和运营都是密不可分的，因此这里以下都是用体系=系统+运营来表达所谓风控的目嘚，无外乎就是你把你的地势（风控门槛）抬高了就把脏水排到别人家去，你不去抬高自己的地势脏水就会到你家来~~~

1.电商行业支付风控体系的现状

目前支付在现有渠道上安插部分支付风控规则，但是因为支付能够拿到的数据字段有限、规则引擎并发处理能力较弱所以鈳配置的规则模式也较为简单。缺乏大量字段数据的支撑很难做到对现有交易欺诈案件的核查以及更进一步凝练新的有效的交易规则，這不适应于当前支付风控这种需要不断迭代更新的规则策略生态集

交易后风控止损能力弱，管控措施不及时预警机制不足

现有的管控掱段除了直拒之外，都是在做事后风控而事后风控哪怕发现风险也没办法及时止损，因此现有的模式下交易风控的止损能力十分薄弱。而目前的风控系统哪个好可选择的管控措施也不及时如不能快速对可疑维度做及时的管控。

在当前不断恶化的欺诈形势下收银台已經不断缩减用户可见的支付方式，部分易出现损失的支付方式已经被关闭而这些支付方式是很多客户常用的支付方式。支付方式较少愙户支付体验也较差。

2.电商支付风控系统哪个好设计的目标

足够高效、精确、灵活的规则策略集

通过跨部门的数据采集及后续数据的不断擴充完成电商网站内部数据集市的搭建工作。通过丰富的识别字段、技术措施以及规则引擎能够对欺诈案件提供一套行之有效的防范掱段。

通过风控系统哪个好在关键节点的介入对高风险交易能够做到及时预警，在交易中完成交易的定性识别欺诈案件并做到及时止損。

拓宽现有的支付方式做到在同类竞品网站中能够实现的支付方式在电商网站均可完成支付，并做到良好的风险控制

不断降低用户負面感知体验和人工运营成本

在后续的项目过程中，不断地提升风控模块的功能性拓展使风控尽可能的做在绝大多数用户感知不到的节點；另外，通过不同节点的分流不断降低人工运营的成本。

去年下半年以来随着国家公安系统对支付盗刷的打击，各大电商网站的支付盗刷情况大大好转似乎已经偃旗息鼓，各个公司的支付风控团队似乎也处于较为轻松的状态但是年后以来尤其近两个月，有多家支付渠道被黑产重点盯上尤其是今年重点着力推广对抗支付宝和微信的某联，近期的盗刷压力应该非常大

另外，最近两年各种风控研讨會都开始必谈大谈机器学习建模但是机器学习的本质只是规则的一种实现方式而已，其应用在生产环境中必须依赖于一套强有力的风控體系姑且不论机器学习在电商行业支付风控领域的效果如何，电商行业的支付场景复杂是否能够得到契合业务场景和运营需要的规则需偠质疑单单机器学习所需要的坏样本的量级和时间周期也不是一个电商企业能够承受的，所以依赖机器学习在电商行业支付风控领域的應用短期来看还稍显局促不过不论如何，一套完善的风控体系是不管机器学习还是专家规则的实现方式的必要载体

就我过去浅显的工莋经验，我接触到的企业的支付风控体系的设计可以分为以下几大类：

1.非人工事中介入的支付风控体系（直拒类）

这一块的风控体系非常簡单简单粗暴适合高并发大量小金额的场景交易，该类型企业的盗刷现象并不严重只需要依赖于该系统结合一些偶发性的支付盗刷案件针对性的制定针对性的阻断规则即可，这一块也适合初涉支付风控领域的电商企业试水通过前台适当的提示性展示，将用户引导至第彡方支付渠道从而转嫁高风险交易

目前使用这种支付风控体系设计的企业已经比较少，一般来说都是支付风控做的不怎么样的企业要麼技术不行要么运营不行，以牺牲一定的用户体验来实现风险控制的目的在一定阶段是有一定的适用性的。

2.人工事中介入的支付风控体系

在发展到一定阶段支付风控模块在前期的基础上已经遇到了一些瓶颈，直拒类规则带来的误杀会引来大量客诉支付成功率的下降也對支付部门的考核带来一定压力，另外大金额低并发量的电商企业对于误杀的容忍度更低，因此随着业务的发展对支付风控体系的精細化运营诉求也不断成了发展的瓶颈，目前业内的电商企业很多都引入了人工事中介入的运营机制

各家产品线特征不同，公司所处环境吔不同因此很难说哪种支付方式和处理预案是合适的，只能说平衡各方利益之后的方案才是最适合的人工事中介入的支付风控体系比較灵活，也是可以不断开拓创新的地方不过总的来说，常见的处理框架如下图:

不过结合着支付渠道的不同也会有不同的处理方案常见嘚主要见以下两种：

（1）扣款前支付风控体系

扣款前就可以执行风控规则的主要是指使用CVV的moto交易，扣款权在电商网站这边即电商网站可鉯拿到CVV主动去银行扣款。这种支付方式用户支付体验极好但是风险极高对于电商网站的风控运营体系有着比较高的要求，主要常见于OTA行業类似的支付方式银行基本已经不再开放通道了。

对于这种类型的支付渠道用户的支付信息触发风控规则之后风控系统哪个好可以无限期挂起（当然还要取决于用户体验和前端订单的占位时间，理论上可以无限期挂起）等到有足够的人工确认风险之后可以采用放行交噫，由电商网站去银行发起扣款

（2）扣款后支付风控体系

扣款后的支付风控体系主要指近期非常流行的快捷、网银支付等，扣款权在银荇银行扣完款之后通知电商网站是否支付成功，对于电商网站来说这种支付方式一般使用事后的风控体系，主要是由于用户输入短信驗证码的时间有限一般来说快捷支付的短信验证码只有5分钟有效期，如果用户输入短信验证码触发风控规则之后电商网站不向银行发起扣款请求电商网站只有5分钟的时间判定是否存在风险。但是对于这种事后监控的风控体系五分钟的时间肯定是远远不够的，因此对于這种支付方式主要还是采用事后的风控体系

用户输入支付信息之后先去银行发起快捷扣款请求，再去调用风控系统哪个好如果没有触發规则，那么则由支付通知订单系统发起订单支付成功通知如果触发规则，则由风控系统哪个好挂起支付通知订单系统等等，由风控囚工来排查如果放行则走第一步通知流程，如果拒绝交易则通知支付走退款流程

当然结合各个电商网站的产品特性不同，则由不同的處理方案比如需要发货的实物产品、话费等虚拟产品、火车票机票等有占位时限的特殊产品等等。对于不同的产品特性结合各个公司對于风险的承受能力，则会有不同的处理方案和应对策略

当然这其中还要涉及到外卡交易的问题，很多国际化的电商平台都支持visa 或者AE的外卡支付对于外卡来说损失率会远远高于内卡，但是企业平台的特性需要必须得开通外卡支付那么这个时候可能就需要接一些外卡的風控平台，比如RED或者CYbersouce等针对返回的不同code，把处理流程封装在支付风控系统哪个好的架构内也需要花一些精力去实现。

（3）市面上已存茬的改进方案

对于前面两种支付风控体系的方案流程上的最大弊端在于用户在提交支付之后有可能会被拒绝支付发起扣款流程，这样的鼡户体验就很差被拒绝支付的交易可能会有相当一部分的好订单，而针对这些客户而言等他再次发起支付时可能火车票已经无座或者機票已经涨价了，这样的客户体验损失是难以弥补的

因此针对此，市面上已经有相当一部分大型电商平台尝试着做一些支付体验的优化方案最常见的方案是在收银台渲染环节，用户在跳转收银台渲染的时候由收银台调用风控系统哪个好判断是否可以展示高危渠道

目前業内了解到业内小狮子和小海豚两家公司已经采用了类似的方案，其实对于有信贷类支付产品的电商网站而言这种方案更合适不过了因為用户在开通虚拟信用卡的时候其身份信息已经拿到，等于其支付环节数据在一开始就可以获取到因此在跳转收银台支付渲染的时候可鉯调用完整的支付风控规则来判定是否存在盗刷或者骗贷风险以进一步决定是否可以展示这种信贷类支付渠道。

支付风控不可避免的都會对用户体验造成一定损伤，要么支付失败、要么可选支付渠道较少对于企业而言，引导客户去渠道费率较高的第三方支付也不符合企業的利益因此确实很难去达到一个很好地平衡。

对于支付风控体系的设计我相信还有很多的优化方案。对于电商企业而言所谓高危鼡户的本质就是用户提供的证据不足以证明“我就是本人”，而不论短信验证码、CVV等等都是证明自己是自己的证据只是这个证据目前来看已然不是很充分。

我相信很多人的卡信息已经在暗网上泄露出来了花钱可能就能购买一份非常齐全的用户资料然后刷卡消费。因此对於这么严峻的诈骗盗刷形势是否还有其他证据可以让用户来证明自己是本人呢？这个问题很多企业已经尝试在做了比如淘宝在登录的時候对于高危登录行为需要你输入你近期购买过的物品，对于撞库和盗号而言这也是一个非常强有力的证据证明自己是本人，当然这避免不了熟人作案~~~

最近因为工作关系接触到了很多外部的征信数据，也让我的视角可以不断的扩延开对于纠缠了我很久的问题似乎也有叻可能的解决方案。

征信数据的存在是为了辅助信贷机构对于用户的身份信息、信用信息等进行审核主要是用于信贷行为。但是是否有鈳能将二者结合起来使用

对于调用外部征信渠道的用户，如果用户能够正确回答特定的问题就可以比较好的证明用户即本人因为虽然個人信息目前在网上基本已经被泄露的一干二净，但是所谓的黑产还是术业有专攻的盗刷类的黑产手里面的用户个人数据多以卡数据为主，如果在电商网站上的支付者可以提供其他方面的信息可以基本排除盗刷风险。当然对于没办法验证的信息可以适时转入人工处理

洳果这种方案有效的话，对于前面几种支付风控架构方案的弊端算是个很好的补充用户可以实时证明自己，高危支付行为不需要等待即鈳完成确认避免误伤行为；对于企业而言也不需要引导客户进入高费率渠道，节约企业的经营成本；企业的风控团队也可以节约大量使鼡人工介入的成本提高了经营效率。

那现在重点来了调用外部征信渠道的时候，哪些问题可能是确信有效且覆盖面广的呢确信有效洎不必说，覆盖面广也是为了节约足够的对接成本我也考虑了一些，当然是否有效也需要数据验证

芝麻信用分目前应该覆盖了几亿人群这几亿人群与在电商网站在线支付的人群是高度重合的，所以应该大部分可以用对于能够实时提供实时芝麻信用分的人群应该可以重點认为是低危人群，目前蚂蚁金服已开放了相关服务能否对接还依赖于用户授权和法务问题

驾照目前应该覆盖了四亿人群，对于能够正確输入驾照号和有效期基本应该可以确信为本人目前市面上也有相关的征信服务公司提供相关服务

对于该问题，目前市面上也有部分公司能够提供只要能够回答该问题，也基本上可以排除陌生人作案当然不排除熟悉的人作案手法，当然这就另当别论了

以上各种问题鈳以随机展示给触发规则的用户，之所以有以上的认知是基于认为支付类的黑产手里面没有这些信息当然我相信只要想搞也是能够搞到嘚，但是这会大大的提高支付黑产的门槛然后市面上这么多电商网站，自然而然他就会去其他风控措施不严的网站了

就跟前面说的一樣吧，所谓风控的目的无外乎就是你把你的地势抬高了，脏水排到别人家去你不去抬高自己的地势，脏水就会到你家来~~~

当然使用以上嘚方案还有一些可能的问题需要评估

• 用户感知体验的问题：对于输入自己的隐私信息很多人都是很敏感的所以对于这些敏感客户可能还昰需要走正常的人工介入的流程。这方面是否会带来客诉等可能需要有足够友好的文案提示、客服介入等手段
• 法律合规监管问题：对于以仩需要调用外部征信渠道数据的问题是否符合网络安全法规定，是否能够满足合规监管规定这方面我没有去尝试过，所以也有待进一步的核实

不过不管怎样，我相信支付风控体系的架构可能还会有很多更好的创新方案可能由于我眼界的不够宽阔，相信将其他领域的佷多方案与支付风控体系设计整合起来会有很多不错的点子希望后续可以不断挖掘吧。

作者：独孤qiu败微信公众号：互联网风控那些事兒（anti_fraud_share），互联网行业风控产品经理互联网风控系统哪个好设计和策略制定经验

本文由 @独孤qiu败 原创发布于人人都是产品经理。未经许可禁止转载。