AI APP Scam Intervention：授权支付诈骗干预架构
APP scam intervention 不是一个更激进的 fraud stop button。它是一套实时支付决策架构：在客户本人已认证、正在授权 push payment 的情况下，识别其意图是否被 deception、coercion、impersonation、romance/investment grooming、remote-access coaching 或 mule networ
AI Authorized Push Payment / Scam Intervention Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_AUTHORIZED_PUSH_PAYMENT_SCAM_INTERVENTION_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
重要说明: 本文只讨论 AI scam intervention 的产品与架构设计，不构成法律、监管、赔付、客户通知、支付规则、可疑活动报告或模型验证结论。真实项目必须由 Legal、Compliance、Payments Legal、Fraud/Scam Operations、AML/BSA、Privacy、Cyber、Model Risk、Conduct Risk、Complaints、Branch/Contact Center、Payments Operations、Data Governance、Internal Audit 等共同确认。不同 payment rail、jurisdiction、账户协议、网络规则和机构政策会直接影响 hold、delay、decline、recall、reimburse、file report 或联系收款机构的边界。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| FTC scam alerts | https://consumer.ftc.gov/features/scam-alerts | 用 scam taxonomy、consumer education、impersonation/social-engineering patterns 和 recovery advice 训练客户保护场景；FTC 页面列出 phishing、gift card、government/business impersonator、romance、wire transfer 等常见 scam 类型（访问日期: 2026-07-01） |
| FTC impersonation rule blog | https://www.ftc.gov/business-guidance/blog/2024/02/ftc-impersonation-rule-goes-effect-april-1 | 用 government/business impersonation scam 语言设计 impersonation risk library、warning copy 和 scam operations typology；不要把本文写成该规则适用性结论（2024-02） |
| FFIEC Authentication and Access to Financial Institution Services and Systems | https://www.ffiec.gov/press/pr081121.htm | 用 risk assessment、layered security、MFA/equivalent controls、monitoring/logging/reporting、call center/help desk controls 和 push payment risk 思维设计 step-up authentication and intervention（2021-08） |
| FinCEN advisories/bulletins/fact sheets | https://www.fincen.gov/resources/advisoriesbulletinsfact-sheets | 用 financial crime typology、mule activity、elder financial exploitation、cyber-enabled fraud 和 reporting escalation 语言连接 fraud/scam operations 与 AML/BSA；正式报告义务由 BSA/AML and Legal 判断（持续更新的入口页，访问日期: 2026-07-01；近期相关：FIN-2025-NTC1 CVC kiosk scam notice 2025-08、FIN-2024-Alert004 deepfake alert 2024-11） |
| CFPB compliance circulars landing page | https://www.consumerfinance.gov/compliance/circulars/ | 用 consumer protection、complaints、servicing、payments and supervision guidance 的入口建立 complaints/remediation and conduct-risk review habit；不在本文作 reimbursement 或 liability 结论（访问日期: 2026-07-01） |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织 AI scam intervention 的 risk mapping、measurement、monitoring、governance 和 improvement evidence（访问日期: 2026-07-01） |
| ISO/IEC 42001 overview | https://www.iso.org/standard/42001 | 用 AI management system、roles、policy、operation、performance evaluation、internal audit 和 continual improvement 建立 AI scam intervention control plane（访问日期: 2026-07-01） |
核心导读
APP scam intervention 不是一个更激进的 fraud stop button。它是一套实时支付决策架构：在客户本人已认证、正在授权 push payment 的情况下，识别其意图是否被 deception、coercion、impersonation、romance/investment grooming、remote-access coaching 或 mule network 操控，并在支付窗口关闭前施加相称干预。系统价值不在于单纯提高拦截率，而在于把客户自主权、资金保护、证据留存、投诉可解释性、隐私边界和操作效率放进同一个控制面。
问题定义
Authorized Push Payment scam 的核心矛盾是：交易在技术上可能是 authorized，但客户意图可能已被诈骗者控制。传统 unauthorized fraud 主要问“是否有人盗用凭证或账户”；APP scam 还必须问“认证客户是否真正理解收款方、用途、不可逆性和替代解释，还是被实时指导、胁迫或诱导”。
金融零售场景的难点在于多个团队各看一段事实：digital banking 看到 session 和 device，payments team 看到 rail 和 settlement window，branch/call center 听到客户 narrative，fraud team 看 beneficiary graph，AML/BSA 关注 mule network，complaints team 事后处理客户损失。AI 架构必须把这些证据拼成同一条 customer journey，而不是把一笔转账孤立评分。
需要明确的四个 confidence：
| Confidence | 说明 | 不应混淆为 |
|---|---|---|
| Identity confidence | 发起人是否是授权客户或授权 business user | 客户未被操控 |
| Payment legitimacy confidence | rail、amount、timing、device、memo、beneficiary 是否符合支付语境 | 收款方可信 |
| Beneficiary confidence | 收款方是否为既有关系、真实商户、已验证 biller，或呈现 mule/pass-through 行为 | 客户意图真实 |
| Intent confidence | 客户是否理解交易对象、风险、不可逆性，是否可能被 coached to lie | AI 可读取心理状态 |
成熟设计必须承认 customer intent 不可直接观测。系统只能以弱信号、支付上下文、受益人网络、客户响应和人工访谈估计 intent confidence，并用不确定性驱动相称干预。
核心原理/方法
第一条原则是把 authentication 与 intent 分离。MFA、passkey、device binding 证明谁在操作，不证明为什么操作；APP scam 里客户本人通过强认证仍可能被骗子指导。
第二条原则是把风险表达为向量，而不是二元结论：
risk_vector =
identity_confidence
+ rail_irreversibility
+ beneficiary_mule_risk
+ customer_behavior_shift
+ social_engineering_signal
+ conversation_confidence
+ evidence_quality
第三条原则是把 intervention 设计成 ladder，而不是 blocking switch。干预可以是 contextual warning、payee confirmation、cooling-off、out-of-band callback、fraud specialist conversation、branch review、limit review、payment delay、case monitoring、post-payment recall/recovery。不同 rail 的可操作窗口不同，不能用一套 generic flow 处理 RTP、wire、ACH、P2P、bill pay、internal transfer 和 crypto on-ramp。
第四条原则是最小必要数据。可用数据应来自机构合法收集且目的明确的来源，例如 in-app payment memo、payee setup、客服 chat/call transcript、branch structured notes、客户主动提供的 scam message。不得默认扫描私人 SMS、email、社交媒体或设备内容；conversation/sentiment 信号只能作为风险提示，不能变成客户人格判断。
系统/架构模型
参考架构：
payment initiation / payee setup / limit increase
-> identity, device and session confidence
-> payment rail risk and intervention window
-> beneficiary and mule-risk graph
-> customer history, behavior shift and recent journey context
-> social-engineering signal layer
-> customer intent confidence model
-> proportional friction orchestration
-> branch / contact center / fraud specialist escalation
-> release / delay / decline / monitor / recall / case open
-> evidence ledger and complaint/remediation handoff
-> model, conduct, privacy and operational governance
关键组件：
| Component | 架构职责 |
|---|---|
| Rail-aware decision gate | 识别 RTP、wire、ACH、P2P、bill pay、internal transfer、crypto on-ramp 的 settlement、recall 和 delay 边界 |
| Beneficiary intelligence | 维护 payee relationship、alias stability、account age proxy、inbound/outbound velocity、known scam linkage、pass-through pattern |
| Intent-confidence layer | 融合客户陈述、urgency/secrecy、safe-account narrative、remote access、limit increase、warning response、story inconsistency |
| Typology-specific intervention | 针对 safe account、government impersonation、BEC、romance、investment、tech support、family emergency、marketplace scam 生成不同 friction |
| Frontline orchestration | 把 branch 和 call center 纳入同一 evidence chain，提供 structured interview 和 supervisor escalation |
| Recovery loop | post-payment recall、receiving institution contact、mule graph update、complaint case linkage |
| Governance cockpit | 监控 false friction、loss prevented、complaints、override、model drift、privacy use、conduct harm |
关键机制与取舍
Scam taxonomy 应按 manipulation pattern 和支付后果分类，而不是只按 rail 分类。
| Typology | 核心操控 | 支付行为 | 干预重点 |
|---|---|---|---|
| Government / law enforcement impersonation | 威胁逮捕、罚款、税务或移民后果，要求保密 | wire、P2P、cash、gift card、crypto | 明确说明真实机构不会要求转钱或保密 |
| Bank / safe account impersonation | 冒充银行 fraud team，要求转到安全账户 | new beneficiary、internal/external transfer、wire | out-of-band callback，阻断来电方脚本 |
| BEC / invoice redirection | 假冒 vendor、executive、closing agent 改变收款信息 | ACH credit、wire、business online banking | known-good callback，dual approval，beneficiary change evidence |
| Romance / relationship scam | 长期 grooming 和情感依赖 | escalating wires、P2P、crypto | longitudinal pattern，非羞辱式专员沟通 |
| Investment / crypto scam | 保证收益、fake platform、withdrawal fee | crypto on-ramp、repeated top-ups | investment warning，cooling-off，platform/beneficiary risk |
| Tech support / remote access | 诱导远控、退款骗局、错误转账 | bill pay、P2P、wire、gift card | remote-access signal，device/session review |
| Mule recruitment | money flipping、收转资金 | inbound credits 后 rapid outbound | customer protection 与 AML escalation 同时存在 |
主要取舍：
| Decision | 低成熟做法 | 高成熟做法 |
|---|---|---|
| 风险评分位置 | 只在 send button 评分 | payee setup、limit increase、payment initiation、pre-settlement、post-payment 多点评分 |
| 意图表达 | scam / not scam | confidence vector + reason codes + evidence quality |
| 受益人风险 | new payee 即高风险 | relationship、verification、network、velocity、alias stability、mule cluster 综合判断 |
| 干预强度 | 高分直接拒绝 | contextual warning、cooling-off、callback、specialist、delay/decline 按 policy 升级 |
| 人工升级 | 全部丢给 fraud queue | 根据 rail urgency、typology、amount、vulnerability、evidence 路由 |
| 模型反馈 | 只用 confirmed losses | 加入 prevented scam、complaint、analyst label、recovery feedback、receiving bank signal |
证据与控制
APP scam 的证据要能回答事后争议：客户看到了什么警示、说了什么、员工如何判断、模型当时的理由是什么、支付窗口是否已关闭、是否尝试 recovery。证据不完整时，模型再准也会在投诉、审计和模型改进中失去价值。
核心 evidence ledger：
case_id
payment_id / rail / channel / amount / timestamp
customer_id / segment / vulnerability flag where policy-approved
identity and session signals
beneficiary_id / alias / verification / mule graph reference
scam typology candidates and confidence
risk vector, model version, reason codes
warning/intervention content version
customer response and interaction transcript or structured notes
frontline user id, role, decision timestamp
decision owner and override reason
final payment outcome
recall/recovery actions
complaint/remediation status
model feedback label and evidence quality score
控制矩阵：
| Control objective | Control activity | Evidence |
|---|---|---|
| 区分认证和意图 | decision schema 分离 identity confidence 与 intent confidence | model schema、risk vector、decision log |
| 识别 mule/beneficiary risk | graph 使用 account age、relationship、velocity、network、case outcomes | beneficiary risk card、graph score、lineage |
| 相称干预 | friction engine 将 risk reason 映射 warning、delay、callback、branch review | decision table、UX version、event log |
| 保护自主权 | 高风险干预提供原因、复核或升级路径 | customer communication、override reason、escalation notes |
| 控制隐私边界 | conversation/device/third-party signals 有 approved purpose、retention、access | privacy assessment、data catalog、access logs |
| 管理模型风险 | validation、calibration、drift、challenger、override review | model inventory、validation report、monitoring dashboard |
| 管理 conduct risk | false friction、complaints、vulnerable impact、demographic proxies where permitted | conduct review pack、complaint trends、remediation log |
| 闭环 recovery | post-payment case 触发 recall 和 mule intelligence update | recovery ticket、receiving bank contact、graph update |
指标不能只看 loss prevented。还应看 false friction rate、legitimate payment delay、customer intent reversal rate、escalation conversion、recovery speed、mule precision、override reason、complaint rate、vulnerable-customer escalation quality 和 evidence completeness。
金融零售/AI产品场景
- Real-time payment 高额新收款方：系统在 payee setup 和 payment initiation 两次评分，发现 safe-account narrative 与受益人 mule risk；客户看到明确警示，并进入 callback 或 fraud specialist。
- Branch wire：banker 使用 structured interview 捕捉 urgency、secrecy、remote coaching 和客户 narrative 变化；证据进入 wire decision 和后续 complaint file。
- Small business BEC：供应商收款账户变更触发 known-good contact verification、dual approval 和 evidence packet，AI 只总结差异和缺口，不自行确认真实性。
- Romance/investment grooming：单笔转账可能不异常，但 longitudinal graph 显示 escalating payments、crypto on-ramp 和 repeated top-ups；系统使用 cooling-off 与专员沟通，避免羞辱客户。
- Contact center scam call：客户被骗子实时指导，回答高度脚本化；AI 将 emotion/coaching 作为弱信号，触发 safe pause，而不是给客户贴标签。
- Post-payment complaint：客户事后称银行没有充分警示；complaints team 可重放 risk vector、warning copy、customer response、decision owner 和 recovery attempt。
反模式
| 反模式 | 风险 | 更好的边界 |
|---|---|---|
| 把 MFA 当 scam control | MFA 只证明操作者，不证明意图 | intent confidence 与 social-engineering layer |
| 高风险转账一律拒绝 | liquidity harm、business disruption、投诉和自主权损害 | 相称 friction 与 policy-based escalation |
| 到处弹 generic warning | 客户疲劳，高风险客户继续被骗子操控 | typology-specific, action-oriented warning |
| 私人通信过度扫描 | 隐私、目的限制、信任风险 | approved sources、最小必要、access control |
| 只训练 confirmed loss | label bias，忽略 prevented scam 和未投诉客户 | 多源 label 和 evidence-quality feedback |
| 忽略 beneficiary graph | 只看 sender anomaly 会漏 mule network | payee lifecycle 与 mule intelligence |
| 前线自由文本记录 | 难以复盘、训练和审计 | structured interview + controlled narrative |
| 赔付话术提前承诺 | 越权且可能与规则/事实不符 | remediation 由 Legal/Compliance/Complaints 流程决定 |
最终心智模型
APP scam 架构的本质不是“更聪明地拦截付款”，而是建立一个能在极短时间内区分认证、意图、受益人、rail window 和社会工程风险的 intervention control plane。一个成熟系统应能证明：客户本人发起高风险 push payment 时，机构看见了哪些信号，为什么选择某种 friction，客户和员工如何响应，支付如何处理，事后如何 recovery 和投诉复盘，以及模型如何在不越过隐私和客户自主权边界的前提下持续改进。
SOTA 检查 (2026-07-01)
- 英国已把本篇的 recovery loop / receiving-institution 责任变成强制赔付制度：UK PSR 强制 APP 赔付 regime 自 2024-10-07 生效（受害者 5 个工作日内赔付、最长 35 个工作日出结论、sending/receiving PSP 50:50 分摊），2025-05 以 PS25/5 合并政策声明固化，PSR 计划 2026 年发布 post-implementation review。本篇“recall/recovery + mule intelligence + receiving bank contact”不再只是最佳实践，而是英国市场的合规基线。
- 欧元区已把本篇的 beneficiary confirmation 变成法定基线：EU Instant Payments Regulation 下的 Verification of Payee（IBAN-姓名核验）自 2025-10-09 起对全部欧元区 PSP 强制（非欧元区 PSP 截止 2027-07-09）。本篇干预阶梯中的 “payee confirmation” 在欧元区已是免费法定服务，架构上应视为默认存在的上游信号而非可选 friction。
- EU PSD3/PSR 走向 APP 赔付常态化：2025-11-27 欧洲议会与理事会就 PSD3/PSR 达成临时政治协议，impersonation/APP fraud 赔付被常态化，且 PSP 未提示 payee 姓名/标识符不匹配将承担责任——本篇“evidence ledger 要能回答客户看到了什么警示”的设计正好是这类责任争议的举证载体。
- 美国侧仍以 typology 通告 + 立法压力推进而非强制赔付：FinCEN 2025-08-04 发布 FIN-2025-NTC1（CVC kiosk scam payments，覆盖 tech support / bank imposter typology），此前 FIN-2024-Alert004（2024-11）针对 deepfake 欺诈；2025 年前 9 个月美国 P2P 平台（Zelle 等）scam 损失 $373.6M、同比增约 35%，国会 2025 年多次向 Zelle 股东行发函并提出 TRAPS Act（2025-06）。本篇 crypto on-ramp typology 与 rail-aware decision gate 在美国语境下仍是现役重点。
- 模型层在换代，控制面结论不过时：2025 年行业报道（如 Mastercard 称嵌入 generative AI 后检测率最高提升 300%）表明检测模型迭代很快，但本篇的框架性结论——authentication 与 intent 分离、risk vector 而非二元评分、rail-aware 干预阶梯、最小必要数据、evidence ledger 与 conduct/privacy 治理——不随模型版本过时；换掉打分模型不需要改控制面。mule/beneficiary graph 的实现深化可交叉参考本库
docs/aipa/day68-mule-graph.md（AIPA D68 笔记），操作手册版见文首配对阅读的 playbook。