7.1 KiB
title, aliases, tags, audience, status, sub_feature, last_review, code_version
| title | aliases | tags | audience | status | sub_feature | last_review | code_version | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| prop-acc · prepaid · 场景 - 疑似欺诈风控冻结 |
|
|
|
已发布 | prepaid | 2026-05-25 | 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):
- 校验
canBeFreezed()(Active only) - 更新
status=Frozen - 在
meta.freeze_reason记冻结事由 - 在
meta.frozen_at记冻结时间
不产生 PrepaidTransaction、不产生 CollectionOrder、不产生 Receipt(纯状态变更)。
第 5 步:通知 + 调查
- 通知业户:"您的预存款账户已冻结,事由 XXX,请联系物业核实身份"
- 联系业户本人(已知手机号 + 业户备用联系方式),核实近期操作是否本人
- 如果是本人 → 解释 + 解冻;如果不是本人 → 走风控 / 法务流程
业户视角
您会感受到什么
- 收到通知:"您的预存款账户已冻结,事由:风控异常,请联系物业核实"
- 小程序"我的预存款"显示 "🧊 冻结"
- 想充值 → 失败,提示"账户冻结"
- 想抵账单 → 失败,提示"账户冻结"
- 想退款 → 失败,提示"账户冻结"
- 余额仍可见(只读)
您要做什么
立即联系物业(电话 / 微信 / 上门),核实:
- 近期充值 / 退款是不是您本人操作
- 手机号变更是不是您本人申请
- 提供身份证 / 房产证等核实身份
| 核实结果 | 后续 |
|---|---|
| 是本人,正常操作 | 物业解冻,详见 unfreeze-after-verification |
| 不是本人(账户被盗 / 微信号被盗) | 走风控流程,可能 retain 账户等司法处理 |
| 不是本人(他人冒充) | 走法务流程,资金可能扣留待裁决 |
系统流程
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 账户":
- 先 unfreeze-after-verification 回 Active
- 再退余 + 关账
- 如果完全不能解冻(业户被司法冻结之类),账户一直留 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,等业户出现