作为P2P产品经理，你该知道的融资端风控问题

互联网金融不同于其他的互联网产品，其直接涉及到资金交易的属性就要求了它对于风险管控的要求要远远高于其他的互联网产品。了解互联网金融平台的风控基础知识，有助于你在设计产品时对于风险点有更好的把控，做到心中有数，从容不迫。

互联网金融的核心是金融。金融最重要的就是风险管理与风险控制。而P2P行业更是因为自身的一些特性（从业者多来自传统民间小贷平台或纯互联网领域）很难兼顾规模速度和风控两者。因此作为一个P2P行业的产品经理，你要对整个平台的风控体制有一个明确的认识，必要的时候要为你的团队制定出合适的风控方案，甚至去反抗你的leader的一些“不靠谱”的想法。

本篇所讲的『风控』并不会讲出借端的『风控』，那是风控部门的主要职责，一般涉及贷端的风控系统，都是由风控部门出策略，产品部门配合。我今天要说的P2P平台的风险控制，主要包括信息安全、资金安全、技术安全和反作弊四块。至于其他的风控，比如出借端风控、公司内部的各种规范、相关的内审机制等，就不在本文的讨论范围内了。

风控的概念

提到风控就不得不提到『风险管理』，风险管理是一个过程，风险控制是这个过程中的一个步骤。

风险管理： 是一个管理过程，包括对风险的定义、测量、评估和发展因应风险的策略。目的是将可避免的风险、成本及损失极小化。理想的风险管理，事先已排定优先次序，可以优先处理引发最大损失及发生概率最高的事件，其次再处理风险相对较低的事件。对于风险管理来说，存在着以下的几个步骤：风险的辨识—>风险的预测—>风险的处理（风险的控制）。我们也将通过这个步骤来梳理P2P平台产品设计中可能会遇到的一些风险点，并提出一些解决方案方法。

今天我们要说的是一个广义上的『风控』，既包括互联网行业中的『信息风控』、『技术风控』、『反作弊风控』，也包括了金融行业的『出借风控』、『资金风控』。而且对于风控的一些方面还有监管层的要求。

因此对于互联网金融产品来说，风控已经不再是一个业务和技术上的问题。这一点需要互金产品经理有一个比较明确的认识。

风控的场景

既然我们所说的是广义上的『风控』，那到底广义上的『风控』存在于什么地方呢？我对照自己做过的产品进行了下整理。主要包括以下领域：

信息安全

应该这么说，在资金存管的政策下，P2P平台对于资金安全的风控压力在逐渐减少，毕竟所有的资金都在银行的存管体系下运营，反而是对于信息安全不管是从实际业务还是政策监管上显得尤为重要了。因为，对于P2P平台来说，不论是用户、平台还是标的的信息都需要采取强有力的风控措施来保障安全。这里需要在产品设计和开发时有预见性的针对可能出现的问题做出相应的方案，在保证信息安全的前提下提升用户体验。

用户信息安全

作为用户信息的主体，用户账户的安全直接关系到平台信息安全。又因为作为互金平台的用户账户会存储有大量的类似身份证，银行卡卡号等的敏感信息。如果出现用户账户信息泄露，极容易诱发各种侵财案件的发生。同时对与平台来说也是极大的打击，甚至可以说在这里，平台“输不起”。

我们在产品设计的过程中，就应该预判可能发生的风险点，并同开发的同事在产品和技术的各个层面制定并完善相关解决方案。

注册

在注册阶段，我们主要需要应对的是『机器注册』、『人工恶意注册』和『注册短信被攻击』。在这里我们可以采用以下的一些防范防范：

『手机号+短信验证码』：通过在需要注册手机号接收（也有上行）短信验证码，确保手机号是真实的。防止垃圾注册随便编写虚假手机号。但目前已有接码和打平台，只能是增加一点（很少）的垃圾账号注册成本。对于验证码的防范将在下边说到。『实名认证』：实名认证可以在很大程度上确保注册用户的真实性，同时也是政策监管的要求。一般对于实名认证的方式有两种：一是通过专门的实名认证入口进行认证，二是依托第三方支付平台或者银行，在进行绑卡/开户的同时完成。对于两种方式的优劣，应该说各有各的优势。第一种可以减轻用户的心理压力，避免引起用户反感，进行步步引导来完成实名和绑卡，另外分开操作的话，手续费也会加倍。第二种方式显然用户操作更少，但是容易一起用户反感，不过仅需支付一次手续费。所以实际选择哪种方式要根据具体情况来制定。『基于大数据的注册风控系统』：目前很多公司都提供了基于其自身大数据能力的『注册风险控制解决方案』，利用其所掌握的大数据分析和技术能力，建立深度特征体系，发现虚假注册、恶意刷单等非常正注册行为。

短信验证码

对于短信验证码，风险点主要在于垃圾注册和调用短信接口进行轰炸，干扰正常的短信下发，浪费短信费用（一般几分钱一条，但是量多了之后花钱也不少，而非正常的短信下发极容易被渠道提供商或者运营商封掉号码，造成更大损失）。攻击者可能利用脚本自动调用平台短信验证接口，造成短信渠道被异常关停。对于验证码风险：可以采取以下几种方式来解决：

『发送验证码前进行人机验证』：在用户操作获取『短信验证码』功能前，设置图形验证码或滑动验证码等人机验证措施，识别机器人自动操作。『请求限制』：同一IP或同一手机在一定时间内请求验证码达到上限将限制该IP或手机号的请求，再次请求时仅在客服后台记录但不发送，用户需致电客服，获取验证码。（比如单个IP在一分钟内最多请求5次，24小时内最多请求30次。单一手机号在90s内只能请求一次，24小时内最多请求10次，确定这个策略要经过完整的调研，不应因为为了安全而造成用户的极度不便。）『短信路由』：采取『短信路由』方式，主要是为了在保证短信的通达率和发送成本间达成平衡。因为不同的短信服务商的价格、条款和通达率不同，因此不同类型的短信下发由不同通道来完成，同时互为备份。对营销短信、验证码短信、用户资金提醒短信进行了分类，通过不同的短信渠道进行下发，相互之间互不影响。另外，还可以采用语言验证码功能，在用户多次请求（比如3次）验证码失败后，可以选择语音验证码来进行验证。『充分利用短信服务商的各种服务』：如短信业务量监控和IP白名单等方式，对于非正常的短信使用做到早发现，早排查。

登录

编辑：未知