美团业务风控系统设计
美团业务风控系统构建经验

规则平台
开发:系统开发
并行
对抗
策略应用 策略开发 系统开发
规则平台 标准化执行
场景:规则集 请求 mxn 规则:决策单元 mxn 因子:逻辑单元
仅计算一次+并行
合并决策
仅计算一次+并行
仅计算一次+并行
复用配置
动态执行提高性能
对抗
决策
策略应用 策略开发 系统开发
松耦合:可配置
策略
对抗
决策
拒绝
? 验证
风险事中
策略 体系
立体闭环防御
事前
事后
运营平台
对称
攻击
事前
事中
x
事后
数据体系
数据平台
风控系统
招无定式,问题决定系统架构
目录
背景介绍
初期发展
架构经验
总结体会
总结
体会
总结
原则 ① 业务需要风控,风控做好服务 ② 持续对抗过程,效率决定成败 ③ 立体闭环防御,逆转信息劣势
体会——必经被动挨打的过程
体会
回到原则一:业务需要风控,风控做好服务
业务
从业务来 回业务去
风控
服务 平台 数据
标题
内容1
子内容
内容2
子内容
V.S.
风控
风控工作原则一
风控是业务产品的必要属性
做好服务者,把业务痛点降到最低
对接
对接成本
业务保证安全 使用风控工具
中间件保证安全 使用风控服务
对接
运行成本
稳定性
+
性能
+
善后
路径优先级 隔离 + 调优 外部依赖、组件依赖 降级 攻击 限流 同步接口、异步接口 迁移规则平台——并行 报表、客诉、 核查、赔付
外卖风控实时数仓实践

ES、Hbase等。
无论是结果数据,还是中间过程数据都落在HDFS上
根据数据量的大小、访问并发量等因素选择使用
维度数据存储 HBase/Tair/Redis等KV存储。
离线数仓维度数据存放在HDFS上并通过Hive访问
数据加工过程 Flink、Storm等
Hive、Spark SQL等
Lambda架构 V.S. Kappa架构
Spout线程数
设置为消费Kafka partition数量的一半
Bolt线程数
设置为QPS* Execute Latency/1000
Acker数量
设置为worker数的一半
Flink优化--扩展DDL
• 自定义Calcite sql解析 • 自定义sink、source
Flink优化--扩展UDF
N
Exceeded
Y
Alarm & Failed
Join Key
Key Exists Y
Join success
Memory/Redis
Store Record
Storm优化--并发安全
Storm优化--sink优化
共享连接池 异步写 批量写
Storm优化--配置实践
Worker数
设置为消费Kafka partition总和一半,然后再看性能调整
实时性 计算资源 批处理效率 研发成本 运维成本
Lambda
实时 流和批同时运行,资源开销大
批处理吞吐量高 流和批各开发一套代码,成本大
维护两套系统,成本大
Kappa
实时 流批分离,回溯数据时才开启批处理,资源开销小
批处理吞吐量低 流批共用一套代码,成本小
业务系统风控技术方案

业务系统风控技术方案一、风控目标。
咱这个业务系统啊,就像一艘航行在商海里的船,风控就是那保驾护航的舵手。
风控的目标呢,简单来说,就是让业务系统稳稳当当的,别出乱子。
一方面要防止那些坏蛋(恶意用户)来捣乱,像是骗钱啦、偷数据啦;另一方面呢,也要确保正常用户能顺顺利利地使用系统,可不能误伤到好人。
二、风险识别。
1. 用户行为分析。
这就好比观察一个人的一举一动。
我们要记录用户在系统里干的各种事儿,像登录的时间、地点,操作的频率、类型啥的。
比如说,如果一个用户平时都是白天在本地登录,突然大半夜从国外登录了,还不停地修改重要信息,这就有点可疑了,可能是账号被盗用了,或者是有不法分子在试探。
对于那些频繁登录失败的情况,也得小心。
这可能是有人在暴力破解密码,就像小偷在不停地试钥匙,想打开我们的“房门”。
2. 数据异常检测。
数据就像是我们业务系统的血液,得时刻关注它的健康状况。
要是突然有大量的数据流入或者流出,而且不符合正常的业务模式,那就得警惕了。
一个小商家平时每个月的销售额就几千块,突然一天有几百万的交易,这很可能是数据造假或者是被黑客攻击用来洗钱了。
还有数据的完整性,如果发现某些关键数据缺失或者被篡改了,就像身体里少了个器官或者器官被换了,这肯定是出了大问题,得赶紧查清楚。
三、风险评估。
1. 风险等级划分。
我们把风险分成三个等级,就像游戏里的小怪兽,有小怪、中怪和大BOSS。
小怪级别的风险呢,可能就是一些小的异常行为,对业务影响不大,比如偶尔的登录地点小变动。
这种情况我们可以先观察观察,给用户发个小提示,让他们确认一下是不是自己的操作。
中怪级别的风险就严重一些了,像多次登录失败或者少量数据异常。
这时候我们可能要限制用户的某些操作,比如暂时冻结账户的资金转出功能,让用户通过一些验证手段来证明自己的身份,比如短信验证码或者回答安全问题。
大BOSS级别的风险那可就是大灾难了,比如大规模的数据泄露或者持续的恶意攻击。
电子商务平台的信用评估与风控系统设计

电子商务平台的信用评估与风控系统设计随着电子商务的快速发展,电子商务平台日益成为买卖双方交流的桥梁,并且为交易提供了便捷的平台。
然而,传统的线下商务中的信用体系无法直接应用于电子商务中,这就需要电子商务平台建立自己的信用评估与风控系统,以确保交易的安全性和可靠性。
信用评估与风控系统是电子商务平台中不可或缺的重要环节。
它通过收集和分析买卖双方的信用信息,评估交易风险,帮助平台进行精确的风险预测和防范,从而确保交易的安全和可信赖。
首先,信用评估系统的设计应包括信息收集、信息验证和信息分析三个基本环节。
信息收集阶段需要收集买卖双方的个人或企业信息,包括身份信息、交易记录、信用历史等。
信息验证阶段需要对收集到的信息进行核实和验证,以确保信息的真实性和可靠性。
信息分析阶段是通过对所收集到的信息进行综合分析,形成信用评级标准和指标,为后续的风控决策提供依据。
其次,信用评估系统应该建立信用评级模型,通过对买卖双方的信用信息进行量化评估,并对其进行分类和排名。
为了确保评估的准确性和公正性,评级模型需要考虑多个因素,如交易历史、用户评价、信用历史等,综合考虑这些因素的权重,将用户划分为不同的信用等级。
通过信用评级,平台可以更好地识别高风险用户,从而针对性地采取相应的风险控制措施。
同时,风控系统的设计也是信用评估与风控系统的重要组成部分。
风控系统通过综合考虑信用评估结果和交易环境等因素,实现对交易的风险预测和防范措施的制定。
在交易过程中,风控系统可以对交易进行实时监控,及时发现可疑行为并采取相应的措施,例如风险提示、交易限额等。
此外,信用评估与风控系统还需要结合大数据和人工智能等技术手段,以提高系统的准确性和效率。
通过对海量数据的分析和挖掘,可以发现隐藏在数据背后的信息和规律,从而更好地为信用评估和风控决策提供支持。
人工智能技术可以应用于风险识别和决策过程中,通过机器学习和模型训练等手段,提高系统的智能化水平和自动化程度。
风控系统前端设计方案

风控系统前端设计方案
风控系统前端设计方案包括界面设计、交互设计以及前端技术选型等几个方面。
界面设计:
1. 风控系统前端应该具备简洁、直观、易用的特点,以提高用户体验。
将界面划分为不同的模块,如用户管理、风险监控、报告生成等,每个模块独立展示,方便用户快速找到所需功能。
2. 使用符合风控系统主题的颜色搭配,营造安全可信的氛围。
同时,界面元素的排版应该合理,避免信息过度集中或过分分散。
交互设计:
1. 交互设计应该关注用户的操作习惯,以简化用户的操作流程。
例如,通过搜索框快速查找用户或风险信息,提供多种筛选条件来缩小搜索范围,将常用功能或信息以按钮形式展示在可见区域等。
2. 提供实时反馈,以便用户了解操作的结果。
例如,在提交风险监控的请求后,显示一个加载动画,告知用户系统正在处理,避免用户重复提交。
前端技术选型:
1. 前端框架可以选择流行的React或Vue,这些框架具有良好
的生态系统和可扩展性,适用于复杂的业务需求。
2. 数据可视化方面,可以选择Echarts或D
3.js等开源图表库,根据业务需求绘制不同类型的图表。
3. 为了提高用户交互体验,可选用Ant Design等UI组件库,
以便快速构建界面。
4. 考虑到风控系统的安全性需求,可以使用Axios等工具来处理网络请求,加强数据传输的安全性。
总结:
风控系统前端设计方案需要从界面设计、交互设计以及前端技术选型等多个方面综合考虑,以提供简洁、易用且安全可靠的用户体验。
美团业务风控系统设计

③ 我在明,敌在暗
ቤተ መጻሕፍቲ ባይዱ
目录
背景介绍 初期发展 架构经验 总结体会
招无定式,问题决定架构
①
②
③
问题一 风险在哪,怎么控制?
对接
目标
感知风险
+
控制风险
感知什么?
谁 时间 环境 方式 对象 动作
控制什么? 站在坏人的角度想——利益 从利益找关联场景,思考控制点
促销优惠 -> 促销的下单、支付、… 销量、排名 -> 购买、创建活动、… 用户余额 -> 下单、支付、退款、…
初期
发展
再发展
初期
单一团购,频繁注册、购买骗取优惠 数据分析,异步冻结
发展
快速销赃,联合商家 实时防御,离线分析补充
再发展
风险升级,业务扩张 独立团队,独立服务,加速迭代
① 内部职责耦合 工程/策略
② 与业务方耦合 决策处理?
挑战
① 业务多带来风险点多
购买、支付流程 用户操作 商家操作等
② 变化快
运营平台
对称
攻击
事中
x
事前
事后
数据体系
数据平台
风控系统
招无定式,问题决定系统架构
目录
背景介绍 初期发展 架构经验 总结体会
总结
体会
总结
原则 ① 业务需要风控,风控做好服务 ② 持续对抗过程,效率决定成败 ③ 立体闭环防御,逆转信息劣势
体会——必经被动挨打的过程
对接
①服务
对抗
②效率
对称
③立体闭环
未来如何发展?
体会——从对手学习
回到原则二:风控是持久战
美团买菜IOS版设备风控浅析与算法还原

美团买菜IOS版设备风控浅析与算法还原本⽂仅限学习交流,请勿⽤于⾮法以及商业⽤途,由于时间和⽔平有限,⽂中错漏之处在所难免,敬请各位⼤佬多多批评指正。
⽬录:⼀、线上买菜场景简述⼆、风控在业务中的应⽤三、产品整体框架四、初始化分析五、反爬签名流程六、设备指纹分析七、算法还原⼋、总结⼀、线上买菜场景简述1、分析说明1. 产品基本信息产品名称:ppp买菜(匿称);产品版本:5.25.0;Slogan:30分钟送达,新鲜送得快;所处⾏业:⽣鲜电商;2. 设备环境机型:iPhone 7;系统:IOS 13.4;⼯具: IDA7.6 Frida;2、简单流程梳理⼀次完整的线上买菜过程都经过了哪些环节呢?⼤致流程是从供应商送货到仓或到店,再由零售商售卖,最终到⽤户⼿⾥,这样便完成了⼀次买菜,如图1-1所⽰: 图1-1上图的业务流程从供应商送货到仓或到店,再由零售商售卖,最终可以多种⽅式到⽤户⼿⾥,完成了⼀次买菜的过程。
⼆、反作弊风控在业务中的应⽤1、APP推⼴拉新还记得在2020年的下半年时候,当时⽣鲜电商的社区团购⼤战⾮常⽕爆,各种买菜APP蜂拥⽽⼊,砸钱、抢流量,你争我抢玩得不亦乐乎。
不夸张地说,我记得当时最常见的情形是,你随便在⼩区溜达⼀圈,就能碰见穿着各种颜⾊制服的地推⼯作⼈员,追赶着⼩哥哥⼩姐姐下载APP给送福利,下载完APP后注册登录APP买菜。
2、存在的风险烧⼤把的钱把流量吸引过来,这个过程中会有⿊灰产⼈员通过⾮法的技术⼿段,伪造新增⽤户并从中获利的⾏为,如果只是把流量吸引过来不考虑质量的话,会增加⼤量的企业⽆效成本。
怎么识别出有效的流量与虚假流量,需要⼀个完善的风控体系与制定有效的策略找出⾼质量流量,然后把这些流量留下来。
接下来为了提⾼⽤户的购买频率,实现反复转化,就出现了各种红包、优惠券活动吸引⽤户提⾼打开APP频率与购买频率。
这个环节中就会有各种薅⽺⽑的⼈群出现,同样需要完善的风控体系与制定有效的策略来最⼤程度地甄别风险。
关于美团网风险控制的方案设计

关于美团网风险控制的方案设计专业营销与策划班级营销S2011-3班学号37、40、2学生姓名黄伟敏、周科、钟棋指导教师武玲婷二O一四年五月摘要在信息化时代,美团网正以前所未有的力量冲击着传统团购活动的观念和方式,波及到社会生活的各个方面。
美团网以其诸多优势在美国和欧洲得到了不断的发展。
随着美国Groupon美团网取得巨大的成功,我国出现了一大批模仿的美团网站,据相关机构统计我国的美团网站的数量已从最初的个位数飙升到6000以上,行业规模呈现出爆炸式发展的态势。
论文分别从团购的定义、优势、问题及对策阐述了美团网的相关概念,通过对国内美团网市场状况的分析,研究了当前美团网的发展现状结合当前网络的具体情况,对这一市场交易方式的营销及趋势还有问题进行简单的探讨。
关键字:美团网;团购风险;营销策略;团购趋势目录摘要 (1)绪论............................................................................................................... 错误!未定义书签。
1美团网的概述 (4)2美团网的分析 (4)2.1成本低,价格低 (4)2.2资金流转快 (4)2.3参与商家多样化 (5)3 美团网营销策略中存在的风险 (6)3.1团购中的信誉风险 (7)3.2团购中的市场风险 (7)3.3团购中的操作风险 (8)4美团网风险的应对策略 (8)4.1信誉风险对策 (8)4.1.1美团网的售后服务 (9)4.1.2美团网的物流服务 (9)4.2市场风险控制 (10)4.3操作风险控制 (10)5结论 (11)参考文献 (11)摘要随着网络技术的快速发展,美团网已经成为当今社会一种非常重要的市场交易方式,特别是在青年群体中更为流行,美团网作为一种独特的营销策略,已经成为现代商务理念、营销管理决策等领域备受关注的课题。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
初期
发展
再发展
初期
单一团购,频繁注册、购买骗取优惠 数据分析,异步冻结
发展
快速销赃,联合商家 实时防御,离线分析补充
再发展
风险升级,业务扩张 独立团队,独立服务,加速迭代
① 内部职责耦合 工程/策略
② 与业务方耦合 决策处理?
挑战
① 业务多带来风险点多
购买、支付流程 用户操作 商家操作等
② 变化快
体会
回到原则一:业务需要风控,风控做好服务
从业务来
业务
风控
回业务去
服务 平台 数据
对接
现实
业务多
x
前台多 后台多
x
场景多
近100个细分业务
iPhone, Android i版, PC 移动后台, 订单中心 用户中心, 促销工具 商家后台, …
购买流程 下单、支付、支付成功、配送成功等
用户操作 注册、登录、找回密码、换绑手机等
商家端操作 验券、新建促销、退款等
对接
关键
业务
V.S.
美团业务风控系统设计
技术创新,变革未来
目录
背景介绍 初期发展 架构经验 总结体会
美团
酒店
旅游
到店综合
猫眼
到店餐饮
团购
外卖
云计算
金融
业务风控
品类覆盖面广 用户多
商户多 高频交易
用户作弊
“薅羊毛”,促销、优惠
商家刷单
刷销量、排名、好评、…
账户和支付安全
信息、余额、支付盗用
目录
背景介绍 初期发展 架构经验 总结体会
问题二 黑衣服的是坏人 —— 但坏人会换上其他颜色
对抗
风控工作原则二 —— 持续对抗过程
策略
增加要素
减少强依赖 黑衣服 + 黑帽子的是坏人
策略网
模型问题? 不稳定的算法问题
模型+规则
结合使用
对抗
效率
持久战的决定因素
产品:策略应用 策略:策略开发 开发:系统开发
规则平台 并行
对抗
策略应用 策略开发 系统开发
未来如何发展?
体会——从对手学习
回到原则二:风控是持久战
资源拆分
服务化模块
对利益的嗅觉
对风险敏感
体会——从军事学习
故知胜有五 知可以战与不可以战者胜; 识寡众之用者胜; 上下同欲者胜; 以虞待不虞者胜; 将能而君不御者胜。
故曰:知彼知己,百战不殆
——《孙子兵法·谋攻篇》
现不现实 人够不够 团队价值观 准备得当 老板支持
风控
风控工作原则一
风控是业务产品的必要属性
做好服务者,把业务痛点降到最低
对接
对接成本
业务保证安全 使用风控工具
中间件保证安全 使用风控服务
对接
运行成本
稳定性
+
性能
+
善后
路径优先级 隔离 + 调优
外部依赖、组件依赖 降级
攻击 限流
同步接口、异步接口 迁移规则平台——并行
报表、客诉、 核查、赔付
2亿请求/日,90%响应时间36ms,稳定性5个9
黑产升级 业务发展 环境变化
③ 我在明,敌在暗
目录
背景介绍 初期发展 架构经验 总结体会
招无定式,问题决定架构
①
②
③
问题一 风险在哪,怎么控制?
对接
目标
感知风险
+
控制风险
感知什么?
谁 时间 环境 方式 对象 动作
控制什么? 站在坏人的角度想——利益 从利益找关联场景,思考控制点
促销优惠 -> 促销的下单、支付、… 销量、排名 -> 购买、创建活动、… 用户余额 -> 下单、支付、退款、…
运营平台
对称
攻击
事中
x
事前
事后
数据体系
数据平台
风控系统
招无定式,问题决定系统架构
目录
背景介绍 初期发展 架构经验 总结体会
总结
体会
总结
原则 ① 业务需要风控,风控做好服务 ② 持续对抗过程,效率决定成败 ③ 立体闭环防御,逆转信息劣势
体会——必经被动挨打的过程
对接
①服务
对抗
②效率
对称
③立体闭环
独立服务 身份+图灵 接入体验
“杀埋一条龙服务”
问题三 全面防守 V.S. 攻击弱点
对称
攻击
批量注册 接码平台 盗取银行卡 身份证 公民信息 木马 伪基站 猫池 …
风险事中
风控原则三 立体闭环防御
策略 体系
事前
风险教育 参与业务 数据准备 主动防护
事后
善后:客诉、核查、赔付 回归:监控、预警、优化
规则平台 标准化执行
请求
场景:规则集
仅计算一次+并行
m xn
规则:决策单元
仅计算一次+并行
m xn 因子:逻辑单元
仅计算一次+并行
合并决策
复用配置
动态执行提高性能
对抗
策略应用 策略开发 系统开发
决策 松耦合:可配置
策略
对抗
决策
拒绝
?
通过
验证
对抗
验证
早期
改进
业务验证 业务开发负担 验证决策受限
“只管杀,不管埋”