一文看懂支付风控场景分析与数据仓库建设

Posted 2021-04-24 风控SaaS联盟

导读

风控是一个让人爱恨交加的话题。 对支付来说风控是必不可少的功能。这个系列的文章将试图从这两个领域简单梳理下支付风控面临的问题，以及如何从技术角度来解决这些问题。

福利提醒：风控SaaS联盟已经建立会员群，欢迎添加联盟君微信：fk-sir。

1

支付风控场景分析

支付风控系统是通过采集交易、渠道、商品、账户、用户等信息，对这些数据进行实时和定时的挖掘分析，识别出各种风险，采取各种措施降低损失。在实际应用中，支付的五个场景和欺诈风险主要特征如下：

场景1：注册场景

对于有账户体系的支付，在注册场景主要面临垃圾注册的欺诈风险。那么欺诈者注册这么多小号的目的是什么?就动机而言，我们的分析遵循利益诱导机制：

• 支付平台可能通过营销活动吸引新注册用户，注册送红包类似，对于欺诈者而言可以通过注册很多小号而薅羊毛

• 欺诈者通过注册小号，为后续发起洗钱、盗卡等欺诈行为打伏笔。

欺诈风险特征1：在用户注册时，当我们寄希望于用图片验证码完成人机图灵测试时，你会惊讶的发现黑色产业链上下游链条中，已出现打码平台这样颠覆三观的人力众包平台。

欺诈风险特征2：在用户注册时，当业务尝试限制用户只能通过手机号注册，且要求进行手机下行短信验证码验证时，这时黑产链条中不仅有打码平台，还有收码平台。

通过收码平台，欺诈者以廉价的方式获取非常多的虚假手机号进行注册，且通过收码平台提供的收短信验证码的客户端工具，欺诈者可以轻松绕过手机短信验证码环节。

场景2：登录场景

对于有账户体系的支付，在登录场景主要面临账户被盗和撞库风险。

首先，对于账户盗用风险，往往用户是因木马钓鱼或互联网泄露数据等各种不安全操作，导致持有的账密信息被盗取。欺诈者在获取账密信息后，会尝试越权登录访问用户支付后台页面，进而发起盗卡交易行为，如购置虚拟商品等，导致用户账户资金损失。此外，越权访问获取支付账户的个人信息利用价值非常大，往往也会被欺诈者在黑产市场中反复交易利用。

对于账户撞库风险，无疑是任何平台的梦魇。互联网用户在网络上注册开通了许许多多的应用或网站服务，许多人在不同网站的账户和密码其实是同一个。那么会存在一个木桶短板效应，只要其中某一个应用或网站的安全性较弱导致被黑帽子攻陷，该网站的账密数据库进而发生泄漏，这个过程我们称之为拖库。

黑帽子在完成拖库之后，进而会对数据进行清洗、封装，并对一些有价值的平台进行定向撞库攻击，即用已泄露账密进行模拟登录尝试，尝试成功即意味着单个账户撞库成功。账户撞库风险的危害在于导致数据大规模性泄露，但与此同时黑产者攻击的成本正随着工具自动化而逐步降低。

欺诈风险特征2：用户登录环境异常。尤其是在撞库风险过程中，黑产往往会使用成熟的工具程序进行批量模拟登录接口。那么，通过在登录页面布控的人机识别检测程序，往往我们能发现登录来源设备是缺失或者伪造，且用户交互的行为存在明显缺陷。

欺诈风险特征3：用户登录习惯异常。通过长时间对用户登录行为的跟踪分析，我们可以分析出账户常用设备、常用登录地等行为习惯。在此数据分析基础上，建立一套可信设备体系，即对于在可信设备上的行为业务应快速通过放行，而发生在非可信设备上的行为应加入重点关注。这其实也是做大数据风控所追求的，即在业务中让好人有更好的用户体验，而让坏人寸步难行。

场景3：绑卡场景

在用户绑卡场景中，平台通常已经是从卡的维度进行风险防控：

• 对卡进行卡号、身份证、姓名、预留手机的四要素验证

• 业务策略限制，为了防盗卡要求只能同卡进出。其实即便要求同卡进出，还是会存在被欺诈者利用的风险。
  

场景4：支付场景

在支付场景中，平台主要面临的风险是导致资损的盗卡支付及监管层面要求的反洗钱反套现监控。

盗卡支付风险起因还是在于个人隐私信息泄露，很有可能你在绑卡的时候，银行卡、密码、CVV码、身份证、手机号信息已经在地下黑产转卖好几手。现在也有很多黑产通过各种渠道如邮件或伪基站，发送钓鱼链接诱导用户主动送上自己的信息。洗钱套现行为更多是金融账户持有人侧的违规行为，通过利用系统或者账户卡的漏洞空子，来达到经济上的收益。

欺诈风险特征1：盗卡行为异常。沉默的支付账户突然发生一笔小额支付，成功后随后若干次等额进行支付操作。此类行为往往具有高风险性，欺诈者在盗卡成功后进行初次激活，在进行小额尝试成功后进而进行批量的资金转移。

欺诈风险特征2：洗钱行为异常。通过对一周或者一个月内的账户资金流入流出分析，如果资金的流动是密集集中在一些账户，而这些账户活跃的IP、设备是同一个或者相近的，那么风险异常是非常高的。

场景5：信用支付场景

在大众创业万众创新的今天，支付行业也在做不同的金融创新业务，如信用支付或分期类业务。那么在信用支付场景中，除了欺诈风险，我们更关注的是金融账户持有人的信用风险。但根据不同阶段，我们的关注点不一样。

在预授信阶段，需要对金融账户进行贷前初审。而在已放款阶段，需要对借款人进行贷后的持续跟踪管理。

在支付环境中，风控系统实现可以参考一下几种方案：

（1）数据库方案

将风险规则、交易数据等都采用关系数据库存放。正如支付系统风控系统建设思考所提到的方案，交易库和风险库一般分别部署在不同的服务器上，在事件触发上可以采用数据库触发器、消息队列事件等方案。此种方案技术实现相对简单，但在进行海量交易数据查询以及大量风险规则处理时候，数据库系统查询性能及扩展性成为一个较大的瓶颈。很难满足风险事件实时分析的要求。

（2）内存数据库方案

由于对海量交易数据的查询、分析极其消耗数据库资源，可以采用内存数据库方案来替代关系数据库，保证风险事件实时处理的性能。 但目前开源的内存数据中VoltDB、H2、MonetDB、FastDB、Berkeley DB、SQLite等在大规模的业务场合应用的成熟度尚待考察，而Oracle TimesTen、MCObject eXtremeDB、Altibase价格太高。

（3）分布式缓存方案

采用Memcached等NOSQL的分布式缓存来缓存交易数据、风险规则等，但由于NOSQL解决方案并不擅长数据间的关系逻辑处理，需要在程序中大量维护业务处理逻辑，远不如关系数据库或内存数据库方案方便。

以上方案，都可以通过规则引擎（例如drools）来完成风险规则的管理和维护，避免了风险规则维护的繁琐及规则间复杂关系处理。

2

支付风控数据仓建设

风控分析不仅要看交易数据，还得研究所有相关联的数据，这才能全面分析出来风险的根源，推断出需要采取的措施。因而数据采集工作对风控系统建设和演化是非常重要的。

1、数据来源

一笔交易的风险等级的计算需要考虑到多个维度。未成年人购买高档酒、促销期间羊毛客刷单、在洗钱高发地区的商户销售的物品成交价格远超实际价格。这些可疑交易的识别，仅依靠支付系统本身是无法完成的。用户的年龄、商品特点(是否高档酒)、是否促销、羊毛号的识别等，需要从各业务系统，甚至公司外部收集和用户、商品、商家、地区、手机号相关的数据，通过对这些数据进行分析，提取特征，识别潜在的风险。

（1） 内部数据

风控几乎需要收集所有相关系统的数据。

• 用户系统：采集用户的静态信息，姓名、性别、年龄等。风控系统不仅仅关注这些静态信息，还需要重点关注用户的行为信息，包括注册、密码修改、修改个人信息等操作，需要收集这些操作的时间、地点、设备等信息。 此外，用户之间的关系，也是风控系统需要关注的数据。

• 商户系统：除了采集机构的基本信息，如成立时间、注册时间、人员规模、营业额、销售额、经营范围、注册地点等， 还需要考虑到该商户关联的用户，包括法人代表、公司组织结构、主要员工信息等。

• 商品系统：商品的静态信息，包括类型、价格、上架时间、库存等信息; 商品的浏览、放入购物车、购买、评论、退货等用户操作，包括这些操作的时间、地点、设备等信息。

• 社交数据：包括评论、论坛、留言等。

• 业务系统：如视频系统中的观影记录、类型偏好、时间、地点、设备等信息。

当然，支付数据是风控最重要基础数据。用户在支付系统中涉及到的数据都需要收集整理来支持风控分析。包括但不限于：账户数据，订单数据，交易数据、优惠券数据、账务流水等。这些数据在支付数据库中也存在，风控所需要的数据和业务数据略有不同，除了业务数据外，风控还关心如下数据：

• 账户，订单等操作实体的状态。在业务数据库中一般仅保留实体的最终状态，比如账户是否已锁定、订单是否已支付等。 而风控需要关心这些状态变更的时机，以及变更的时间间隔。例如，用户频繁更改交易密码，超正常频率提交订单等，就不是一个正常的状态。

（2）外部数据

对于大部分业务单一、用户量不大的公司来说，其数据有限而且单一，需要使用外部数据来辅助完成风控计算。 常用的外部数据包括：

• 公安部的实名认证数据，包括用户姓名、身份证号信息。

• 央行发布的各种名单，如洗钱区域，恐怖组织名单等。

• 央行信用报告，这个查询可是要真金白银的。

• 微博数据，一个人经常了解如何养卡，套现等内容并不是太好的事情。

• 工商局提供的公司信息。招聘网站上的公司招聘信息。

• 芝麻信用，这个需要申请。

（3）采集方式

一般来说，风控的非实时数据采集，不能直接从线上的数据库中读取，这会把数据库打死。主要的数据采集方式有从库采集，日志采集和pingback三种方式。

数据库从库：主流数据库，如Hbase，mysql都提供同步数据进从库的功能，读取从库不会影响主库操作。但如上所述，采用从库有如下问题：

• 分析所需数据和业务数据不同，还需要从其他途径补充数据。

• 将风控所需数据和业务数据紧耦合起来了。一旦业务有变更，风控系统也需要调整。

日志：这是风控数据采集的主要方式。 业务方可以将风控所需要的数据输出到日志中，风控系统对接日志来异步采集数据。这使得数据采集不会影响业务处理主流程。 这种方式风险在于：

• 需要规范日志的格式，否则每个系统一套日志格式，会导致对接工作量巨大。

• 保持日志的稳定性。一旦代码被修改，打印日志的代码被删除了，会导致日志数据无法采集的风险。

需要注意日志采集系统的可靠性。目前主流的采集框架都有可能会丢失日志。虽然从我们使用的情况来还未发生这种事情，但不排除这个风险。

从技术上来说，日志采集的框架主要框架有：

• ELK(Elastic + Logstash + Kibana)， Logstash 驻留在日志输出端采集日志，并发送到Elastic 服务器上。 Kibana则是一个日志分析的工具;

• Flume + Kafka + Elastic 。 通过Flume进行采集，输出到Kafka，汇总到Elastic进行存储。日志分析可以在Elastic上离线非实时进行，也可以直接对接Kafka准实时分析，即流处理。 使用Storm 或者Spark都可以。

• pingback。Pingback指在页面上埋入脚本来监测用户的操作，特别是点击操作和键盘操作，将检测到的用户行为异步发送到服务器端。这可以侦测到用户在页面停留时间，鼠标点击的区域等信息，由此可以推断用户偏好，情绪等信息。 pingback的挑战在于如何在服务器端应对流量洪峰。pingback数据一般不直接入库，可以先写入Kafka，风控系统对接Kafka来分析pingback数据。

2、数据特征

用于支持风控计算的最终数据，在静态与动态数据为基础计算出来的带置信度的推算数据为主的离散数据。

（1）静态数据与动态数据

上述采集到的数据，大部分是静态数据。也就是这些数据一旦产生，一般不会被修改。但在分析时，还需要一些易变的动态数据来，比如用户的 年龄，每天的访问量，每天消费金额等。

（2）原始数据与推算数据

不管静态还是动态数据，他们都是从用户输入或者系统采集的方式产生。但我们知道，互联网的数据可靠性是有问题的。网上千娇百媚的姑娘，在现实中可能是一位抠脚大汉。虽然系统中设计了复杂的表格来收集用户信息，但会提供全部信息的用户还是很少，大家对隐私内容还是捂得很紧。

所以，在进行风险计算前，还需要对数据进行验证和补充。这都需要借助其他数据来进行推算，这些数据被称为推算数据。推算数据和原始数据不同之处在于它会有多个可能取值，每个值都带有置信度。完全可信为100%，不可信为0。置信度总和为1。比如正常情况下，用户的性别要么男，要么女。假如有个用户注册时选择性别女，但经常买刮胡刀，衬衣，没有买过女性用品，那实际性别为男的置信度就非常高。

（3）离散数据与连续数据

这是从属性值的取值范围来评估。比如用户每天的订单额，一般来说是连续分布的。而性别，职业，爱好等，是离散值。一般来说，离散值更容易做分析处理，刻画特征，所以在分析前，需要对连续数值做离散化处理。

3、名单数据

名单数据是支付风控数据仓库中最重要的内容。 风控系统数据仓库建设，也一般都从名单数据开始。 名单加上简单的拦截规则，已经可以解决绝大部分风控的问题。就算在更先进的风控系统中，名单仍然是风控中的基础数据。在评估事件风险时，名单往往是用来执行第一道拦截时所用的数据。比如用户交易时使用的手机是黑名单中的手机，则必须终止本次交易。

（1）黑白灰名单

大家都熟知黑名单与白名单，一个是必须阻止，一个是必须放行。 除此之外，还有灰名单。灰名单用于对一些高风险的用户进行监控。 这些用户的行为不是直接阻止，而是延迟交易，经人工确认无问题后再放行。

（2）更新周期

相对其它数据来说，名单数据的更新频率不高，按天、周、月更新都有，很少有需要实时更新的内容。对于手机号，证件号等名单，一般可以采取人工更新的策略。每天评估风控数据，对确认有问题的号码，加入到黑名单中。如果采用的是第三方名单，则需要按照第三方的要求对名单做更新。

（3）名单列表

一般来说，风控系统需要配置的名单列表有：

• 个人名单，如下名单是必备的(后续会及时更新)，央行的反洗钱恐怖分子名单;公安部的通缉犯名单;全国法院失信被执行人名单信息公布与查询。

• IP名单，没有权威的IP名单。这需要在运行中积累。建立IP名单需要注意如下事项：公司内部IP，合作伙伴IP可以列入白名单列表;手机运营商的IP也要做到白名单中，封一个IP等于封掉一大批手机号;代理服务器可以列入灰名单;访问量大的IP也可能大公司的外网IP，不能仅依赖访问量来识别黑IP。

• 公司名单，必备名单包括央行反洗钱制裁公司名单和工商局失信企业名单。

• 手机号名单，这也没有权威数据，电信运营商也不会提供此类服务。支付宝正在推广这个服务，但还没有公开。黑名单数据需要自主收集。

• 地域名单，央行公布的联合国反洗钱地区名单是必须在风控时考虑的名单，其他地域名单也需要自主收集。

• 协查名单， 公检法协查名单，接收到协查请求后，将人员全部信息拉黑。

（4）名单数据存储

名单数据在使用上的特点：

• 使用频率高，实时性要求高。各种名单匹配基本都需要在线上做实时计算。

• 数据粒度小，总量大小不一，但存储空间需求都不高。大部分名单都是一些号码表，几个G的空间都能存储。

• 更新频率低。名单数据一般都比较稳定，按天更新。

在使用中，名单数据一般直接存储在内存中，或者使用内存数据库(Redis，Couchbase)。关系型数据库可以用来保存名单数据，但不会直接被线上应用所访问，它无法满足高访问量的需求。

4、画像数据

名单数据能够快速发现用户在某个维度上的异常行为。在实际使用中，存在过于简单粗暴，一刀切的问题。比如如果限制单次购买金额为5000元，这个规则被试探出来后，攻击者会选择4999元来规避这个限制。画像技术则是尝试从多个维度来评估当前事件的风险。比如画像刻画某用户平时主要在北京地区登录，购买习惯在10~300元之间。某一天突然发生一笔在东莞的4999元额度的消费，那这笔交易就非常可疑了。而这种交易通过规则比较难发现出来。支付风控涉及的画像包括用户、设备、商品、地域、操作行为等。这里重点介绍用户、设备和商品的画像。

（1）用户画像(persona)

用户画像是从用户的角度来刻画其背景和行为习惯，为判定某交易的风险等级提供支持。

用户画像的内容包括但不限于：

• 人口信息：一般就叫基本信息，主要包括：姓名、性别、出生日期、出生地、民族、星座等。

• 资产特征：月工资、年收入、工资外收入、房产、车等。

• 家庭特征：婚姻状况、是否有小孩、小孩关联、家庭成员等。

• 交易偏好：交易频率(总计、年、月、日)、交易金额(总计、年、月、日)、常用账户、交易时间偏好、交易地点偏好、交易所使用设备、交易物品、交易物品所属类别等。

• 行为特征，这是和业务相关的特征。比如对于电商，关注 用户浏览的物品、浏览的物品类别、购买的物品等。而对于视频网站，则关注用户查看的视频、观影时长、类别偏好、观影地点偏好等信息。

对于已登录用户，可以使用用户ID来识别并做画像，但对未登录用户，系统需要通过设备来识别。

（2）设备画像

一个用户配备多台智能设备已经是很常见的事情了。手机，PAD，笔记本，台式机，都是常用的设备。用户在不同的设备上的行为往往是不一样的。有人偏好在电脑上寻找要购买的商品，却最终使用手机来下单，因为手机支付更便捷。 对设备进行画像，和用户画像类似，实际上是刻画使用设备的用户的特征。 此外，对于未登录用户，由于无法标识，也只能通过设备来代表这个用户。设备画像关注如下信息：

• 设备信息，包括设备类型、型号、屏幕大小、内存大小、CPU类型、购买时间、购买时价格、现在价格等。

• 交易偏好，同用户画像。

• 行为特征，同用户画像。

对设备画像来说，生成一个能唯一识别该设备的标识，即设备指纹，是数据采集中的一个挑战。设备指纹具有如下特点唯一性，每台机器的指纹都不同，不能重复。一致性，机器指纹在一台机器上是唯一的，不同应用，不同登录用户中取到的指纹都是一样的。稳定性，指纹不会随时间变更，不会由于外围设备变更而变更。重装应用，重装操作系统也应该保持不变。

（3）商品画像

商品画像是从商品的角度来刻画购买或者拥有该商品的人的特性。

• 基本特征：名称，价格，类别，是否虚拟资产，上架时间，下架时间等促销信息：价格，开始时间，截止时间。

• 购买者特征：偏离这个特征越多，风险越大。购买时间分布，地点分布，价格分布，数量分布，年龄分布，性别分布等。

（4）画像数据存储

画像数据有如下特点：

• 数据粒度大。一个用户的画像数据，成百上千个维度都正常。大部分数据都是推算数据，也就是数据格式是带置信度的，比如 {性别： 男，80%;女，20%};每个维度的数据一般最终都需要离散化，比如年龄，虽然0~150的取值区间还不算稀疏，一般还会将年龄再分段。

• 数据量大。考虑到匿名用户和设备，上千万规模的注册用户，匿名用户和设备会在数十亿规模的量级。

• 数据结构不稳定。 根据业务需要会频繁添加新的数据维度，甚至添加新实体进来。

• 数据更新频繁。采用推算数据，每天不仅仅要计算新增数据，也需要重新计算现有数据的维度权重。

• 数据访问频率高。交易时计算权重，也需要使用画像数据。

很难有一个数据库能够同时满足上述的需求。画像数据存储需要综合采用多种数据库来满足不同应用上的需求。数据写入库， 需要支持数据批量、快速地写入，Hbase是个不错的选择。数据读取库，需要支持数据高速读取， couchbase可以满足这个需求。但couchbase不能存储所有数据，这样成本太高。 可以把couchbase作为HBase的缓存来使用。

写库和读库之间的数据同步。可以根据业务量选取合适的消息队列。每天更新的数据规模在百万及其以下，ActiveMQ可以满足需求;而上千万的数据，则需要使用Kafka。

5、知识图谱

画像是从群体和个体的统计角度评估事件的风险，而图谱则更进一步，从关系的角度来评估风险。 知识图谱是由Google提出来并应用到搜索引擎上，其后在多个领域都得到很好的应用。 交易是一种社会行为，所以从关系的角度来评估这个行为，能够更精确的了解行为中存在的风险。一个简单的例子，如果发现A是高风险的用户，而通过社交图谱分析，发现A经常和B有交易关系， 那B的风险等级也相应地会被调高。

知识图谱是基于图的数据结构，它的存储主要是使用图数据库。关系型数据库和Hbase等nosql数据库在处理图的关系以及关系计算上性能较差，需要专用的图数据库，当前主要的图数据库有neo4j，Titan,Jena等。neo4j是使用最多的图数据库，而且可以和spark graph集成，方便对图谱数据做处理。

注：本文来源于网络。