197 lines
7.1 KiB
Markdown
197 lines
7.1 KiB
Markdown
---
|
|
title: prop-acc · prepaid · 场景 - 疑似欺诈风控冻结
|
|
aliases:
|
|
- 冻结预存款账户
|
|
- 风控冻结
|
|
- freeze-suspected-fraud
|
|
- 场景-预存款风控冻结
|
|
tags:
|
|
- 场景
|
|
- prop-acc
|
|
- 预存款
|
|
- 冻结
|
|
audience:
|
|
- 业务人员
|
|
- 风控
|
|
status: 已发布
|
|
sub_feature: prepaid
|
|
last_review: 2026-05-25
|
|
code_version: 2026-05-22
|
|
---
|
|
|
|
# 场景:疑似欺诈风控冻结
|
|
|
|
物业财务 / 风控发现某预存款账户**有可疑迹象**(短时间大额充值、与其他账户关联异常、业户身份疑问等),先冻结账户,禁止任何资金动作,核实后再决定解冻或关账。
|
|
|
|
## 典型情境
|
|
|
|
> [!example] 真实情境
|
|
> 平台风控系统发现:
|
|
>
|
|
> - **王女士**(15-7-203)预存款账户**昨天充了 ¥50,000**(往常月充值 < ¥3,000)
|
|
> - 同时,该业户绑定的微信号**昨天给 3 个不同预存款账户**各转了 ¥10,000-¥20,000(不像本人正常操作)
|
|
> - 业户报备的手机号**昨天突然变更**
|
|
>
|
|
> 风控团队判断:**疑似账户被盗 / 洗钱嫌疑**。先**冻结**所有相关账户,联系业户核实。
|
|
|
|
## 业务人员视角(风控 + 财务)
|
|
|
|
### 第 1 步:风控触发
|
|
|
|
风控团队识别异常 → 通知物业财务 → 财务在系统层立即冻结。
|
|
|
|
### 第 2 步:打开账户
|
|
|
|
后台 → 预存款 → 找到王女士账户(Active,balance=50000+原余额)→ 进 `ViewPrepaidAccount`。
|
|
|
|
### 第 3 步:点击 `FreezeAccountAction`(标签"冻结")
|
|
|
|
> [!warning] 按钮可见性
|
|
> 守护:`canBeFreezed()`(等价 Active)+ Policy `->authorize('freeze')`。Frozen / Closed 灰化。
|
|
|
|
Modal 表单:
|
|
|
|
| 字段 | 填什么 |
|
|
|---|---|
|
|
| **冻结事由(reason)** | **必填且详细**,如 "风控:24h 内大额异常充值 + 微信关联多账户 + 手机号变更,疑似账户被盗" |
|
|
|
|
### 第 4 步:提交
|
|
|
|
系统调 `PrepaidAccount::freeze($reason)`:
|
|
|
|
1. 校验 `canBeFreezed()`(Active only)
|
|
2. 更新 `status=Frozen`
|
|
3. 在 `meta.freeze_reason` 记冻结事由
|
|
4. 在 `meta.frozen_at` 记冻结时间
|
|
|
|
**不产生** `PrepaidTransaction`、**不产生** `CollectionOrder`、**不产生** `Receipt`(纯状态变更)。
|
|
|
|
### 第 5 步:通知 + 调查
|
|
|
|
- 通知业户:"您的预存款账户已冻结,事由 XXX,请联系物业核实身份"
|
|
- 联系业户本人(已知手机号 + 业户备用联系方式),核实近期操作是否本人
|
|
- 如果是本人 → 解释 + 解冻;如果不是本人 → 走风控 / 法务流程
|
|
|
|
## 业户视角
|
|
|
|
### 您会感受到什么
|
|
|
|
- 收到通知:"您的预存款账户已冻结,事由:风控异常,请联系物业核实"
|
|
- 小程序"我的预存款"显示 "🧊 冻结"
|
|
- 想充值 → 失败,提示"账户冻结"
|
|
- 想抵账单 → 失败,提示"账户冻结"
|
|
- 想退款 → 失败,提示"账户冻结"
|
|
- 余额仍可见(只读)
|
|
|
|
### 您要做什么
|
|
|
|
立即联系物业(电话 / 微信 / 上门),核实:
|
|
|
|
- 近期充值 / 退款是不是您本人操作
|
|
- 手机号变更是不是您本人申请
|
|
- 提供身份证 / 房产证等核实身份
|
|
|
|
| 核实结果 | 后续 |
|
|
|---|---|
|
|
| 是本人,正常操作 | 物业解冻,详见 [[unfreeze-after-verification]] |
|
|
| 不是本人(账户被盗 / 微信号被盗)| 走风控流程,可能 retain 账户等司法处理 |
|
|
| 不是本人(他人冒充)| 走法务流程,资金可能扣留待裁决 |
|
|
|
|
## 系统流程
|
|
|
|
```mermaid
|
|
sequenceDiagram
|
|
participant 风控
|
|
participant 财务
|
|
participant Filament
|
|
participant PrepaidAccount
|
|
participant 数据库
|
|
participant 业户
|
|
|
|
Note over 风控: 检测异常充值 + 关联微信号
|
|
|
|
风控->>财务: 告警,要求冻结王女士账户
|
|
财务->>Filament: ViewPrepaidAccount → FreezeAccountAction(reason)
|
|
Filament->>PrepaidAccount: freeze(reason)
|
|
PrepaidAccount->>PrepaidAccount: canBeFreezed()? Active=true
|
|
PrepaidAccount->>数据库: 更新 status=Frozen, meta.freeze_reason, meta.frozen_at
|
|
数据库-->>财务: ok
|
|
Filament-->>财务: 成功
|
|
|
|
Note over 数据库: 冻结期间所有 deposit/consume/refund 调用都拦截
|
|
|
|
财务->>业户: 通知冻结 + 要求核实
|
|
```
|
|
|
|
## 冻结期间的能力对照
|
|
|
|
| 操作 | Active | Frozen |
|
|
|---|---|---|
|
|
| `DepositAction`(充值)| ✅ | ❌(`canOperate=false`)|
|
|
| `ConsumeAction`(消费抵扣)| ✅ | ❌ |
|
|
| `RefundAction`(退款)| ✅ | ❌ |
|
|
| `FreezeAccountAction`(冻结)| ✅ | ❌(已是 Frozen)|
|
|
| `ReactivateAccountAction`(解冻)| ❌(已是 Active)| ✅ |
|
|
| `CloseAccountAction`(关账)| ✅(balance=0)| ❌(必须先解冻)|
|
|
| 看账户 / 看流水 | ✅ | ✅(只读)|
|
|
|
|
> [!info] 与 deposit 关键差异:**没有 ForceClose**
|
|
> deposit 在 Frozen + 有余额困境时可以走 ForceClose(refund/forfeit/retain 三种 disposition)直接关账。**prepaid 没有这条路径** —— 一户一账 + 业户基本是本人,纠纷场景罕见,设计上简化。
|
|
>
|
|
> 真要"关 Frozen 账户":
|
|
> 1. 先 [[unfreeze-after-verification|解冻]] 回 Active
|
|
> 2. 再退余 + 关账
|
|
> 3. 如果完全不能解冻(业户被司法冻结之类),账户**一直留 Frozen**,运维介入
|
|
|
|
## 真实情境(二):月初批量自动抵扣误冻
|
|
|
|
> [!example] 反例:误冻结
|
|
> 风控系统某次误报,把正常业户王女士的账户冻结了。月初自动抵扣 job 跑到她账户时,因 Frozen 跳过,她的物业费没扣。
|
|
>
|
|
> 业户次月发现欠费,投诉。物业核实是误冻,立即 [[unfreeze-after-verification|解冻]],手动 ConsumeAction 补抵账单。
|
|
|
|
误冻的代价比 deposit 大,因为 prepaid 是**业户日常用的钱包**,误冻一天就让业户感觉服务出问题。**冻结前务必充分判断**。
|
|
|
|
## 常见问题
|
|
|
|
> [!question] 冻结期间业户能查询余额吗?
|
|
> 能。只读。可以看到余额、流水、状态(Frozen)、冻结事由。
|
|
|
|
> [!question] 冻结后业务人员可以做什么?
|
|
> - 看账户和流水(只读)
|
|
> - 走 `ReactivateAccountAction` 解冻
|
|
> - 不能充值 / 消费 / 退款(全部按钮灰)
|
|
> - 不能关账(必须先解冻)
|
|
> - **不能 ForceClose**(prepaid 没这功能)
|
|
|
|
> [!question] 风控应该多严?误报代价大不大?
|
|
> 误报代价:
|
|
> - 业户感知 = 服务异常 = 投诉
|
|
> - 业务人员介入解释 + 解冻 = 工作量
|
|
> - 严重影响信任
|
|
>
|
|
> 漏报代价:
|
|
> - 真欺诈未拦截 = 资金损失 / 法律风险
|
|
>
|
|
> **建议**:风控规则宽严平衡,人工审核 + 紧急冻结。冻结前优先**主动联系业户核实**,确认异常再冻。
|
|
|
|
> [!question] 业户失联或不配合核实怎么办?
|
|
> 长期 Frozen 状态保留。资金留在账户(`balance`),业户出现可解冻。**prepaid 没有 retain 机制**,长期失联走业务流程(类似 deposit retain,运维 / 法务介入)。
|
|
|
|
> [!question] 冻结期间业户能在小程序看到原因吗?
|
|
> 看 UI 设计。**推荐** 在小程序的"账户状态"页显示 `meta.freeze_reason` 的对外友好版本(去掉技术细节,如"账户冻结中,请联系物业了解详情")。
|
|
|
|
## 异常分支
|
|
|
|
- 误冻 → 立即 [[unfreeze-after-verification|解冻]]
|
|
- 核实后正常 → [[unfreeze-after-verification|解冻]] → 继续用
|
|
- 核实后确认被盗 / 欺诈 → 走法务流程,资金可能 retain 等司法
|
|
- 业户已失联 → 留 Frozen,等业户出现
|
|
|
|
## 相关文档
|
|
|
|
- [[account-state-machine]]
|
|
- [[unfreeze-after-verification]]
|
|
- [[exception-refund-on-frozen]]
|
|
- [[../deposit/freeze-during-dispute]](deposit 冻结场景对比)
|