支付系统风控架构实战：事前事中事后全流程设计与核心指标解析

本来按照计划是写完支付交易后，开始梳理渠道路由或清结算账户相关的内容，不过在和部分同学沟通之后，发现大家对支付的“隐形护航人”——风控，都比较感兴趣。

我自己也不是科班的风控专家，和大部分支付产品经理一样，过往工作经验里和风控的主要配合就是按照风控团队的要求，在他们需要的节点上送数据。至于风控团队收到数据后做了什么处理，对曾经的我来说也是个黑盒子，我想这也是大家对此普遍感兴趣的原因。

今天我们就从支付产品的角度，试着解读风控模块在支付系统中的核心职责与设计思路，权当抛砖引玉。内容可能不够深入全面，如有错误解读，欢迎交流指正。

支付虽然有风控模块，但风控整体范畴很大，最著名的当属金融或银行的风控体系。两者有结合，但也有显著区别。支付需要风控，而风控的重要一环也正是防范支付风险。

抛开专业视角，对大多数人来说，支付风控可能有个共同特征：正常的时候，相安无事，普遍认为这是理所应当甚至只是锦上添花的事情。

事实当然相反。很多人都是在出问题的时候，才意识到它的重要性。许多团队，哪怕是知名公司，都曾因风控漏洞付出过惨痛代价。

我们很多人对支付风控的理解是有误区的，包括曾经的我。例如认为风控就是黑名单过滤，觉得风控太严格、要的数据太多，影响用户体验，也不清楚风控到底是怎么设计的。这背后的主要原因，往往在于与黑灰产斗争的经验不足。

微信支付日均10亿笔交易，如何实现“精准拦截”而不误杀正常用户？支付宝每年拦截12亿笔可疑交易，误判率仅0.001%，并且支付宝凭什么敢承诺“被盗全赔”？背后都有一套贯穿业务全流程的智能风控体系在支撑。这些巨头拥有大量的风控案例和题材，经过常年的斗智斗勇才逐步迭代完善。

支付行业本质上就是在经营风险。当前支付风险已呈现专业化、团伙化的特征，单点防御根本防不住黑灰产的组合式、多维立体攻击，必须建立事前、事中、事后的全链路防控体系。

所以，风控的真正使命不是“阻拦交易”，而是在风险与体验的钢丝上找到平衡。风控并不是支付的绊脚石，而是让支付业务能跑得更远的基石。

今天，我们就试着拆解支付风控的设计方法，沿袭之前的逻辑，从业务需求到系统设计，一步步来看。

对于我们不专门从事风控领域的同学而言，理解这套风控体系也很有价值：一是能基本了解风控的系统设计方法论；二是可以构建风险防控的意识和整体视野；三是现实一点看，风控领域的薪资待遇确实非常可观。

支付风控系统的业务定位和需求分析

为什么支付必须做风控？可以从以下几个角度看待：

一是合规刚需：反洗钱、反恐融资等监管本身就有严格要求，央行87号文中有明确阐述；

二是为了商业生存：因为1%的欺诈率可能就会吃掉10%的利润，甚至造成更惨痛的损失；

三是为了用户信任：安全感是支付产品的核心体验，如果用户觉得在某个平台付款资金不安全，那交易闭环无从谈起，用户也可能流失。

所以支付风控的本质，是在“用户体验”和“资金安全”之间寻找动态平衡。

对于平台而言，做好支付风控可以从三个角度来看：

• 用户侧：主要目的是防止盗刷、账户接管、洗钱。
• 商户侧：要防止商户跑路、欺诈、非法经营。
• 交易本身：需要防止套现、赌博、非法集资等异常交易。

但支付风控不同于信贷风控或运营风控。信贷风控的核心是关注风险定价和还款能力，而支付风控的核心是需要能实时拦截异常。就像机场安检，要在不影响正常旅客的前提下，精准识别危险分子。

这些都对支付风控提出了更高的要求：

• 实时性要求高：支付风控决策必须在毫秒级完成，否则用户体验会很糟糕；
• 需要多维联防：既要防欺诈，也要预防合规风险；
• 需要动态调整：黑产团伙会试探规则漏洞，所以风控团队需要和灰黑产进行多轮博弈。

通过以上分析，我们基本可以把支付风控的业务需求定义为：它是支付系统的“免疫系统”，其核心业务目标是三个保证：

• 保安全：防止资金损失（如盗刷、套现）；
• 保体验：减少误拦（如更换手机登录被冻结）；
• 保合规：满足监管要求（如外汇限额、反洗钱）。

支付系统风控设计解析

支付的风控系统，围绕上面的三个保证，需要覆盖整个交易的生命周期。业内比较通用的做法，都是围绕事前、事中、事后三维度进行风控框架设计。当然，风控系统并不是简单地拦截，好的风控系统需要构建分层次的防御体系。风控模型一般的框架流程如下：

典型支付风控的整体设计流程

其中，规则和模型是分离的。规则用于处理逻辑清晰、界定确切的情况；而模型则用来处理更复杂的模式，根据历史数据提供参考建议。

分级决策：决策中心针对规则或模型提供的分数/指标等，设置从轻到重的动作，比如监控、需要验证、拦截等。

另外，规则引擎等需要能支持热部署能力，比如黑名单规则需要分钟级甚至秒级生效。

最终，按照当前所处交易阶段，进行相应处理。不同阶段的核心目标和需要执行的动作不太一样。

按照事前、事中、事后进行框架设计及必要采集动作

下面我们分别按照事前、事中、事后三个阶段，来梳理每个阶段的设计思路和方案。

事前防控：把坏人拦在大门外

这里一般需要从两个角度来设计不同的风控采集流程，分别针对商户和用户。

商户进件流程解析：商户资质审核是事前防控的主战场。不仅仅针对第三方支付公司，平台型商户也一样。整体的商户风控流程根据个人了解应该包括以下环节：

1. 多源数据交叉验证：不仅仅要查询工商注册信息，其他三方系统信息也需要查询，比如通过银联水晶球系统核验商户是否已经被其他机构标记为高风险；
2. 动态风险评分：风险评分模型需要将法人失信记录、行业风险系数（珠宝玉石类商户风险较高，超市类商户风险较低）、关联企业数量等多个因素加权量化，而不是根据某一个单维度参考；
3. 分级审批：低风险商户可以自动通过，中风险转人工复审，高风险直接拒绝并可按需上送给协会等机构。

而对于小微商户，风控难度其实更大，最好进行以下核实：

1. 生物特征绑定：小微商户法人是个人，除了基础的身份证等信息之外，最好进行生物特征采集，比如人脸，防止身份被冒用；
2. 经营场所验证：有条件的话，可以通过LBS定位，采集门店照片，并要求提供水电账单等佐证其实际经营场所情况；
3. 分层限额管理：根据不同验证情况，设置差异化的交易限额。

用户注册流程解析：针对消费者或者C端用户，也需要进行风控拦截。当然，这要根据平台的业务性质决定，不是任何环节都强制要求用户实名或提供其他校验。一般的强风控业务，用户注册环节风控流程如下：

当然，也可以要求业务系统让用户提供更多信息进行二次验证，再决定是否允许注册或进行下一步操作。

事前防控，参考一些实战总结，最好规避以下坑点：

1. 过度依赖人工审核：人工审核不仅效率低，且容易因为疲劳产生疏漏，应该以机器为主，人工为辅；
2. 数据更新不及时：黑产使用的身份证、银行卡等信息可能已经在外围渠道测试过，必须实时查询接口，不能为了成本采用离线库名单，容易产生错漏；
3. 流程设计失衡：曾有人统计每增加一个验证步骤，用户流失率可能增加10%。所以要平衡好信息验证安全和用户体验，交互设计和引导流程就非常重要；
4. 缺乏关联图谱分析：某一个商户单独看可能没问题，但如果10个商户共用一个IP或设备，那就很可能存在问题，属于团伙作案，因此必须关联分析；
5. 合规调整滞后：核验要紧跟合规要求调整。比如央行要求支付机构对商户开展尽职调查，需留存实际控制人信息等，如果未及时调整，可能会导致监管处罚。

事前防控的主要目的是“让好人畅通无阻，让坏人寸步难行”。精准的防控可以把大量潜在风险提前拒之门外。

事中防控：实时阻断异常交易

当用户点击支付按钮的瞬间，风控系统需要进行三重快速判断：你是不是真实的你，商户是不是可信的商户，这笔交易本身是否正常。

这些判断，基本都需要在毫秒级完成，本质上是一场速度对决。风控系统必须及时拦截可疑交易。这种毫秒级的对抗，靠的是背后强大的规则引擎和模型学习能力。

现代支付系统的风控模块，基本都是一个数据流式处理工厂，其核心架构可以展开如下：

1. 数据采集：采集的信息根据不同平台可能有区别，但本着“宽进严出”的原则，尽量多采集。包括设备指纹、设备ID、IP地址、用户信息、商户信息，甚至设备的陀螺仪数据、电池状态、用户鼠标移动速度、输入习惯等均可纳入采集范围。
2. 实时计算：这里需要使用流式计算框架处理海量数据，例如使用 Flink 处理时间窗口计算，Spark Streaming 处理跨渠道关联分析等，以实现复杂的实时特征计算。
3. 规则引擎：通过预设好的一条条明确规则来评估交易风险。例如“新注册账号首笔交易 > 5000元” + “未识别设备” = 风险基础分 + 50。
4. 决策引擎：根据规则触发情况，结合模型服务给出的评分、用户的历史行为数据等，生成当前操作的处理指令，比如放行、需要验证、或直接拦截。
5. 执行层：这是最后一步。若确认放行，则与支付系统联动，完成资金扣款或放款；若需要验证，则发送短信验证码或要求人脸识别。

上面只是讲述了风控处理的大致流程和设计，但实际执行还会有很多难点。高效的识别能力就是其中一个核心难点，比如：

1. 交易特征的识别：比如平台有一些正常的交易金额和时间范围。正常交易金额通常是随机数，但频繁出现888、666等吉利数字的金额就比较可疑；或者凌晨进行大额转账也是不太正常的。这只是个体层面的识别，更复杂的是需要识别其关联交易对手，比如突然转账给某个从未联系过的账户，或者资金给到对方后对方立刻快速转移走等。
2. 行为特征的识别：用户的操作习惯偏离度是个重要指标。比如平时都用 iPhone 下单但突然改成安卓；平常晚上9点之后不会有交易但在凌晨三点突然购物。以及用户的操作轨迹不正常，在支付页面停留不超过1秒，很有可能是脚本执行而非真人点击。
3. 设备网络的识别：同一设备频繁更换账号，或者同一个账号在不同设备间跳跃登陆；使用的网络环境不正常，代理IP、GPS定位与IP归属地严重不符。
4. 关联图谱的建立：最难的还是这个。团队作案可能会有多人、多账号、多设备，如果不做用户-设备-银行卡-网络IP的关联分析，可能根本无法识别出多人多账号在共用几套设备。

这些都是事中监控需要考虑和判断的，并且需要在极短时间内完成，是一项极具挑战的任务。事中风控很考验平衡艺术，规则太松可能变成黑产的温床，规则太严则误杀正常用户，并且极有可能是在用户支付流程中，严重影响用户体验。

通过公开资料总结，一些支付机构风控实践总结的事中系统设计注意点供参考：

• 分级处置机制：不要一刀切拦截，而是按风险等级柔性处理，低风险增强验证，高风险则直接拦截；
• 熔断保护：当系统负载过高时自动降级，比如只执行核心规则，避免影响正常支付，导致用户体验降低；
• 灰度发布：新的规则先对低流量试运行，比如灰度0.1%，验证无误后再全量放开；
• 性能隔离：将实时性要求高的简单规则（如黑名单检查）与复杂模型计算分离部署；
• 缓存优化：高频访问的数据（如用户最近交易记录）放在 Redis 中，减少数据库压力；
• 分布式追踪：为每个交易生成唯一 TraceID，便于问题排查；
• 规则热更新：无需重启服务即可动态调整规则阈值。

事后处置：最小化损失

事后风控不能理解成马后炮，它是风险防控的闭环。事后风控主要完成三件事：风险事件回溯分析、损失追回、风控策略优化。其中，风控策略的优化是笔者认为最具长期价值的事情。

完整的事后风控系统经常包括以下模块：

风险事件回溯分析

当发现可疑交易后，调查人员需要通过“时间机器”还原完整的作案过程：

• 交易流水分析：主要是为了定位异常交易特征，如集中在23:00-04:00的高频小额交易就是一种典型特征；
• 资金链路追踪：绘制资金流向图，识别中转账户和最终提现卡，确定资金去向；
• 行为数据分析：将用户登录、浏览、支付等行为按时间轴排列，寻找可疑点进行详细分析。

损失追偿

对于已经发生的资金损失，只能多渠道追偿，想办法减少损失：

• 资金拦截：快速联系银行或三方支付渠道，尝试冻结尚未转出的资金；
• 保险理赔：如果与保险公司有合作，可向合作保险公司提交理赔申请；
• 司法追讨：对涉案商户或个人提起民事诉讼。

但一般追回资金的路途都很漫长，甚至根本追不回。尽管如此，必须争取把可用渠道都走一遍，能挽回多少是多少。

风控策略的继续优化

这是事后防控的核心价值所在。

• 规则有效性分析：统计各规则的触发次数、准确率、覆盖度，淘汰低效规则；
• 模型迭代训练：将新发现的欺诈案例加入训练集，提升模型识别能力；
• 风险趋势预测：通过时序分析预测下一个风险高发期（如电商大促前黑产会异常活跃）。

事后处置的核心其实不完全是技术，而是预先建立的应急预案。比如法律文书模板、银行绿色通道、保险理赔流程等等。这些都是经验和教训的积累。

结语

风控系统的数据指标体系，按照以上设计逻辑推导下来肯定包含一系列核心指标，例如：

• 事前：用户/商户资质真实率、风险名单命中率（监控黑名单覆盖范围）；
• 事中：错误拦截率、漏拦率、规则引擎准确度。此外，风控决策的响应时间是关键指标；
• 事后：资金损失统计、最终追回的资金占比、处置时效等。

风控其实是一场无止境的攻防战。在这个技术日新月异的时代，黑产的技术手段也在不断进化，所以风控设计没有终极答案。

但风控确实至关重要，就像人体的免疫系统，默默抵御威胁而不影响正常机能。因此，最好的风控可能就是让用户完全感知不到它的存在。但这绝不是把风控视为成本中心的理由，因为一次做不好风控，带来的痛苦教训可能是无法挽回的。

对于从事风控的同学，我理解可能是痛苦并快乐着。痛苦的是，魔高一尺道高一丈的持续对抗；快乐的是，每一次成功的风控拦截，都是对某个普通人辛苦积攒的财富的守护。

风控领域也会遇到很多让人匪夷所思的有趣案例。朋友们，你遇到过哪些有意思的风控案例，或者有过被风控后的无奈瞬间吗？欢迎在技术社区如 云栈社区 的相关板块留言讨论。