192 lines
14 KiB
Markdown
192 lines
14 KiB
Markdown
1|# 子系统 06 — 风险与反欺诈 (`risk`) v1.0
|
||
2|
|
||
3|## 子系统概述
|
||
4|
|
||
5|| 维度 | 说明 |
|
||
6|| --- | --- |
|
||
7|| 代号 | `risk` |
|
||
8|| 核心职责 | 强弱关联判断、黑名单实体管理、风险事件管理、双重退款检测 |
|
||
9|| 数据所有权 | `risk_signals`, `risk_cases`, `blacklist_entities`, `refund_match_results` |
|
||
10|| 启动依赖 | identity（软依赖） |
|
||
11|| 外部系统依赖 | Amazon（退款数据）、财务系统（OA 返款数据） |
|
||
12|
|
||
13|---
|
||
14|
|
||
15|## 1. 模块划分
|
||
16|
|
||
17|```
|
||
18|┌─────────────────────────────────────────────────────────────┐
|
||
19|│ risk 子系统 │
|
||
20|│ │
|
||
21|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||
22|│ │ M1: 关联判断 │ │ M2: 黑名单 │ │ M3: 双重退款 │ │
|
||
23|│ │ 引擎 │→│ 管理 │ │ 检测 │ │
|
||
24|│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
|
||
25|│ │ │ │ │
|
||
26|│ ▼ ▼ ▼ │
|
||
27|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||
28|│ │ M4: 风险事件 │ │ M5: 风险审核 │ │ M6: 对外 API │ │
|
||
29|│ │ 管理 │ │ Admin │ │ Gateway │ │
|
||
30|│ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||
31|│ │
|
||
32|└─────────────────────────────────────────────────────────────┘
|
||
33|```
|
||
34|
|
||
35|| # | 模块 | 职责 |
|
||
36|| --- | --- | --- |
|
||
37|| M1 | 关联判断引擎 | 对每次风险信号做强弱关联判断（强：邮箱/设备/电话/地址/订单号/ProfileID/收款信息 命中→高风险；弱：IP单独/姓名单独/同址异名→观察+复核） |
|
||
38|| M2 | 黑名单管理 | 黑名单实体管理（添加/移除/过期）、黑名单同步、命中查询 |
|
||
39|| M3 | 双重退款检测 | Amazon 退款记录 vs OA 返款记录的自动比对，检测重复退款 |
|
||
40|| M4 | 风险事件管理 | 风险事件创建、状态流转、关联工单/推送/计划状态回写 |
|
||
41|| M5 | 风险审核 Admin | 人工复核弱关联风险、确认/排除诈骗、黑名单操作 |
|
||
42|| M6 | 对外 API Gateway | 供所有子系统查询风险状态、上报风险信号 |
|
||
43|
|
||
44|---
|
||
45|
|
||
46|## 2. 各模块内外说明
|
||
47|
|
||
48|### 2.1 M1: 关联判断引擎
|
||
49|
|
||
50|| 维度 | 说明 |
|
||
51|| --- | --- |
|
||
52|| **对内** | 每次风险信号进入时执行：8 项强关联维度（邮箱/设备号/电话/收件人姓名+地址/订单号/聊天记录/Profile ID/收款信息）→任一命中→高风险；3 项弱关联维度（IP单独/姓名单独/同址异名）→高风险观察+人工复核；判断结果：强关联/弱关联/无关联 |
|
||
53|| **对外接口** | `GET /api/risk/check/{person_id}` — 风险查询（含关联判断结果） |
|
||
54|| **数据写入** | `risk_signals` |
|
||
55|| **依赖** | `GET /api/identity/context/{person_id}` — 获取身份线索用于关联判断 |
|
||
56|| **关键规则** | 风险判断不是一次性，每次有效互动都要重做；非 APP 用户缺设备/注册邮箱等维度→风险识别能力下降 |
|
||
57|
|
||
58|### 2.2 M2: 黑名单管理
|
||
59|
|
||
60|| 维度 | 说明 |
|
||
61|| --- | --- |
|
||
62|| **对内** | 黑名单实体 CRUD（邮箱/设备/电话/地址/收款信息）；黑名单命中查询（任何子系统查询用户是否在黑名单）；黑名单同步（确认诈骗后同步到黑名单）；黑名单过期/申诉机制 |
|
||
63|| **对外接口** | `GET /api/risk/blacklist/check?type=EMAIL&value=xxx` — 黑名单命中检查 |
|
||
64|| **数据写入** | `blacklist_entities` |
|
||
65|| **待确认** | 黑名单是否有过期时间？申诉/移除流程？ |
|
||
66|
|
||
67|### 2.3 M3: 双重退款检测
|
||
68|
|
||
69|| 维度 | 说明 |
|
||
70|| --- | --- |
|
||
71|| **对内** | 采集 Amazon 退款记录（外部系统同步）+ OA 返款记录（财务系统同步）；按订单号/用户/金额/时间自动比对；匹配结果：无重复/疑似重复/确认重复；确认重复时强告警+阻止后续返款 |
|
||
72|| **对外接口** | `GET /api/risk/double-refund-check/{person_id}` — 双重退款检测 |
|
||
73|| **数据写入** | `refund_match_results` |
|
||
74|| **依赖** | Amazon 退款数据（外部）、OA 返款数据（外部财务系统） |
|
||
75|| **待确认** | Amazon 退款数据如何及时获取？OA 返款记录是否已有 API？ |
|
||
76|
|
||
77|### 2.4 M4: 风险事件管理
|
||
78|
|
||
79|| 维度 | 说明 |
|
||
80|| --- | --- |
|
||
81|| **对内** | 风险事件创建（客服上报疑似诈骗 / 双重退款检测 / 关联判断命中）；事件状态流转（待复核→复核中→确认风险/排除风险）；高风险链路动作（拦截继续推送/拦截自动退款/拦截自动放行）；回写关联工单/推送/计划状态 |
|
||
82|| **对外接口** | `POST /api/risk/report` — 上报风险信号（客服、系统自动均可调用） |
|
||
83|| **数据写入** | `risk_cases` |
|
||
84|
|
||
85|### 2.5 M5: 风险审核 Admin
|
||
86|
|
||
87|| 维度 | 说明 |
|
||
88|| --- | --- |
|
||
89|| **对内** | 人工复核弱关联风险；确认/排除诈骗判定；黑名单手动操作；风险口径维护 |
|
||
90|| **对外接口** | 管理 API |
|
||
91|| **待确认** | 复核时效要求？（N 分钟内必须复核？） |
|
||
92|
|
||
93|---
|
||
94|
|
||
95|## 3. 对外 API 契约（草案）
|
||
96|
|
||
97|| 接口 | 方法 | 输入 | 输出 | 消费者 |
|
||
98|| --- | --- | --- | --- | --- |
|
||
99|| 风险查询 | `GET /api/risk/check/{person_id}` | person_id | `{risk_level(NONE/WEAK/STRONG), signals[], cases[]}` | 所有子系统（每次互动时调用） |
|
||
100|| 上报风险信号 | `POST /api/risk/report` | `{person_id, signal_type, evidence, reported_by}` | `{signal_id}` | support（客服上报诈骗）、outreach（异常互动） |
|
||
101|| 黑名单命中 | `GET /api/risk/blacklist/check?type=&value=` | 维度类型+值 | `{hit, entity}` | outreach（发送前）、identity（身份归并时） |
|
||
102|| 双重退款检测 | `GET /api/risk/double-refund-check/{person_id}` | person_id | `{status, matched_refunds[]}` | outreach（返款前）、support（退款处理前） |
|
||
103|
|
||
104|---
|
||
105|
|
||
106|## 4. 数据对象
|
||
107|
|
||
108|| 对象 | 核心字段 | 说明 |
|
||
109|| --- | --- | --- |
|
||
110|| `risk_signals` | signal_id, person_id, signal_type, hit_dimensions[], risk_level(STRONG/WEAK), detected_at | 风险信号（每次互动生成的判断） |
|
||
111|| `risk_cases` | case_id, person_id, source, status(PENDING_REVIEW/REVIEWING/CONFIRMED_RISK/RULED_OUT), reviewer, created_at, resolved_at | 风险事件 |
|
||
112|| `blacklist_entities` | entity_id, entity_type(EMAIL/DEVICE/PHONE/ADDRESS/PAYMENT), entity_value, status(ACTIVE/EXPIRED/APPEALED), added_at, added_by | 黑名单实体 |
|
||
113|| `refund_match_results` | match_id, person_id, amazon_refund_id, oa_refund_id, match_status(NO_DUPLICATE/SUSPECTED/CONFIRMED), matched_at | 双重退款比对结果 |
|
||
114|
|
||
115|---
|
||
116|
|
||
117|## 5. 业务澄清问题清单 — risk
|
||
118|
|
||
119|### 5.1 强弱关联规则（4 项）
|
||
120|
|
||
121|| # | 问题 | 优先级 |
|
||
122|| --- | --- | --- |
|
||
123|| R-01 | 8 项强关联维度中，每个维度的命中是独立判断还是组合判断？（例如仅「设备号命中」是否就足够判定强关联？还是需要「设备号 + 电话」同时命中？） | **P0** |
|
||
124|| R-02 | 「强关联→直接进入高风险或黑名单链路」——这里的「直接」是指全自动化拦截无需人工确认？还是系统先拦截再人工审核？（涉及自动化力度） | **P0** |
|
||
125|| R-03 | 弱关联的「观察期」多长？观察期过后是自动解除还是必须人工确认？观察期内用户继续参与互动如何处理？ | P1 |
|
||
126|| R-04 | 风险判断中「IP 单独命中」列为弱关联——IP 从哪里获取？（JOYHUB APP？EDM 邮件头？客服系统？）不同来源的 IP 可靠性不同 | P1 |
|
||
127|
|
||
128|### 5.2 双重退款（4 项）
|
||
129|
|
||
130|| # | 问题 | 优先级 |
|
||
131|| --- | --- | --- |
|
||
132|| R-05 | Amazon 退款数据如何获取？（SP-API 实时拉取？T+1 同步？手动导入 CSV？）同步频率决定检测时效 | **P0** |
|
||
133|| R-06 | OA 返款系统是哪个？是否有 API？如果没有 API，返款记录怎么录入？（财务手动录入？CSV 导入？） | **P0** |
|
||
134|| R-07 | 「双重退款」比对的关键字段是什么？（订单号？金额？用户？时间窗口？）匹配精度？（金额完全相等还是 ±X%？时间窗口多宽？） | P1 |
|
||
135|| R-08 | 确认重复退款后，阻止后续返款——「阻止」是指系统自动拦截返款指令，还是只发告警让人工决定？ | P1 |
|
||
136|
|
||
137|### 5.3 黑名单管理（3 项）
|
||
138|
|
||
139|| # | 问题 | 优先级 |
|
||
140|| --- | --- | --- |
|
||
141|| R-09 | 黑名单是否有过期/申诉/解除机制？（例如用户被误标后如何申诉？谁有权解除？） | P1 |
|
||
142|| R-10 | 黑名单是否需要与外部系统同步？（例如 JOYHUB 的黑名单？Amazon 的欺诈标记？）同步方向？ | P1 |
|
||
143|| R-11 | 黑名单的粒度——是标记「真实人」还是「某个维度的值」？（标记的是真实人 ID 还是具体的邮箱/设备？） | P1 |
|
||
144|
|
||
145|### 5.4 风险可见性（3 项）
|
||
146|
|
||
147|| # | 问题 | 优先级 |
|
||
148|| --- | --- | --- |
|
||
149|| R-12 | 文档要求「客服、审核、退款等环节必须都能看到风险提醒」——风险提醒的展现形式是什么？（红色标签？弹窗？工单页顶部横幅？） | P1 |
|
||
150|| R-13 | 风险状态的「提醒」通过什么通道发送？（audit 通知中心？IM 消息？系统内消息？） | P1 |
|
||
151|| R-14 | 风险人员角色是否需要独立的风险控制台前端？该前端需要哪些功能？（事件列表/审核工作台/黑名单管理/统计报表？） | P2 |
|
||
152|
|
||
### 5.5 高级风险检测能力（4 项）
|
||
|
||
| # | 问题 | 优先级 |
|
||
| --- | --- | --- |
|
||
| R-15 | 是否需要行为速度检测？（同一真实人短时间内大量注册/大量申请退款/大量提交评价→触发异常行为告警？） | P1 |
|
||
| R-16 | 是否需要设备指纹/浏览器指纹？（识别同一设备换账号、模拟器、虚拟机等欺诈行为？） | P2 |
|
||
| R-17 | 是否需要地理位置异常检测？（同一账号短期内从不同国家/城市登录→触发告警？） | P2 |
|
||
| R-18 | 风险评分模型——是否需要一个综合风险分数（0-100）而非二元判断（强/弱/无）？评分模型的因子和权重？ | P1 |
|
||
|
||
### 5.6 风险事件处理流程（3 项）
|
||
|
||
| # | 问题 | 优先级 |
|
||
| --- | --- | --- |
|
||
| R-19 | 风险事件的优先级（P0/P1/P2）如何定义？（双重退款确认→P0？单次弱关联→P2？）不同优先级的响应 SLA？ | P1 |
|
||
| R-20 | 风险人员的工作台——是否需要「待审核队列」「审核中」「已处理」等看板视图？是否需要分配给具体审核人？ | P1 |
|
||
| R-21 | 同一个人短时间内触发多次风险信号——是每次生成新事件还是合并到已有事件？合并规则？ | P1 |
|
||
|
||
### 5.7 黑名单管理补充（3 项）
|
||
|
||
| # | 问题 | 优先级 |
|
||
| --- | --- | --- |
|
||
| R-22 | 黑名单的生效范围——加入黑名单后是「全系统拦截」还是「只拦截某些操作」？（是否还允许正常购买？只拦截测评参与？） | P1 |
|
||
| R-23 | 黑名单是否需要分级？（一级黑名单→全拦截 / 二级黑名单→降频+人工审核 / 三级黑名单→仅标记提醒） | P1 |
|
||
| R-24 | 黑名单是否需要与外部欺诈数据库同步？（如行业共享的欺诈黑名单？Amazon 的 abuse 标记？） | P2 |
|
||
|
||
### 5.8 非 APP 用户风险盲区（2 项）
|
||
|
||
| # | 问题 | 优先级 |
|
||
| --- | --- | --- |
|
||
| R-25 | 文档已明确「非 APP 用户识别能力下降」——是否需要额外的风控措施？（例如非 APP 用户的返款额度降低？首次返款必须人工审核？） | P1 |
|
||
| R-26 | 是否计划引导非 APP 用户注册 APP 以补全风险画像？（EDM/客服主动引导注册——注册转化跟踪？） | P2 |
|
||
|
||
### 5.9 实施层面（3 项）
|
||
|
||
| # | 问题 | 优先级 |
|
||
| --- | --- | --- |
|
||
| R-27 | 风险判断的实时性要求——每次互动时实时调用 risk API？（性能 overhead？需要缓存策略？） | P1 |
|
||
| R-28 | 双重退款检测的时效——Amazon 退款数据（外部）同步延迟 vs OA 返款实时——T+N 的延迟是否可接受？ | P1 |
|
||
| R-29 | 风险事件的数据保留策略？（已解决的诈骗案件数据保留多久？用于后续模型训练还是定期清理？） | P2 |
|