AI Authorized Push Payment / Scam Intervention Architecture Playbook

定位: 面向 Advanced AI PM、CBAP Senior BA、AI Product Architect、Enterprise Architect、Fraud/Scam Operations、Payments Product、Branch and Contact Center Operations、Model Risk、Conduct Risk、Privacy、Compliance、AML/BSA、Complaints、Internal Audit 和金融零售业务 owner。本文不是基础反欺诈材料, 而是训练你把 authorized push payment scam 从“客户自己转账”提升为 real-time customer protection architecture、AI decisioning、payment rail intervention、frontline operating model、evidence and remediation capability。

核心判断:

The bank should not treat every authorized push payment as valid intent, and should not treat every high-risk payment as fraud. The architecture challenge is to estimate scam-induced intent loss, intervene proportionally, preserve customer autonomy, and prove the decision later.

---

0. Disclaimer

本文是学习、架构训练和作品集材料, 不构成法律意见、监管意见、合规结论、消费者赔付建议、客户通知建议、支付网络规则解释、可疑活动报告建议、模型验证意见或具体机构政策建议。

正式项目必须由 Legal、Compliance、Payments Legal、Fraud/Scam Operations、AML/BSA、Privacy、Cyber、Model Risk、Conduct Risk、Complaints、Payments Operations、Branch/Contact Center、Product Owner、Data Governance、Third-Party Risk、Internal Audit 和必要的外部顾问共同判断。

不同 payment rail、account agreement、network rule、state/federal/international law、客户类型、business/consumer status、jurisdiction、transaction facts、complaint record、evidence quality、receiving institution response 和机构政策都会影响是否能 hold、delay、decline、recall、reimburse、close account、file report 或联系第三方。本文避免作任何 jurisdiction-specific reimbursement claim。Remediation and reimbursement must be determined by Legal/Compliance/Complaints under applicable facts and policy。

---

1. Executive Framing

APP scam 是金融零售 AI 的高难度场景, 因为它处在三个边界交叉处:

• Payments velocity: 客户需要快速转账, 诈骗也依赖快速转走。
• Customer autonomy: 客户确实登录、认证、点击并授权, 但可能被操控。
• Institution duty and conduct risk: 机构不能简单袖手旁观, 也不能用粗暴拦截替代客户决策。

高级 PM / Architect 要把问题从 "build a scam model" 改写为:

How do we design a real-time intervention system that detects scam-induced authorization,
applies the least harmful effective friction,
routes complex cases to trained humans,
preserves evidence for complaints and remediation,
feeds mule intelligence back into financial crime operations,
and remains governed under model, conduct and privacy controls?

Executive one-liner:

APP scam control is a customer-protection decision system, not merely a fraud classifier.

Board / executive concerns:

---

2. Source Anchors

Source nuance:

• FTC scam alerts 是 typology and education anchor, 不是金融机构具体赔付义务结论。
• FFIEC authentication guidance 强调 authentication and access risk management, layered security and monitoring；APP scam 需要在此基础上增加 intent and social-engineering layer。
• FinCEN anchors 对 mule and suspicious activity awareness 有价值, 但报告义务、时点和内容由 BSA/AML and Legal 判断。
• CFPB guidance/circulars landing page 用于培养 consumer protection and complaints discipline, 不应被本文当作某一 APP scam reimbursement rule。
• NIST AI RMF and ISO/IEC 42001 提供 AI governance language, 不是单个模型的 pass/fail checklist。

---

3. Scam Taxonomy

Playbook taxonomy 要能直接驱动 intervention, not just reporting。

Taxonomy design requirements:

• Allow multi-label cases. A romance scam can become crypto investment scam。
• Capture scam stage: grooming, payee setup, first payment, repeated payment, recovery fee, complaint。
• Capture pressure signal: urgency, secrecy, authority, shame, love/trust, greed/FOMO, fear, remote control。
• Capture payment consequence: immediate loss, delayed settlement, recoverable window, mule cluster, complaint。

---

4. Payment Rail and Intervention Map

Rail-aware design questions:

• What is the last point where friction can still prevent loss?
• What delay/hold/decline authority exists under product terms and network rules?
• What recovery channel exists post-send, and who owns it?
• What does the customer expect in this rail, and what friction will feel legitimate?
• What evidence is needed if the customer later complains?

---

5. Decision Gates

Gate 0: Use Case and Risk Tier

Purpose: decide which payment journeys need APP scam controls before launch。

Output: Scam Control Tier, required evidence objects, required intervention ladder, model inventory entry。

Gate 1: Beneficiary / Payee Onboarding

Purpose: stop risky destination setup before payment urgency peaks。

Controls:

• New payee risk scoring。
• Name/alias/account consistency where available。
• Beneficiary graph lookup。
• Known vendor/merchant/biller directory match。
• Account change verification for business payments。
• First-payment delay or enhanced warning where policy allows。

Gate decision:

Gate 2: Payment Initiation

Purpose: combine transaction, session, rail and customer history。

Signals:

• Amount relative to customer baseline。
• First payment to beneficiary。
• Rail risk and settlement speed。
• Device/session anomalies and remote-access indicators where allowed。
• Recent limit increase, failed attempts, repeated edits, split payments。
• Recent calls/chats/branch visits/complaints。
• Customer segment and vulnerability flags only where policy-approved。

Output: risk vector with reason codes, not just score。

Gate 3: Customer Intent Confidence

Purpose: estimate whether authorization reflects informed and independent intent。

Intent checks:

Architecture output: intent_confidence = high / medium / low / unknown, with uncertainty and reason codes。

Gate 4: Step-Up Friction

Purpose: choose least harmful effective friction。

Friction quality rules:

• Be specific about the scam pattern。
• Avoid blame and shame。
• Do not disclose sensitive model logic or mule intelligence。
• Offer a safe pause。
• Preserve customer response。
• Provide escalation route。

Gate 5: Human Escalation

Purpose: use branch/call center judgment without unstructured inconsistency。

Escalation routing:

Structured interview questions:

• Who told you to make this payment?
• How did you verify the person or company independently?
• Are you currently on the phone/chat with anyone about this payment?
• Did anyone tell you not to tell the bank, your family, or colleagues?
• Did anyone ask you to say the payment is for a different purpose?
• Do you understand this payment may be difficult or impossible to recover after it is sent?
• Would you be willing to pause and call the organization using a number you find independently?

Gate 6: Release / Delay / Hold / Decline / Monitor

Purpose: make accountable payment decision。

Decision record must include:

• risk vector and model version。
• payment rail and intervention window。
• customer response and evidence。
• decision owner and authority。
• Legal/Compliance consultation if required。
• final action and customer communication。
• recovery path if payment proceeds。

No architecture document should hard-code universal authority to delay or refuse payments. That authority is product-, rail-, contract-, law-, and policy-dependent。

Gate 7: Post-Payment Recovery and Complaint

Purpose: once payment leaves, speed and evidence matter。

Actions:

• Initiate recall/recovery workflow immediately where available。
• Contact receiving institution through approved channel。
• Open complaint/remediation case if customer alleges scam or inadequate warning。
• Preserve intervention evidence and final customer-visible content。
• Update mule graph and beneficiary risk。
• Feed outcome to model labels after quality review。
• Review whether customer is at risk of repeat targeting。

---

6. Artifact Set

---

7. RACI / Operating Model

Decision rights:

RACI:

Governance cadence:

---

8. Implementation Roadmap

Phase 1: 0-30 Days, Foundation

Phase 2: 31-60 Days, MVP Controls

Phase 3: 61-90 Days, AI Decisioning

Phase 4: 91-180 Days, Scale and Control

---

9. Evidence Pack

Evidence pack should prove what happened, why intervention occurred, what the customer saw/heard, who decided, and how the outcome was handled。

Minimum evidence fields:

Evidence quality scoring:

Replay package:

customer payment context
authentication and session evidence
beneficiary risk card
payment rail intervention window
AI risk vector and reason codes
warning or friction shown
customer response
frontline structured interview
decision owner and action
payment settlement/recovery outcome
complaint/remediation outcome
model feedback label

---

10. Model Risk and AI Governance

Model inventory fields:

Validation questions:

• Does the model separate identity confidence from intent confidence?
• Does it over-score new payees in ways that harm legitimate life events, small businesses or immigrant remittances?
• Are labels biased toward customers who complain or high-value losses only?
• Does conversation analytics rely on approved data sources?
• Do reason codes support operations without leaking control logic to scammers?
• Are thresholds validated by rail, channel, amount band, customer segment and typology?
• Can analysts override, and are overrides monitored?
• Is there challenger analysis against simpler rules and human-only review?
• Is drift monitored after scam typology changes?

NIST AI RMF mapping:

ISO/IEC 42001 mapping:

---

11. Privacy and Conduct Boundaries

Privacy design principles:

• Use minimum necessary data for scam intervention。
• Make data source, purpose, retention and access explicit。
• Prefer structured customer-provided answers over covert inference。
• Separate customer protection analytics from marketing or unrelated profiling。
• Treat call/chat transcripts as sensitive operational records。
• Review third-party mule/beneficiary intelligence for permissible use and sharing limits。
• Avoid storing scammer-provided screenshots longer than necessary without retention review。

Data boundary table:

Conduct risk tests:

• Would a reasonable customer understand why friction occurred?
• Are warnings accurate, specific and non-shaming?
• Are certain customer groups experiencing excessive delay or false declines?
• Does the process allow a legitimate urgent payment to escalate efficiently?
• Are vulnerable customers supported without stripping agency?
• Are complaint outcomes feeding back into design?
• Are employees trained not to accuse customers of lying or being complicit without evidence?

---

12. Branch and Call Center Playbook

Frontline objective:

Create a safe pause, test independent intent, capture evidence,
and route the payment decision through the right authority.

Do:

• Speak calmly and specifically。
• Ask if anyone is on the phone/chat or remote session。
• Ask how the customer independently verified the recipient。
• Explain payment irreversibility in plain language。
• Offer an independent callback or pause。
• Escalate high-risk patterns to fraud specialist or supervisor。
• Record exact questions and answers。
• Preserve customer dignity。

Do not:

• Shame the customer。
• Argue about whether the customer is "being scammed"。
• Promise reimbursement or legal outcome。
• Reveal mule intelligence details。
• Let a customer-provided phone number be the verification channel。
• Use free-text speculation such as "customer is lying"。
• Ignore coached story changes。

Structured note template:

Scam typology suspected:
Payment rail and amount:
Beneficiary:
Customer stated purpose:
Independent verification method:
Urgency/secrecy/coaching indicators:
Active phone/chat/remote access:
Warning provided:
Customer response:
Escalation:
Decision owner:
Outcome:
Evidence gaps:

Quality assurance:

---

13. Complaints and Remediation Workflow

Complaints workflow should be designed before losses occur。

Intake questions:

• What payment was sent, through which rail, and when?
• What scam story does the customer report?
• Did the customer receive warnings or speak with staff before sending?
• What did the customer see and acknowledge?
• Was there a hold, delay, override or release decision?
• Were recovery attempts initiated quickly?
• Is there receiving institution evidence?
• Is the customer at risk of repeat targeting?

Workflow:

complaint intake
  -> payment and intervention evidence retrieval
  -> scam typology classification
  -> recovery status check
  -> legal/compliance/policy review
  -> customer communication
  -> remediation decision by authorized owner
  -> model label update after QA
  -> CAPA if control weakness found

Remediation review dimensions:

Do not put reimbursement outcomes in the playbook as universal promises. Use "authorized remediation owner decides under policy and facts"。

---

14. Metrics and KRIs

Executive dashboard:

KRIs:

Metric anti-gaming:

• Do not count every abandoned high-risk payment as prevented scam without sampling/QA。
• Do not optimize only loss prevention; include legitimate payment delay and complaint harm。
• Do not hide false declines as "customer chose not to proceed" when friction design caused confusion。
• Do not retrain only on confirmed fraud losses; include prevented and legitimate labels。

---

15. Checklists

Product Design Checklist

Model Risk Checklist

Operations Checklist

Privacy and Conduct Checklist

---

16. Anti-Patterns

---

17. Tabletop Scenarios

Scenario 1: Safe Account Scam on Instant Rail

A customer attempts a high-value instant payment to a new beneficiary.
The payment memo says "safe account". The customer passed MFA and says the bank fraud department called them.
They are still on a phone call during the transfer.

Expected actions: safe-account warning, ask active call/coaching questions, independent bank callback, fraud specialist escalation, decision record, potential delay/hold/decline under policy, evidence preservation。

Scenario 2: Branch Wire with Coached Customer

An older customer visits a branch to send a wire overseas.
They appear anxious, say it is for a real estate investment, and refuse to provide documents.
The beneficiary was added that morning.

Expected actions: non-shaming conversation, investment/romance typology questions, supervisor escalation, beneficiary risk card, wire room review, customer pause, structured notes。

Scenario 3: Business Email Compromise

A small business user changes a vendor account and submits an ACH credit file.
The email thread approving the change came from a lookalike domain.
Dual approval occurred, but no known-good callback was performed.

Expected actions: hold/review if within window, known-good vendor callback, BEC typology record, business user education, ACH recovery path, control gap CAPA。

Scenario 4: Crypto Investment Scam

A retail customer sends repeated wires to a crypto exchange after receiving app warnings.
They say they have already seen profits but must deposit more to unlock withdrawal.

Expected actions: investment scam warning, cooling-off, fraud specialist conversation, ask withdrawal proof, repeat-targeting review, complaint/recovery prep if payment proceeds。

Scenario 5: Complaint After Prior Warning

A customer complains that the bank should have stopped a P2P payment.
Evidence shows a generic warning was shown, but no typology-specific warning or structured response was captured.

Expected actions: complaint evidence review, remediation owner decision under policy, warning design CAPA, model label update, conduct risk review。

---

18. Practical Templates

18.1 Executive One-Pager

Problem:
Authorized customers are sending fast payments under scam influence.

Risk:
Customer loss, complaint exposure, mule network growth, conduct risk, payment disruption.

Architecture:
Separate identity confidence from intent confidence; score beneficiary/mule risk;
apply rail-aware friction; escalate to trained humans; preserve evidence; feed outcomes back.

Controls:
Typology warnings, payee scoring, structured interviews, recovery workflow,
model monitoring, privacy boundary, conduct review.

Metrics:
Loss, prevented loss estimate, false friction, delay, recovery, complaints,
evidence completeness, model drift.

Decision needed:
Approve pilot scope, risk appetite, intervention authority, staffing, data boundary and roadmap.

18.2 Scam Intervention Case Card

Case ID:
Customer:
Rail / channel:
Amount:
Beneficiary:
Typology:
Risk vector:
Intent confidence:
Intervention:
Customer response:
Decision owner:
Outcome:
Recovery action:
Complaint status:
Evidence score:
CAPA:

18.3 Warning Copy Principles

18.4 Model Monitoring Pack

18.5 Complaint Review Worksheet

---

19. 30-Day Portfolio Lab

目标: 30 天内做出一个可展示的 AI APP Scam Intervention Architecture portfolio pack。推荐选择 "instant payment safe-account scam" 或 "branch wire romance/investment scam"。

---

20. Interview Answers

Q1: 如何向高管解释 APP scam intervention architecture?

30 秒:

这不是普通 fraud model。客户本人通过认证并授权付款, 但 intent 可能被诈骗操控。架构目标是把 identity confidence、beneficiary/mule risk、payment rail window、customer intent confidence 和 social-engineering signals 连接起来, 用比例化 friction 干预, 并保留 evidence 支撑投诉、补救、审计和模型改进。

Q2: 为什么 MFA 不能解决 APP scam?

30 秒:

MFA 证明操作人可能是客户本人, 但不能证明客户没有被 impersonation、safe-account scam、romance scam 或 remote-access coaching 操控。APP scam 需要在认证之外建立 intent confidence layer 和 scam-specific intervention。

Q3: 你如何设计不伤害合法客户的 friction?

30 秒:

我会用 risk-based intervention ladder: 低风险只确认, 中风险给 typology-specific warning, 高风险加 checklist/cooling-off/callback, critical cases 才进入 hold/delay/decline/escalation under policy。同时监控 false friction、legitimate payment delay、complaints and override。

Q4: Beneficiary/mule graph 的价值是什么?

30 秒:

APP scam 的资金出口通常是 mule network。只看 sender anomaly 会漏掉多个受害人向同一收款集群付款的模式。Beneficiary graph 能在 payee setup、first payment、repeat payment 和 post-payment recovery 阶段提供 destination risk, 但必须受 data-sharing, privacy and AML governance 约束。

Q5: Conversation signals 怎样使用才专业?

30 秒:

只使用合法收集、目的明确、最小必要的数据, 如客服转写、branch structured notes、in-app memo、客户主动提供的 scam messages。不要默认扫描客户私人 SMS/email/social media。模型输出要是 reason codes and confidence, 而不是给客户贴标签。

Q6: 如果客户坚持付款怎么办?

30 秒:

架构不应让一线员工临场拍脑袋。应按 rail-aware policy 记录 risk vector、warning、客户回答、frontline escalation、decision owner and final action。是否 delay、hold、decline 或 release 取决于产品条款、rail rules、Legal/Compliance and institutional policy。无论结果如何, evidence and recovery path 要完整。

Q7: 投诉和补救怎么和 AI 架构连接?

30 秒:

每次 intervention 都要有 case_id 连接 transaction、risk vector、warning content、customer response、staff notes、decision and recovery action。投诉团队基于 evidence pack 和政策事实做 remediation review。模型团队只在 QA 后使用 outcome label, 避免把争议案例直接当训练真相。

Q8: 这个 portfolio 能体现 PM/Architect 的什么能力?

30 秒:

它体现我能把 AI risk、payment rails、fraud operations、frontline workflow、privacy、conduct、model risk and complaints 串成一个可运行的 customer protection architecture, 而不是只画一个模型或写一段 warning copy。

---

21. Final Operating Principle

AI APP scam intervention maturity 可以用一个问题测试:

If an authenticated customer is about to send fast money under possible scam influence,
can the institution estimate intent and beneficiary risk,
pause the right transaction with the least harmful friction,
escalate through trained humans,
act within rail-specific windows,
preserve evidence for complaints and remediation,
learn from outcomes,
and prove privacy, conduct and model governance discipline?

如果答案不清楚, 问题不是缺一个 fraud score。问题是 payment product、AI decisioning、scam operations、branch/call center、complaints、privacy、conduct risk and evidence engineering 还没有被设计成同一套 operating system。